CSRF攻击及其防御

Posted 2021-04-25 信息安全club

“ 宜未雨而绸缪，毋临渴而掘井。”

CSRF的全名是（Cross Site Request Forgery），中文为跨站点请求伪造。CSRF是一种诱使受害者在有漏洞的WEB应用上用他自己的自己的会话执行其非预期操作的攻击手段。和大部分XSS攻击的目的是窃取信息不同，CSRF的攻击目的是为了提交改变状态的请求。事实上，CSRF的攻击者不能也不必看到请求的响应。

01

—

CSRF攻击实例

        让我们设想一个有CSRF漏洞的银行Leak Bank。通过对银行网站发送请求http：//www.leakbank.com/transfer?account=Andy&amount=1000&to=Bob, Andy可以把1000元转账给Bob。黑客Carl在Leak Bank开了一个账户，想偷取Andy的钱，他可以尝试发送请求http：//www.leakbank.com/transfer?account=Andy&amount=1000&to=Carl, 但这个请求来自Carl自己，不是来自Andy，所以会授权失败。

        这时Carl想起可以利用CSRF漏洞。通过一点社会工程学，比如在自己的网站上放个内涵图片啥的，受害者Andy不幸点了某个链接，替Carl提交了请求。这时上述URL会从Andy的浏览器发向Leak Bank，而这个请求会附上Andy浏览器中的cookie一起发向银行服务器。在大多数情况下这个请求会失败，因为这需要Andy的认证信息。但如果Andy刚访问过Leak Bank，并且Session仍然有效的话，悲剧就诞生了。Andy的1000块钱在他毫不知情的情况下被转移到了Carl的账户。即使有朝一日他察觉了，去银行查询日志，也只能看到曾经由一个来自他本人的合法请求转移了这笔钱。

02

—

CSRF的防御

验证码

        验证码强制了用户必须和应用交互才能完成请求。因此在通常的情况下，能很好地防止CSRF。但是验证码的用户体验太差，在企业应用里一般不能考虑这种做法。

Referer check

         然而，这种方法有其缺点。首先，在某些浏览器上黑客有可能篡改Referer。其次，因为Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯隐私，因此设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，Leak Bank会因为没有 Referer 值而拒绝合法请求。

Anti CSRF Token

         CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中。要抵御 CSRF，需要在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。因此可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则拒绝该请求。

        这种方法的难点在于如何把 token 以参数的形式加入请求。我们的做法是三管齐下，

• 通过修改form的prototype在submit前注入token

• 通过document.ready的listener来为动态创建的form注入token

• 通过修改tag来注入token

  
  

用HTTP Header 自定义属性验证

       和上一种方法类似，不同之处在于 token 不是以参数的形式置于 HTTP 请求之中，而是在 HTTP Header中自定义属性里。通过 XMLHttpRequest 这个类，可以给所有该类请求加上 csrftoken 这个 HTTP Header属性，并设置 token 值。这样能免除上一种方法的种种不便，然而本方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适用。

注：鉴于暴露产品代码有违反SBC之嫌，这次就不贴代码了（前几次帖子也将逐一整改），请感兴趣的同学自己去git找源码看