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,以表单形式提交。

你可能感兴趣的:(web安全,csrf,安全,web)