CSRF（跨站点请求伪造）

• 攻击者诱使用户访问一个页面，以该用户身份在第三方站点里执行了一次操作。就叫做CSRF。

• CSRF进阶

  • 浏览器的Cookie策略
    • 浏览器所持有的Cookie分为两种：一种是“session Cookie”，又称“临时Cookie”；另一种是“Third-party Cookie”,也称为“本地Cookie”.
    • 两者的区别在于，Third-party Cookie 是服务器在set-Cookie时指定了Expire事件，只有到了Expire时间后Cookie才会失效，所以这种Cookie会保存在本地,而Session Cookie则没有指定Expire时间，所以浏览器关闭后，Session Cookie就会失效。
    • 如果浏览器从一个域要加载另一个域的资源，由于安全原因，某些浏览器会阻止Third-party Cookie.
    • 攻击者则需要精心构造攻击环境，比如P3P,再比如诱使用户在当前的浏览器中先访问目标站点，使得Session Cookie有效，再实施CSRF攻击
    • 但若CSRF攻击的目标并不需要使用Cookie，则不必考虑Cookie册罗。
  • P3P头的副作用
    • P3P Header 是W3C制定的一项关于隐私的标准，全程The Platform for Privacy Preferneces。
    • 在网站业务中，P3P头主要用于类似广告等需要跨域访问的页面，但是很遗憾的是，P3P头设置后，对于Cookie的影响将扩大到整个狱中的所有页面。
    • P3P可以参考，W3C标准（http://www.w3.org/TR/P3P）
    • *正因为P3P头目在网站的应用中被广泛应用，因此CSRF的防御不能依赖于浏览器对第三方Cookie的拦截策略。
  • GET？POST?
    • 在CSRF攻击流行之初，曾经有一个错误的观点，认为CSRF攻击只能由GET请求发起，因此很多开发者都任务只要把重要的操作改成只允许POST请求，就能防止CSRF攻击。
    • 但是会有很多种方法可以构造一个POST请求。

• CSRF的防御

  • 验证码
    • 验证码被认为是对抗CSRF攻击最简洁而有效的防御方法。
    • 但验证码并未万能，很多时候，处于用户体验考虑，网站不能给所有操作都加上验证码。因此，验证码只能作为防御CSRF的一种辅助手段，而不能作为最重要的解决方案。
  • Referer Check
    • Referer Check 的缺陷在于，服务器并非什么时候都能取到Referer,很多用户出于隐私保护的考虑，限制了Referer的发送，在某些情况下，浏览器也不会发送Referer，比如从HTTPS跳转到HTTP，出于安全的考虑， 浏览器也不会发送Referer。
    • Refer Check虽然抵挡CSRF的效果不好，但是确实一个很好的监控手段，低级的黑客攻击并很少考虑到伪造Referer
  • Anti CSRF Token
    • CSRF安全的本质是重要操作的所有参数都是可以被攻击者猜到的
    • 把参数加密，使用一些随机数，从而让攻击者无法猜测到参数值，比如md5(一个固定数值+用户账号)
    • 但是加密或混淆后的URL将变得非常不友好，如果加密的参数每次都改变，则URL将无法再被用户收藏。数据分析的工作也不好做。
    • 使用Token
      • Token一定要足够随机，需要使用安全的随机数生成器生成Token。
      • 使用Token时应该注意Token的保密性，不能让Token出现在URL种，应该尽量把Token防在表单种。把敏感操作由GET改为POST,以表单的形式提交。
    • CSRF的Token仅仅用于对抗CSRF攻击，当网站存在XSS漏洞的时候，这个方案就会无效，因为攻击者可以使用XSS读取页面内容里的Token值，然后再构造一个合法的请求，这个过程被成为XSRF

转载于:https://www.jianshu.com/p/5fab07e9f4fe