关于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必须经过两个步骤：

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

2、用户在访问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，如何进行防御？

 

1、服务器端表单hash认证

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

 

2、验证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攻击，则拒绝该请求。

 

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

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

我们就是采用的这种方法，因为基本上所有的请求都是通过ajax，我们通过重新封装ajax，在ajax头部添加一个token，server去识别这个token，如果请求没有这个token或者错误就拒绝。

 

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

 

5、尽量少用或不要用request()类变量，获取参数指定request.form()还是request. querystring ()，这样有利于阻止CSRF漏洞攻击，此方法只不能完全防御CSRF攻击，只是一定程度上增加了攻击的难度。

 

6、 通过图形验证码

相对来说图形验证码应该是最安全的，但是我们不可能在所有的API上去加上这么个玩意儿，一般是在表单，比如注册，登录等，当用户频繁操作时出现，避免影响用户体验

 

所以建议以后ajax请求都尽量加上token验证，虽然不一定能防御所有的CSRF攻击，但是可以大幅度提升接口的安全性，中秋节加班通过紧急修复后，CSRF攻击基本没有了。

 

 

 

 

转载于:https://www.cnblogs.com/hutuzhu/p/5919400.html