CSRF跨站伪造请求

　　一、什么是CSRF

CSRF（Cross Site Request Forgery） 跨站请求伪造。也被称为One Click Attack和Session Riding，通常缩写为CSRF或XSRF。如果从名字你还不不知道它表示什么，你可以这样理解：攻击者（黑客，钓鱼网站）盗用了你的身份，
以你的名义发送恶意请求，这些请求包括发送邮件、发送消息、盗取账号、购买商品、银行转账，从而使你的个人隐私泄露和财产损失。

　　二、CSRF攻击实例

我们先假设支付宝存在CSRF漏洞，我的支付宝账号是lyq，攻击者的支付宝账号是xxx。然后我们通过网页请求的方式 http://zhifubao.com/withdraw?account=lyq&amount=10000&for=lyq2 
可以把我账号lyq的10000元转到我的另外一个账号lyq2上去。通常情况下，该请求发送到支付宝服务器后，服务器会先验证该请求是否来自一个合法的session并且该session的用户已经成功登陆。
攻击者在支付吧也有账号xxx，他知道上文中的URL可以进行转账操作，于是他自己可以发送一个请求 http://zhifubao.com/withdraw?account=lyq&amount=10000&for=xxx 到支付宝后台。
但是这个请求是来自攻击者而不是来自我lyq，所以不能通过安全认证，因此该请求作废。这时，攻击者xxx想到了用CSRF的方式，他自己做了个黄色网站，在网站中放了如下代码：
http://zhifubao.com/withdraw?account=lyq&amount=10000&for=xxx 并且通过黄色链接诱使我来访问他的网站。当我禁不住诱惑时就会点了进去，上述请求就会从我自己的浏览器发送到支付宝，
而且这个请求会附带我的浏览器中的cookie。大多数情况下，该请求会失败，因为支付宝要求我的认证信息，但是我如果刚访问支付宝不久，还没有关闭支付宝页面，我的浏览器中的cookie存有我的
认证信息，这个请求就会得到响应，从我的账户中转10000元到xxx账户里，而我丝毫不知情，攻击者拿到钱后逍遥法外。所以以后一定要克制住自己，不要随便打开别人的链接。

　　三、CSRF攻击原理图

要完成一次CSRF攻击，受害者必须依次完成以下两个步骤：
登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。
看到这里，你也许会问：“如果我不满足以上两个条件中的一个，我就不会受到CSRF攻击”。是滴，确实如此，但是你不能保证以下情况不会发生：你不能保证你登录了一个网站之后，不再打开一个tab页面并访问其它的网站（黄网）。
你不能保证你关闭浏览器之后，你本地的Cookie立刻过期，你上次的会话已经结束。
上述中所谓的攻击网站，可能就是一个钓鱼网站或者黄色网站。

　　四、CSRF防御

　　1，验证HTTP Referer

根据HTTP协议，在HTTP头部中有一个Referer字段，它记录了该HTTP请求所在的地址，表示HTTP请求从那个页面发出的。比如当你访问 
http://zhifubao.com/withdraw?account=lyq&amount=10000&for=xxx ，用户必须先登录支付宝网站，然后通过点击页面的的按钮来触发转账事件。此时，转账请求的Referer值就是转账页面所在的
URL，通常是以zhifubao.com域名开头的地址。如果攻击者要实行CSRF攻击，那么他只能在自己的站点构造请求，此时Referer的值就指向黑客自己的网站。因此要防御CSRF攻击，支付宝只需要对每一
个转账请求验证其Referer值，如果是以zhifubao.com开头的域名，则是合法请求，相反，则是非法请求并拒绝。
这种方法的好处就是简单易行，只需要在后台添加一个拦截器来检查Referer即可。然而这种办法并不是万无一失，Referer的值是由浏览器提供的，一些低级的浏览器可以通过某种方式篡改Referer
的值，这就给了攻击者可乘之机；而一些高级浏览器处于安全考虑，可以让用户设置发送HTTP请求时不再提供Referer值，这样当他们正常访问支付宝网站时，因为没有提供Referer值而被误认为CERF
攻击，拒绝访问。实际应用中通常采用第二种方法来防御CSRF攻击。

　　2，token验证

CSRF攻击之所以能够成功，是因为攻击者可以完全伪造用户的请求，该请求中所有的用户验证信息都存在cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的cookie来通过
安全验证。要防止CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于cookie之中。可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来
验证这个token，如果请求中没有token或者token不正确，则认为可能是CSRF攻击而拒绝该请求。
现在业界一致的做法就是使用Anti CSRF Token来防御CSRF。

　　过程：

用户访问某个表单页面。
服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。
在页面表单附带上Token参数。
用户提交请求后，服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
这个Token值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token应注意Token的保密性，尽量把敏感操作由GET改成POST，
以form或者AJAX形式提交，避免Token泄露

　　3，验证码

验证码，强制用户必须与应用进行交互，才能完成最终请求。通常情况下，验证码能够很好的遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为
一种辅助手段。

　　4，尽量用post

GET接口能够直接将请求地址暴露给攻击者，所以要防止CSRF一定最好不要用GET。当然POST并不是万无一失，攻击者只需要构造一个form表单就可以，但需要在第三方页面做，这样就增加了暴露的
可能性。

　　5，自定义HTTP属性

这种方法也是使用token并验证，但是它是把token放在HTTP请求头部中。通过使用AJAX我们可以在我们的请求头部中添加我们的自定义属性，但是这种方法要求我们将整个站的请求全部改成AJAX，
如果是新站还好，老站的话无疑是需要重写整个站点的，这是很不可取的。