你了解可怕的CSRF攻击吗？

vlambda
2020-01-10

你了解可怕的CSRF攻击吗？

来源丨小怪聊职场

www.jianshu.com/p/67408d73c66d

什么是CSRF攻击

CSRF攻击的全称是跨站请求伪造（ cross site request forgery)，是一种对网站的恶意利用。CSRF 是通过伪装来自受信任用户的请求来利用受信任的网站。你可以这么理解 CSRF攻击：攻击者盗用了你的身份，以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括：利用你的身份发邮件、发短信、进行交易转账等，甚至盗取你的账号。

CSRF攻击原理

首先用户 C浏览并登录了受信任站点 A；
登录信息验证通过以后，站点 A会在返回给浏览器的信息中带上已登录的 cookie， cookie信息会在浏览器端保存一定时间（根据服务端设置而定）；
完成这一步以后，用户在没有登出（清除站点 A的 cookie）站点 A的情况下，访问恶意站点 B；
这时恶意站点 B的某个页面向站点 A发起请求，而这个请求会带上浏览器端所保存的站点 A的 cookie；
站点 A根据请求所带的 cookie，判断此请求为用户 C所发送的。

因此，站点 A会根据用户 C的权限来处理恶意站点 B所发起的请求，而这个请求可能以用户 C的身份发送邮件、短信、消息，以及进行转账支付等操作，这样恶意站点 B就达到了伪造用户 C请求站点 A的目的。

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

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

很多情况下所谓的恶意站点，很有可能是一个存在其他漏洞的受信任且被很多人访问的站点，这样，普通用户可能在不知不觉中便成为了受害者。

CSRF攻击举例

当你登录网站 A后，没有及时登出，这时你访问了论坛 B，不幸的事情发生了，你会发现你的账号里面少了 10000块...

当然，绝大多数网站都不会使用 GET请求来进行数据更新，因此，攻击者也需要改变思路，与时俱进。

假设银行将其转账方式改成 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 type="text" name="money" value="10000"/>
  
    
    
  </form>
  
    
    
  <script>
  
    
    
   var form = document.forms('aaa');
  
    
    
   form.submit();
  
    
    
  </script>

当然，以上只是举例，正常来说银行的交易付款会有USB key、验证码、登录密码和支付密码等一系列屏障，流程比上述流程复杂得多，因此安全系数也高得多！

CSRF的防御

尽量使用POST，限制GET

GET接口太容易被拿来做 CSRF攻击，看上面示例就知道，只要构造一个 img标签，而 img标签又是不能过滤的数据。接口最好限制为 POST使用， GET则无效，降低攻击风险。

当然 POST并不是万无一失，攻击者只要构造一个 form就可以，但需要在第三方页面做，这样就增加暴露的可能性。

将 cookie设置为 HttpOnly

CRSF攻击很大程度上是利用了浏览器的 cookie，为了防止站内的 XSS漏洞盗取 cookie,需要在 cookie中设置 “HttpOnly”属性，这样通过程序（如 JavaScript脚本、 Applet等）就无法读取到 cookie信息，避免了攻击者伪造 cookie的情况出现。

在 Java的 Servlet的API中设置 cookie为 HttpOnly的代码为：response.setHeader("Set-Cookie","cookiename=cookievalue;HttpOnly");

增加Token

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

通过Referer识别

参考文献

《大型分布式网站架构设计与实践》

后记

vlambda博客
学习文章列表