01 漏洞描述

HTTP的无状态性，导致Web应用程序必须使用会话机制来识别用户。一旦与Web站点建立连接(访问、登录)，用户通常会分配到一个Cookie，随后的请求，都会带上这个Cookie，这样Web站点就很容易分辨请求来自哪个用户，该修改哪个用户的数据。如果从第三方发起对当前站点的请求，该请求也会带上当前站点的Cookie。正是这是这个缺陷，导致了CSRF的产生，利用这个漏洞可以劫持用户执行非意愿的操作。

02 漏洞检测

CSRF的利用场景常常是在用户已登录的情况下，伪造用户意愿从站外发起请求。更深入剖析：请求能从站外发起(跨站)、请求的参数和值可以伪造(伪造请求)，因此，CSRF的检测也是从这两点入手。

以转账为例，输入账户和金额，点击Transfer即可完成转账。我们检测该功能是否存在CSRF。

是否可跨站

要检测是否可跨站，只需要操作请求头中的referer字段即可。referer字段记录了请求的来源，如果请求头中没有referer字段，或者删掉请求头中的referer字段，均响应成功，那么服务器就没有校验请求来源，存在“跨站”。

首先正常提交请求包，发现转账成功。

我们可以看到请求头中有个Referer字段，其中的值表示我们是从哪个页面请求过来的。我们试着将Referer字段删除并再次提交，查看账户余额有没有变化。

发现账户余额从990变成980，说明服务器并没有验证请求来源，可以“跨站”。

是否可伪造请求

伪造请求的前提是，我们知道如何去伪造请求中的参数和值，也就是说我们知道请求中包含哪些参数，知道参数的准确值或者范围。因此，检测是否可伪造请求，只需要查看请求中是否有我们无法伪造的参数和值即可。

可以看到，请求中有4个参数，account表示账号，amount表示转账金额，这两个很好伪造，action表示执行的动作，不需要伪造，直接使用即可。token是什么东西？(Token令牌了解一下)

token参数的值这么长，一看就知道不好伪造。那删掉token试试，万一和referer字段一样，服务器没有对token进行校验呢。

反复重放了几次请求，发现账户余额保持不变，很显然，token参数必须有。那我们随便改一下token的值，看请求中是不是只要有token参数就行了，但服务器并不会校验token的值。

反复重放几次，发现账户余额依然保持不变，说明服务器对Token做了校验，请求中不能缺失token或token错误。

正打算放弃的时候，无聊的重放着原始请求包，突然发现账户余额变成了900。

WTF，同一个token值好像可以反复使用，均能通过校验，难道这token是永久的？后来发现只要不退出重新登录，token会一直有效，了解了，这叫“韩式半永久”。

验证CSRF

既能“跨站”，又能伪造请求，那CSRF的验证就很简单了。重新抓包，利用抓包工具生成CSRF的POC。

复制其中的HTML代码，在本地新建一个HTML页面，将复制的代码保存其中，然后在同一个浏览器中打开(不懂的请gun去学习Cookie方面的知识)。

点击CSRF页面中的按钮，发现会跳转到转账页面，且账户余额只有400，少了500。 

CSRF的检测到此圆满结束。至于CSRF的利用，简单说两句，可以构造一个链接(GET)、隐藏的表单(POST)、图片等，然后想方设法让用户点击或访问就可以了。  

03 漏洞修复

请求来源验证；HTTP请求头中有个referer字段，该字段记录了当前HTTP请求的来源。可以通过检查请求是否来自站外，来防御站外发起的CSRF，但不能防御从站内发起的CSRF，且存在被绕过的风险。

Token验证；在请求中添加攻击者无法预测的Token令牌，当请求中缺失Token或Token值不对时，则拒绝请求。请使用一次性的Token，而且记得及时更新，不然还是可以绕过。(这种情况工作中已经遇到过无数次了)

使用图形验证码，但可能会影响用户体验。

04 PS

我这里举了一个既包含referer又包含token的例子，为了让大家更好的理解CSRF的检测，排版可能会与实际情况有些出入。实际工作中，我个人习惯先多次重放，看token是否可重复使用，如果可重复使用，自然不用修改token值或删除，只需要检测是否可“跨站”即可；如果不能重复使用，说明会校验token值，那么就不必修改token值，只需直接删除token试试，最后再测试是否可“跨站”。而且在实际利用中，token值的获取没有这么简单。只是在检测过程中，我们发现token机制存在缺陷，那我们应该防患于未然，将风险降低到零。这里简要解释一下文章内容与实际工作中相出入的几点。