CSRF

漏洞原理

CSRF是跨站请求伪造，表面上与XSS相像，但XSS是利用合法用户获取其信息，而CSRF是伪造成合法用户，利用目标用户的合法身份(其实就是coookie)，以用户的名义执行某些非法操作(向服务器发送伪造请求)。

广义的CSRF是指CSRF不一定要借助受害用户的浏览器，黑客可以通过自己写一个脚本伪造出一个和真实的http请求一模一样的数据包发送给你的服务器，前提是你这个http接口中的所有参数都是可以预期的。

cookie分类

浏览器持有的cookie有两种，一种是“Session Cookie”，临时Cookie;另一种是“Third-party Cookie”，本地Cookie。

两者的区别在于，Third-party Cookie是服务器在Set-Cookie时指定了Expire时间，只有到了Expire时间后Cookie才会消失，所以这种Cookie会保存在本地；而Session Cookie则没有指定Expire时间，所以浏览器关闭后，Session Cookie就消失了。Session Cookie保存在浏览器进程的内存空间中，而Third-party Cookie则保存在本地。

如果浏览器从一个域的页面中，要加载另一个域的资源，由于安全原因，某些浏览器会阻止Third-party Cookie的发送。

隐患

如果CSRF攻击的目标需要使用cookie，那么则必须具备这两种cookie，部分浏览器处于安全考虑，默认禁止了浏览器在 <img>、<iframe>、<script>等标签中发送第三方cookie。但是还是有存在一些浏览器默认策略是允许发送第三方cookie的，这就有可能导致CSRF攻击成功。

P3P

P3P头

P3P(The Platform forPrivacy Prefrences Project)是一种被称为个人隐私安全平台项目的标准，能够保护在线隐私权，使Internet冲浪者可以在选择浏览网页时，是否被第三方收集利用自己的个人信息。

隐患点

设置了P3P头之后，对于cookie的影响会扩大到整个域中的所有页面。也就是说如果网站返回给浏览器的HTTP头中包含P3P头，将会允许浏览器发送第三方cookie

P3P头的介入可能会改变网站的隐私策略，使得<iframe>、<script>等标签在ie中不再拦截第三方cookie的发送，造成CSRF漏洞。

产生条件

用户在浏览器上登录自身信任网站a
浏览器获得了服务器传给自己的cookie并保存。
用户在网站a保持登录状态的情况下，打开了恶意网站b
恶意网站b返回给用户一些攻击性代码，伪造用户向a网站发送请求
携带着用户cookie信息的请求由网站b传给网站a，网站a接受到请求后以为是用户发起的请求，于是执行了恶意网站的恶意代码。

漏洞检测

通常是由于服务端没有对请求头做严格过滤引起的。最简单的检测方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

漏洞分类

get型CSRF漏洞

很多利用方法，各种标签都可以用。

<a herf="http://jiulin.space/csrf.php?password=123">伪造参数</a>

<iframe src="http://jiulin.space/csrf.php?password=123" style="display:none"></iframe>

<img src="http://jiulin.space/csrf.php?password=123">

POST型CSRF

可以在页面构造好一个form表单，然后使用js自动提交这个表单，攻击者甚至可以将这个页面隐藏在一个不可见的iframe窗口中，那么整个自动提交表单的过程对于用户也是不可见的。

漏洞关键

该漏洞攻击利用的核心是进行伪造请求，所以关键在于请求的参数和参数值，如果攻击者无法得知url的所有参数和参数值，那么就无谈构造一个伪造的请求。

所以CSRF攻击成功的关键所在就在于重要操作的所有参数都是可以被猜测到的。

防御方法

加入验证码

在POST的基础上可以再加一个验证码，用户每次提交数据时都需要在表单中填写验证码，这个方案大幅度的降低CSRF攻击，一些简单的验证码可能会被hacker破解，但一般情况下，验证码是很难被破解的。

验证Referer

在验证时添加一个Referer，判断请求的来源地址是否是当前网页，如果是，则可以认为该请求是合法的，否则就拒绝用户请求。

Anti CSRF Token

CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于cookie中，因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信总不存在于cookie之中。

在开发过程中我们可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务端进行token校验，如果请求中没有token或者token内容不正确，则认为是CSRF攻击而拒绝该请求。

绕过姿势

绕过token

利用逻辑错误绕过

应用程序有可能会在token存在或不为空的情况下检测token的有效性，这种情况下我们发送的请求不包含token或token值为空是可能绕过CSRF的防御。

利用检测不严格绕过

应用程序可能只检测token是否合法却不检测token是否与当前用户匹配，在难以获取受害者token值的情况下可以提交自己产生的token来绕过CSRF防御。

利用session固定绕过

有时候站点使用一个双提交cookie作为一个CSRF的防御措施。这个表明这个请求需要包含一个cookie，其值为随机token值，且同时在请求参数中也有一个字段值为该随机token值。如果值相同，那么请求是合法的。这种防御形式是非常常见的。

如果一个双提交cookie用在了防御措施中，那么这个应用有可能没有将有效的token保存在服务器端。所以它没有办法指定token是否合法，并且也有可能很少检查cookie中的token值和参数中token值是不是一样的。这代表你可以发送一个假token，然后仍然可以有效实施CSRF攻击。

利用XSS绕过

利用xss漏洞获取其cookie，查看存储在其中的token。

绕过Referer

当Referer为空时

可以移除Referer字段：

1 2	<mata name = "referrer" content = "no-referrer">

可以利用一些伪协议如data:、ftp://等，使用这些伪协议时html页面向任何http站点提交请求的话，这些请求的referer都是空的。

针对白名单的绕过

判断referer是某域的情况下，可以尝试在referer的url中将受害者域名置于二级域名区域或url目录区域。

判断referer是否存在某关键词，如果一个站点在referer字段中检测“jiulin.space”字段，那么可以构造“jiulin.space.hacker.com”或者“hacker.com/jiulin.space”来绕过。