16 KiB
因收到Google相关通知，网站将会择期关闭。相关通知内容
08 CSRF_SSRF：为什么避免了XSS，还是“被发送”了一条微博？
你好，我是何为舟。
前面我们讲了2种常见的Web攻击：XSS和SQL注入。它们分别篡改了原始的HTML和SQL逻辑，从而使得黑客能够执行自定义的功能。那么除了对代码逻辑进行篡改，黑客还能通过什么方式发起Web攻击呢？
我们还是先来看一个例子。在平常使用浏览器访问各种网页的时候，是否遇到过，自己的银行应用突然发起了一笔转账，又或者，你的微博突然发送了一条内容？
在我们学习XSS之后，你可能会联想到，这是银行或者微博中出现了某个XSS漏洞。但问题是，你今天并没有访问过银行或者微博的页面，所以并没有“被XSS”的机会。这时，你想到，会不会是你今天访问的其他网页里存在一些恶意的攻击，实现了你不知道的转账和发博行为呢？好了，你肯定很想知道黑客究竟是怎么做到的，那你不妨先自己思考一下，写出几个可能的答案，然后跟着我开始学习今天的内容！
CSRF攻击是如何产生的？
我们几乎每天都要用到浏览器，我们的信息也会被浏览器“保存”。那我们首先来看一下，浏览器是如何保存你的身份信息的。
当我们在访问一个Web页面的时候，并不是我们自己去获取页面信息，而是浏览器去获取了这些信息，并将它们进行了展示。这就说明，你允许浏览器代表你去和Web的服务端进行交互。为了能够准确地代表你的身份，浏览器通常会在Cookie中存储一些必要的身份信息。所以，在我们使用一个网页的时候，只需要在首次访问的时候登录就可以了。
从用户体验上来说，这当然是非常方便的。但是，黑客正是利用这一点，来编写带有恶意JavaScript脚本的网页，通过“钓鱼”的方式诱导你访问。然后，黑客会通过这些JavaScript脚本窃取你保存在网页中的身份信息，通过仿冒你，让你的浏览器发起伪造的请求，最终执行黑客定义的操作。而这一切对于你自己而言都是无感知的。这就是CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击。
接下来，我们就以银行转账为例子，来详细讲解一下这个攻击过程。
当你在银行页面发起一笔转账时，这个过程其实是通过一个转账接口来完成的。这个接口的内容可能包括下面这些内容：
接口地址：http://bank.com/transfer ； HTTP方法：POST； 接口参数：to（目标账户）、amount（金额）。
在转账之前，你肯定进行了一次登录。这样一来，这个转账接口就可以通过你之前存储在Cookie中的相关字段来完成认证了。所以，这个接口参数中不需要包含任何身份认证相关的信息。也正是因为如此，这个接口满足了CSRF攻击的基本条件：
使用Cookie进行认证； 参数中不包含任何隐私信息。
于是，黑客可以构造一个如下的空白网页。我们假设这个网页的地址为 hacker.com。
<html> </html>在HTML中，