CSRF攻击

除了XSS攻击外，还有一种叫CSRF的攻击不容小视。

什么是CSRF攻击呢？

与XSS攻击的不同之处在于，CSRF攻击不需要往用户的页面中注入恶意脚本。

常见的CSRF攻击有 自动发起get请求 ， 自动发起post请求 ， 诱导用户点击链接 三种方式。

在一个 img 标签里构建一个 get 请求，当页面被加载时，浏览器便会自动发起一个 get 请求。

<img src="http://xxx.org?value=100">

在页面中隐藏一个表单，当用户打开页面时，自动提交这个表单。

如：

在 a 标签的 href 属性里构建一个请求，然后诱导用户去点击。

如何防止CSRF攻击呢？

发起CSRF攻击有两个条件，分别是用户登录了目标站点，且浏览器保留了用户的登录状态；用户打开了第三方站点。

攻击者会利用登录状态来发起CSRF攻击，而 Cookie 是保持登录状态的关键数据，所以，可以在 Cookie 上想办法防止CSRF攻击。

在 Cookie 中加入 sameSite 属性，samesite有三种值。

服务端验证请求源，如果请求来自非指定源，则服务端不做响应。

浏览器向服务端发送请求时，服务端生成一个 CSRF Token ，并将它植入到返回的页面中。当再次发起请求时，就需要携带这个 CSRF Token ，如果没有这个token，则请求失败。

说明: 本文大部分借鉴 wiki-跨站请求伪造 , 另一部分来自文章 wiki-Cross-Site Request Forgery

csrf 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造. 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。 . CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应

攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞： 简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。 补充: 还可能更改账号所绑定的邮箱地址或者密码等.

假如 Alice 在 bank.com 向 Bob 汇款 10000, 那么攻击将会由以下两步骤组成:

如果 bank.com 把查询参数放到 URL 中, 那么 Alice 向 Bob 转账的操作可以简化为如下:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria 根据 bank.com 网站请求的结构, 将 Bob 名字替换为她自己的, 还把金额变大:

http://bank.com/transfer.do?acct=MARIA&amount=100000

那么这个充满恶意的 URL ,被 Maria 放到 a 标签中, 并且利用欺骗语言吸引 Alice 点击:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

或者放到一个 长度和宽度都为0 的图片的src 中(图片不用用户点击, 自己就发起请求):

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">

如果这张图片放到邮件中, Alice 根本就不会发现什么. 然而浏览器还是会将请求提交到 bank.com 的后台中.

一个真实的事件是发生在2008 年的 uTorrent exploit

假设 bank.com 现在使用 post 请求来传递参数的, 那么这个请求可以简化为:

这种情况下, a 标签和 img 标签都无法发送 post 请求, 但是可以使用 FORM 来完成:

我们还可以利用 JavaScript 来让文档载入的时候就发送这个请求:

假设现在银行使用的是 PUT 将数据放到一个JSON 中发送到后台中:

那么我们可以利用内嵌的 JavaScript :

幸运的是这段 PUT 请求并不会发送, 因为 同源策略 的限制. 除非你的后台设置了

不论是 GET 请求还是 POST 请求, 如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失10000资金。

这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着 如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。

CSRF（Cross Site Request Forgery），中文翻译为跨站请求欺骗攻击，是一种利用了浏览器漏洞的一种攻击手段，常被黑客用作刷接口的手段。

Cookie是保存在浏览器本地的一些数据，通常服务器会将和用户有关的数据，如登录token存放在Cookie中。浏览器有一套对Cookie的保护措施，比如Cookie按域（domain）存储，Cookie在别的域下是不可见的。

浏览器中的Cookie按照域（Domain）存储，不同域下的Cookie彼此不可见。但是从别的域下发来的请求却能带上这个域的Cookie。带上Cookie是好事，但不可避免的产生一些坏结果，因为Cookie中往往存储了用户的登录token，这使得来自别的域的请求自动处于登录状态，这意味着别的域的请求能模拟用户做出任何事情，比如批量发帖，批量删帖等。

小明是某某社区的用户

虽然跨域请求能带上Cookie，但请求前却无法看到Cookie中的内容，那么我们只要在Cookie中加上一个字段（X-CSRF-TOKEN）并在别的地方如Header中加上一个一模一样的字段，在服务器收到请求时校验这两个字段是否一致，便能防御CSRF攻击。

生成X-CSRF-TOKEN有两种策略：

1.在登录时由服务器下发给Cookie。

2.前端通过随机数生成，当发送请求时，发现Cookie中没有X-CSRF-TOKEN字段，便给Cookie加上该字段。

实践时我采用了前端随机生成Token的方法，实现过程中也遇到了一些问题。

1.如何生产Token

通过随机数生成的Token实际上就是时间戳。这种随机数是可以被碰撞攻击的。比如用户生成了Token就被CSRF，那CSRF中携带的Token完全可能与我们生成的Token一致。解决方法是通过服务器下发的登录Token+时间戳做一个md5作为X-CSRF-TOKEN。

但这由带来了另一个问题，像登录Token这种重要的数据应该设置为http only，即js不可见，这样才能避免另外一些攻击，因此最好的办法实际是采用服务器下发Token的方式。

2.token放在header中还是放在body里

将Token放在Header中当然是最好的，但在实践中，使用自定义的Header会带来一些跨域的问题。浏览器在遇到跨域并且请求中有自定义Header时，首先它会向服务器发送一个Options请求来获取服务器的跨域策略，即response中的那几个header：

Access-Control-Allow-Origin

Access-Control-Allow-Methods

Access-Control-Allow-Credentials

Access-Control-Allow-Headers

因此在服务端我们要在Access-Control-Allow-Methods中加上Options，在Access-Control-Allow-Headers中加上X-CSRF-TOKEN。

然而这还不够，发送Options请求很有可能会失败，如果你有nginx的话。nginx可能会直接将Options请求给拦下来，导致之后的请求无法执行。

---