CSRF的原理及防御

简解：CSRF的原理及防御

Cross-Site Request Forgery，跨站请求伪造。攻击者通过盗用用户身份悄悄地发送一个请求，达到目的。

简单地讲，我们在上网的时候，网站会使用cookie来识别用户身份，【1】每次请求一个资源时，客户端都会主动附带cookie给服务器进行身份认证。【2】如果此时是从第三方页面（另一个域B）发起对该域（A）的请求，也会附带上A的cookie。CSRF就是利用这样的机制实施攻击的。

【上边的1和2是为了下边讲清楚，其实它们是一个东西】

具体攻击方式分两大类：
1、服务器接受GET方式请求。
e.g. 1 （针对上边的【1】）: 用户登录了某银行站点www.bank*.com，用户可以输入转账id（假设攻击者id=11）和money通过trasf.php的操作达到转账目的。我们构造一个URL： http://www.bank*.com/trasf.php?id=11&money=10000，接着引诱用户单击，这样就完成攻击，用户给攻击者转账成功。
==>
这个过程中，由于用户已经登录了网站，他之后对该网站的请求会附带自己的身份信息，也就是cookie，这样，单击我们构造的URL之后，就会以用户的身份向服务器发出转账请求。
e.g. 2 （针对上边的【2】）: 攻击者搭建一个恶意网站 attack.com，其中有一个页面X.html有如下代码： <iframe src=http://www.bank*.com/trasf.php?id=11&money=10000> 当用户登录到银行 www.bank*.com之后，访问 attack.com/X.html，完成攻击。
==>
用户访问 attack.com/X.html 时，由于是从第三方页面（attack.com）发起对域（www.bank*.com）的请求，也会附带上www.bank*.com 的cookie，所以该脚本带着cookie执行了，攻击成功。（ <iframe>会自动执行的，类似的还有 <img>， <script>等方式）

我们知道，在写这类涉及敏感数据的表单时，提交方式都会用POST而不是GET，假设上边的银行也用了POST方式，但是，我们的CSRF攻击还是成功了。原因在于，在服务器接收表单数据时，开发者使用了 $_REQUEST 方法而不是 $_POST，这导致了本来的POST操作可以用GET方式实现。

2、服务器只接受POST请求。
e.g.: 搭建一个攻击者自己的恶意网站 attack.com，该网站内写一个页面，页面中有一个表单，完成例子1中的那部分表单功能，即 id=11，money=10000，action=www.bank*.com/trasf.php等，然后有脚本，脚本内容为 自动将表单提交 。然后让用户在登录银行网站后访问到该页面，完成攻击。
==>
这个攻击方式也是针对【2】的。

了解了CSRF的原理后，知道其实它完全是以用户的身份去执行，而应用程序和浏览器很难去判断这是CSRF攻击还是合法请求。
那么，防御方法也就是针对这个来设计了。

主要有以下几种方法，简单讲一下：

通过检查请求页面的来源，识别从站外发起的请求，也就能防御CSRF了。

每次用户提交内容时，要求其在表单中填写验证码，提交后对其进行检测。
验证码机制是：服务器生成一个验证码，发送给客户端，以图片形式显示。然后客户填写后，发回服务器，对比验证。

CSRF能成功的一个重要原因是：攻击者能预知和伪造请求中的关键字段，因此，在请求中放入攻击者不能伪造的信息就能防御CSRF。
token就是在请求中加入一个随机参数token，服务器进行验证。

具体机制我也不懂，资料也没找到，感觉是像非对称加密解密那样的方式。这点等我之后再了解清楚，知道的朋友请不吝留言赐教。

［1］邱永华.XSS跨站脚本攻击剖析与防御[M].北京：人民邮电出版社，2013