关于CSRF跨域请求伪造的解决办法

中秋节时候咱们的应用在短信验证码这块被恶意刷单，好比被用来作垃圾短信之类的，若是大规模被刷也能形成不小的损失。这还只是短信验证码，若是重要的API遭到CSRF的攻击，损失不可估量。因此紧急加班解决了CSRF的攻击问题。

CSRF是什么鬼？

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

CSRF能干吗？

你这能够这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF可以作的事情包括：以你名义发送邮件，发消息，盗取你的帐号，甚至于购买商品，虚拟货币转帐......形成的问题包括：我的隐私泄露以及财产安全。

CSRF特性？

依靠用户标识危害网站

利用网站对用户标识的信任

欺骗用户的浏览器发送HTTP请求给目标站点

另外能够经过IMG标签会触发一个GET请求，能够利用它来实现CSRF攻击。

 

CSRF原理

 

简单来讲，CSRF必须通过两个步骤：

一、用户访问可信任站点A，并产生了相关的cookie；

二、用户在访问A站点时没有退出，同时访问了危险站点B；

你们同时访问多个网站是很正常的事情，因此也很容易遭到CSRF的攻击。

 

举个栗子：

某电商网站A，你购买时候支付的操做是：http://www.market.com/Transfer.php?bankId=11&money=1000;
某危险网站B，他有段代码是 <img src=http://www.market.com/Transfer.php?bankId=11&money=1000>

访问A支付后你会发现银行卡里面多扣了1000块钱，why？经过get方式，你在访问A网站进行支付操做时，A网站保存了你的cookie信息，若是B网站拿到了你的cookie或者他伪造的数据恰好就是cookie里的，就能伪造你的请求，进行一样的支付操做。

也许你会说，我换成post请求不就好了，可是若是你的server代码没有处理，同样能够进行伪造。

 

So，如何进行防护？

 

一、服务器端表单hash认证

在全部的表单里面随机生成一个hash，server在表单处理时去验证这个hash值是否正确，这样工做量比较大，咱们以前全部的表单都没添加！！！，好几十个页面，这个当前处境不切实际

 

二、验证http Referer字段

根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在一般状况下，访问一个安全受限页面的请求必须来自于同一个网站。好比某银行的转帐是经过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登陆bank.test，而后经过点击页面上的按钮来触发转帐事件。当用户提交请求时，该转帐请求的Referer值就会是转帐按钮所在页面的URL(本例中，一般是以bank. test域名开头的地址)。而若是攻击者要对银行网站实施CSRF攻击，他只能在本身的网站构造请求，当用户经过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。所以，要防护CSRF攻击，银行网站只须要对于每个转帐请求验证其Referer值，若是是以bank. test开头的域名，则说明该请求是来自银行网站本身的请求，是合法的。若是Referer是其余网站的话，就有多是CSRF攻击，则拒绝该请求。

 

三、在HTTP头中自定义属性并验证

自定义属性的方法也是使用token并进行验证，和前一种方法不一样的是，这里并非把token以参数的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里。经过XMLHttpRequest这个类，能够一次性给全部该类请求加上csrftoken这个HTTP头属性，并把token值放入其中。这样解决了前一种方法在请求中加入token的不便，同时，经过这个类请求的地址不会被记录到浏览器的地址栏，也不用担忧token会经过Referer泄露到其余网站。

咱们就是采用的这种方法，由于基本上全部的请求都是经过ajax，咱们经过从新封装ajax，在ajax头部添加一个token，server去识别这个token，若是请求没有这个token或者错误就拒绝。

 

四、CSRF攻击是有条件的，当用户访问恶意连接时，认证的cookie仍然有效，因此当用户关闭页面时要及时清除认证cookie，对支持TAB模式(新标签打开网页)的浏览器尤其重要。

 

五、尽可能少用或不要用request()类变量，获取参数指定request.form()仍是request. querystring ()，这样有利于阻止CSRF漏洞攻击，此方法只不能彻底防护CSRF攻击，只是必定程度上增长了攻击的难度。

 

六、 经过图形验证码

相对来讲图形验证码应该是最安全的，可是咱们不可能在全部的API上去加上这么个玩意儿，通常是在表单，好比注册，登陆等，当用户频繁操做时出现，避免影响用户体验

 

因此建议之后ajax请求都尽可能加上token验证，虽然不必定能防护全部的CSRF攻击，可是能够大幅度提高接口的安全性，中秋节加班经过紧急修复后，CSRF攻击基本没有了。