本系列文章分享JavaScript语言常见的安全漏洞，漏洞的原理，可能导致的安全问题，以及如何防御与避免。本文分享的是跨站点请求伪造（Cross Sites Request Forgery）。

跨站点请求伪造，指利用用户身份操作用户账户的一种攻击方式，即攻击者诱使用户访问一个页面，就以该用户身份在第三方有害站点中执行了一次操作，泄露了用户的身份信息，接着攻击者就可以使用这个伪造的，但真实存在的身份信息，到某网站冒充用户执行恶意操作。

但是，攻击者只有预测到URL的所有参数与参数值，才能成功地伪造一个请求（当然了，他可以在安全站点里以自己的身份实际去操作一下，还是能拿到参数的）；反之，攻击者无法攻击成功

下图通俗解释什么是CSRF，又是如何给用户带来危害的

参考上图，我们可以总结，完成一次CSRF攻击，必须满足两个条件

用户登录受信任网站B，并且在本地生成Cookie

在不登出网站B的情况下，访问有害网站C

CSRF的原理

CSRF攻击是攻击者利用**`用户身份`**操作用户账户的一种攻击方式

CSRF的攻击方式

1.浏览器的Cookie策略

浏览器所持有的策略一般分为两种：

1. Session Cookie，临时Cookie。保存在浏览器进程的内存中，浏览器关闭了即失效。
2. Third-party Cookie，本地Cookie。服务器在Set-Cookie时指定了Expire Time。过期了本地Cookie失效，则网站会要求用户重新登录。

* 在浏览网站的过程中，即使浏览器打开了Tab页，Session Cookie都是有效的，因此发起CSRF攻击是可行的。

2.P3P头的副作用

"P3P Header"是 "W3C" 制定的一项关于隐私的标准，全称是 "The Platform for Privacy Preference"（隐私偏好平台）

如果网站返回给浏览器的 HTTP 头包含有 P3P 头，则在某种程度上来说，将允许 浏览器发送第三方 Cookie。在 IE 下即使是"<iframe>"、`<script>`等标签页将不再拦截第三方 Cookie 的发送。主要应用在类似广告等需要跨域访问的页面。

3.GET，POST请求

* 这里有个误区

大多数 CSRF 攻击，都是通过 <img> 、 <iframe> 、 <script> 等带 src 属性的标签，这类标签只能发送一次 GET 请求，而不能发送 POST 请求，由此也有了认为 CSRF 攻击只能由 GET 请求发起的错误观点。

构造一个 POST 请求，只需要在一个不可见的iframe窗口中，构造一个form表单，然后使用JavaScript自动提交这个表单。那么整个自动提交表单的过程，对于用户来说就是不可见的。

CSRF的防御方式

1.验证码

原理：

CSRF攻击过程中，用户在不知情的情况下构造了网络请求，添加验证码后，强制用户必须与应用进行交互

*  优点：简洁而有效

*  缺点：网站不能给所有的操作都加上验证码

2.Referer Check

原理：

* 利用HTTP头中的Referer判断请求来源是否合法

* Referer首部包含了当前请求页面的来源页面的地址，一般情况下Referer的来源页就是发起请求的那个页面，如果是在iframe中发起的请求，那么对应的页面URL就是iframe的src

*  优点：简单易操作（只需要在最后给所有安全敏感的请求统一添加一个拦截器来检查Referer的值就行）

*  缺点：服务器并非什么时候都能取到Referer

        1.很多出于保护用户隐私的考虑，限制了Referer的发送。

        2.比如从HTTPS跳转到HTTP，出于安全的考虑，浏览器不会发送Referer

3.使用Anti CSRF Token

原理：把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值，也就无法构造请求的 URL，也就无法发起 CSRF 攻击。

例子（增加token）：

*  比如一个删除操作的URL是：`http://host/path/delete?uesrname=abc&item=123`

*  保持原参数不变，新增一个参数Token，Token值是随机的，不可预测

*  http://host/path/delete?username=abc&item=123&token=[random(seed)]

*  优点：比检查Referer方法更安全，并且不涉及用户隐私

*  缺点：

        加密

        1. 加密后的URL非常难读，对用户非常不友好

        2. 加密的参数每次都在改变，导致用户无法对页面进行搜索

        3. 普通参数也会被加密或哈希，将会给DBA工作带来很大的困扰，因为数据分析常常需要用到参数的明文

        token

1. 对所有的请求都添加Token比较困难

需要注意的点

Token需要足够随机，必须用足够安全的随机数生成算法

Token应该为用户和服务器所共同持有，不能被第三方知晓

Token可以放在用户的Session或者浏览器的Cookie中

尽量把Token放在表单中，把敏感操作由GET改为POST，以form表单的形式提交，可以避免Token泄露（比如一个页面：http://host/path/manage?username=abc&token=[random]，在此页面用户需要在这个页面提交表单或者单击“删除”按钮，才能完成删除操作，在这种场景下，如果这个页面包含了一张攻击者能指定地址的图片<img src="http://evil.com/notexist" />，则这个页面地址会作为HTTP请求的Refer发送到evil.com的服务器上，从而导致Token泄露）