Web安全之CSRF

测试积点老人

什么是CSRF?
跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

以上是维基百科对CSRF的解释，我画一幅思维导图更好理解：


用户通过源站点页面可以正常访问源站点服务器接口，但是也有可能被钓鱼进入伪站点来访问源服务器，如果伪站点通过第三方或用户信息拼接等方式获取到了用户的信息，直接访问源站点的服务器接口进行关键性操作（例如支付扣款或返回用户隐私信息等操作），此时如果源站点服务器未做校验防护，伪站点的请求操作就可以被成功执行。另一种情况则可能是盗刷源站点的登录等接口来暴力破解用户密码的情况，如果源站点不添加防护措施，用户信息就极可能被盗取

例子
假如一家银行用以执行转账操作的URL地址如下：

1. 　　http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

复制代码

　那么，一个恶意攻击者可以在另一个网站上放置如下代码：

1. 　<imgsrc="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

复制代码

如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。

透过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义执行操作。

防御措施

• 检查Referer字段
  

HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。

这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。

• 添加校验token
  

由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。

我们在源站点服务请求调用时添加了对源站点的验证，使用服务器端实时返回加密的验证 Token给源站点页面，在源站点页面提交时将 Token一起带给服务器验证，而Token是不会被其他伪站点利用的。而非法的伪站点和盗刷的行为就可以被直接拒绝掉，这样就大大降低了CSRF发生的概率。所以在Web后端，我们常常会进行 Token的验证，其中一种形式是将页面提交到后台的验证 Token与 session临时保存的 Token进行比较就可以来实现了。

1. 　//生成随机的csrf验证 Token，并返回给前端页面
   
2. 　　this.session.csrf = md5(math.random(0, 1).tostring().slice(5, 15);
   
3. 　　this.body = yield render('user/login', {
   
4. 　　  csrf: ctx.session.csrf
   
5. 　　});
   
6. 　　//提交时验证 Token是否与源站的 Token相同
   
7. 　　let csrf = this.request.body['csrf'];
   
8. 　　if (csrf !== this.session.csrf) {
   
9. 　　  res = {
   
10. 　　      code: 403,
    
11. 　　      msg: '不明网站来源提交'
    
12. 　　    }
    
13. 　　} else {
    
14. 　　  // 正常提交后的逻辑
    
15. 　　}

复制代码

目前解决CSRF的最佳方式就是通过加密计算的 Token验证，而 Token除了通过 session也可以使用HTTP请求头中 Authorization的特定认证字段来传递。当然并不是说使用了Token，网站调用服务就安全了，单纯的 Token验证防止CSRF的方式理论上也是可以被破解的，例如可以通过域名伪造和拉取源站实时 Token信息的方式来进行提交。另外，任何所谓的安全都是相对的，只是说理论的破解时间变长了，而不容易被攻击。很多时候要使用多种方法结合的方式来一起增加网站的安全性，可以结合验证码等手段大大减少盗刷网站用尸信息的频率等，进一步增强网站内容的安全性。