CSRF介绍、概念

CSRF跨站点请求伪造(Cross—Site Request Forgery)，也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

简单理解：

攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

攻击原理：

  1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

​ 2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

​ 3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

​ 4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

受害者只需要做下面两件事情，攻击者就能够完成CSRF攻击：

  • 登录受信任站点 A，并在本地生成cookie；
  • 在不登出站点A（清除站点A的cookie）的情况下，访问恶意站点B。

CSRF攻击举例

GET型

假设某银行网站A以GET请求来发起转账操作，转账的地址为www.xxx.com/transfer.do?accountNum=l000l&money=10000，参数accountNum表示转账的账户，参数money表示转账金额。
而某大型论坛B上，一个恶意用户上传了一张图片，而图片的地址栏中填的并不是图片的地址，而是前而所说的砖账地址：<img src="http://www.xxx.com/transfer.do?accountNum=l000l&money=10000">
当你登录网站A后，没有及时登出，这时你访问了论坛B，不幸的事情发生了，你会发现你的账号里面少了10000块…
为什么会这样呢，在你登录银行A时，你的浏览器端会生成银行A的cookie，而当你访问论坛B的时候，页面上的标签需要浏览器发起一个新的HTTP请求，以获得图片资源，当浏览器发起请求时，请求的却是银行A的转账地址www.xxx.com/transfer.do?accountNum=l000l&money=10000，并且会带上银行A的cookie信息，结果银行的服务器收到这个请求后，会以为是你发起的一次转账操作，因此你的账号里边便少了10000块。
当然，绝大多数网站都不会使用GET请求来进行数据更新，因此，攻击者也需要改变思路，与时俱进。

POST型

假设银行将其转账方式改成POST提交，而论坛B恰好又存在一个XSS漏洞，恶意用户在它的页面上植入如下代码：

<form id="aaa" action="http://www.xxx.com/transfer.do" metdod="POST" display="none">
    <input type="text" name="accountNum" value="10001"/>
    <input ty。pe="text" name="money" value="10000"/>
</form>
<script>
    var form = document.forms('aaa');
    form.submit();
</script>

如果你此时恰好登录了银行A，且没有登出，当你打开上述页面后，脚本会将表单aaa提交，把accountNum和money参数传递给银行的转账地址http://www.xxx.com/transfer.do，同样的，银行以为是你发起的一次转账会从你的账户中扣除10000块。

CSRF防御

1、尽量使用POST，限制GET

GET接口太容易被拿来做CSRF攻击，看上面示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。接口最好限制为POST使用，GET则无效，降低攻击风险。
当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样就增加暴露的可能性。

2、增加token

类似一种不需要输入的“验证码”。

CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于cookie中，因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息总不存在于cookie之中。鉴于此，系统开发人员可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务端进行token校验，如果请求中没有token或者token内容不正确，则认为是CSRF攻击而拒绝该请求。也可以在HTML表单中加入隐藏的token，在提交表单时验证（适用范围小）

但如果网站同时存在xss、csrf，这种token防御机制可能就失效了，因为攻击者能从javascript获取token值。

3、二次确认

在用户进行一些关键操作时候，产生对话框二次提示确认。

或要求输入验证码，敏感操作要进行验证码验证。

这样用户突然收到提示也会警觉起来。

参考：

https://blog.csdn.net/stpeace/article/details/53512283

https://www.jianshu.com/p/67408d73c66d

https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

赏

菜菜子新人