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