浅谈CSRF防御-基础篇

首先为什么是基础篇?
是不是还会有提高篇?

因为我现在CSRF学的只是一点皮毛
只是在这几天使用过程中有了一些基础的认识
所以想写下来记录一下
高手请轻喷 初学难免会犯错 有错请指出~~

至于提高篇 估计得很久后才会写
至少得对CSRF有了深入的认识

webp

CSRF(Cross Site Request Forgery, 跨站域请求伪造)是一种网络的攻击方式,该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点,从而在并未授权的情况下执行在权限保护之下的操作,有很大的危害性。然而,该攻击方式并不为大家所熟知,很多网站都有 CSRF 的安全漏洞。

接下来我会谈谈就我目前知道的几种防御方式

0X01 验证码

口味比较重,严重影响用户体验!一般只在重要步骤加。要绕过的话的结合实例分析,页面的js里有没有泄露验证码的生成方式,是不是通过Cookie计算的;一般没什么好的办法。

0X02 验证Referer

在 HTTP 头中有一个字段叫 Referer,它记录了该 HTTP 请求的来源地址。在通常情况下,访问一个安全受限页面的请求来自于同一个网站。在ie7+,FF3+的浏览器里基本是无法伪造Referer的,但是会记录用户的访问来源,有些用户可能会觉得侵犯了他们的隐私。绕过的话,我试了下,可以用a标签的rel属性设置不带referer的页面<a rel=noreferer> 更多rel属性可以戳文档@HTML5标签的rel属性;因为我发现有些设置了referer验证的站不带referer反而能成功过验证。

0X03 Token

可以看看 Django的官方文档 @Django Cross Site Request Forgery protection
把Token放在Cookie里,一开始我不是很理解,CSRF的时候会自动把用户Cookie带上,我就想,那这个Token有个JB用?一个这么流行的开源框架应该不会犯这么低级的错误吧。一定是我哪里没理解!对!一定是这样的。于是我开始各种搜索,终于搞懂了!原来POST提交的时候会把这个Token进行一次变换,而第三方站点提交的时候是不会变换而直接提交这个Token值,并且Cookie是私有的,第三方站点是无法读取和访问的,也就无法操作Token进行变换!于是巧妙地防御了CSRF!搜索的时候发现网上都说Django的CSRF防御能绕过,但是我搜索了半天也没找到怎么绕过,求好心人科普~~

目前接触到碰到的就这三种,有什么更高级的防御方式我们以后再议~~