谨慎能捕千秋蝉（二）——CSRF

CSRF（Cross Site Request Forgery）跨站点请求伪造。

CSRF的本质是当重要操作的参数都能被攻击者预测到，才能成功伪造请求。

一、场景演示

下图是一个伪造请求的场景，按顺序来看；

1、2是正常登陆并产生Cookie，3、4是在登陆后访问骇客的网站并发请求，5是服务器执行骇客发出的请求。

这个场景的关键就是带上Cookie伪造请求。

1）浏览器中的Cookie

浏览器有“Session Cookie”（临时Cookie）和“Third-party Cookie”（本地Cookie）；

前者浏览器关闭后就失效了，后者指定了Expire时间，只有超过了时间才会失效。

默认会拦截“Third-party Cookie”的有IE6、IE7、IE8、Safari；

不会拦截的有Firefox、Opera、Chrome等，我就验证了Firefox、Chrome、以及IE8。

2）验证浏览器的支持

设计两个域名“www.normal.net”（正常的网站）和“www.csrf.net”（伪造的网站）

1. 访问“www.normal.net/cookie.php”页面，在cookie.php中设置Cookie，用PHP代码实现。

<?php
    setcookie("cookie1",'session');
    setcookie("cookie2",'third',time()+3600*24);

2. 接着访问“www.csrf.net/csrf.html”，在csrf页面中添加了一个iframe，通过iframe访问normal网站。

<iframe src="http://www.normal.net"></iframe>

3. 查看用iframe访问normal网站中的请求头信息，Cookie只有IE8会拦截，接下来会说明一种绕过拦截的方法。

Firefox
Chrome
IE8

3）P3P头

P3P头（Platform for Privacy Preferences Project）隐私偏好项目平台，通过加这个头，可以让IE不拦截第三方Cookie。

不过IE11以及Microsoft Edge将不在支持P3P头。

1. 还是用PHP来实现，与上面的不同之处用加红区分。

<?php
    header("P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR");
    setcookie("cookie1",'session');
    setcookie("cookie2",'third',time()+3600*24);

2. 请求“www.normal.net/cookie.php”页面，响应头中有下面一句话。

3. 在iframe中访问normal网站的请求头中出现了两个Cookie。

4）GET或POST请求

HTML中能够设置src/href的标签都可以发起一个GET请求，例如上面的攻击通过iframe的src属性发起的。

<link href=""/>
<img src=""/>
<meta http-equiv="refresh" content="0; url="/><!--HTML重定向-->
<script src=""></script>
<a href=""></a>
<video src=""></video>
<audio src=""></audio>
...

攻击者还可以通过伪造表单来执行POST请求，例如在一张页面中布置好输入框、选择框等标签，通过JavaScript自动提交。

二、CSRF的危害

1）篡改目标网站上的用户数据

2）盗取用户隐私数据

3）作为其他攻击的辅助手法

4）传播CSRF蠕虫

例如某个社交网站爆出的漏洞，让某个用户查看恶意页面后，给他所有好友发送短信，短信中又包含了这个恶意页面；

好友点击的话，又会给他的好友发送短信，这样就开始了传播，受感染的人也将越来越多。

CSRF蠕虫的原理和XSS蠕虫基本类似，但也略有不同：

1. CSRF的攻击代码存在于攻击者页面中，目标网站传播的内容都包含攻击者页面的URL。还有前提，目标用户登录了目标网站，之后的传播需要带上目标用户的“Session Cookie”。

2. XSS的攻击代码存在于目标页面中，即使是Script从攻击域上引进来的，对JavaScript上下文来说，也属于目标网站。

三、CSRF的防御

1）验证码

CSRF的过程，往往是在用户不知情的请求下发起了网络请求；

而加了验证码，就让用户必须与应用进行交互，才能完成最终请求，能够遏制CSRF的攻击。

但是加了验证码后，在用户体验上面会大打折扣，所以要因地制宜。

2）Referer Check

Referer Check常用于“防止图片盗链”，同理，也可以检查请求是否来自合法的“源”。

但Referer Check有缺陷，服务器并非任何时候都能取到Referer，例如HTTPS跳转到HTTP，就不会发送。

3）Anti CSRF Token

在每个请求中增加一个Token参数，这个Token是个随机数，为用户和服务器共同持有，不能被第三者知晓。

Token可放在用户的Session或Cookie中，为了使用方便，还可设置一个生命周期

在提交请求的时候，服务器只需验证表单中的Token和Session（或Cookie）中的Token是否一致即可遏制CSRF攻击。

但在XSS的攻击下，Token会无效，因为XSS可以模拟客户端浏览器执行任意操作，那就可以读取出Token，再构造一个合法的请求，这个过程称为XSRF。

4）SameSite属性

SameSite是Cookie的一个属性，可让Cookie在跨站请求时不被传送，从而就能阻止CSRF攻击。它有三个值：

（1）None：浏览器会在同站请求、跨站请求下继续传送Cookie。

（2）Strict：浏览器将只传送相同站点请求的Cookie，即当前网页URL与请求目标URL完全一致。

（3）Lax：默认选项，允许部分跨站请求带Cookie，但Form提交或Ajax请求是不会传送Cookie的。

demo代码下载：

http://download.csdn.net/download/loneleaf1/9746890

参考资料：

zenphoto csrf 攻陷

用P3P header解决iframe跨域访问cookie[各种语言]