web安全————CSRF（防御篇）

     CSRF防御之验证码
     目前，验证码被认为是对抗CSRF攻击最简单有效的防御措施。用到验证码就是在请求过程中强制用户与应用进行交互，但是一个站点、一个好的产品要考虑到用户的体验，显然如果在所有的操作上都加入验证码对用户来说就很不友好。因此验证码只能是一种防御CSRF攻击的辅助手段，并不能成为主要解决方案。


     CSRF攻击之Referer check
     一个站点的页面与页面之间有一定的逻辑关系，Referer check用于检查请求是否来自合法的“源”，所以多用于防止图片盗链。也就是说检查Referer值就可以知道请求是否是该站点的域，从而判断是否为CSRF攻击。但是，很多用户出于隐私保护考虑，限制了Referer的发送，服务器就无法收到Referer。Referer check还是无法成为防止CSRF攻击的主要手段，但可以通过它来对CSRF攻击进行监控。


     CSRF的本质
     在探索防御CSRF攻击道路上，要想找到一条可行的方法，那么必须先要认清CSRF的本质。CSRF为什么能够攻击成功呢？？其本质原因是因为攻击者能够猜到重要操作的所有参数，攻击者首先要成功预测URL上的所有参数与参数值才能构造一个伪造请求。既然这样的话，那么可否试试：把参数加密或者使用随机数？？这样攻击者就无法猜中参数值。同时这也符合“不可预测性原则”。
     下面我们简单的来看看一个实例：在一个URL上简单的删除操作请求http://host/path/delete?username=abc&item=123456，这样的情况容易被攻击者猜到，如果对参数进行加密:http://host/path/delete?username=md5(salt+abc)&item=123456，这样攻击者很难得到salt值也就很难实现攻击。虽然这样做可防御CSRF攻击，同时也存在问题：加密后的URl非常难读，会给数据分析工作带来很大的困扰，因为数据分析工作常常用到的是明文。因此，我们需要一种更通用的方法来防御CSRF，那就是Anti CSRF Token。


      CSRF防御之Token
      讲之前先看上面的例子，我们保持原来的参数不变，新增一个token值，这个token值是随机的、不可预测的:http://host/path/delete?username=abc&item=123456&token=[random(seed)]。token值为用户和服务器所有，这个值可以放在用户的session中，或者浏览器的cookie中。有token值时，用户提交请求，服务器只需要验证表单中的token与用户session（或cookie）中的token值是否一致即可。由于攻击者无法再构造出一个完整的URL，那么CSRF攻击就无法实施。有了token并不是就可以高枕无忧了，例如攻击者可以通过XSS或者一些跨站漏洞窃取token值。因此一个好的安全防御体系是相辅相成，缺一不可的。
      token使用的一些原则
      1，token值要足够随机且不可预测
      2，在用户有效周期内，token消耗前使用同一个token，若消耗掉token则应重新生成一个token值，如果有多个页面共存的场景，应该考虑生成多个有效的token值
      3，token应该注意保密性，不应该出现在URL中，防止通过Referer方式泄露，因此token值应尽量放在表单中，且把敏感操作GET改为POST，以表单形式提交。