一、CSRF介绍

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“OneClick Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。

上图为CSRF攻击的一个简单模型，用户访问恶意网站B，恶意网站B返回给用户的HTTP信息中要求用户访问网站A，而由于用户和网站A之间可能已经有信任关系导致这个请求就像用户真实发送的一样会被执行。

二、CSRF攻击的危害

攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 

如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子Samy利用css的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy 是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博上面。

如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

三、CSRF攻击原理及过程

1 、用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2、在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3、用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4、网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5.、浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

举例：

简单版：

假如博客园有个加关注的GET接口，blogUserGuid参数很明显是关注人Id，如下：

那我只需要在我的一篇博文内容里面写一个img标签：

那么只要有人打开我这篇博文，那就会自动关注我。

升级版：

假如博客园还是有个加关注的接口，不过已经限制了只获取POST请求的数据。这个时候就做一个第三方的页面，但里面包含form提交代码，然后通过QQ、邮箱等社交工具传播，诱惑用户去打开，那打开过博客园的用户就中招了。

在说例子之前要纠正一个iframe问题，有人会直接在第三方页面这样写。如下：

这样是用问题的，由于同源策略的原因，iframe内容根本加载不出来，所以里面form提交当然不会执行。

PS：我尝试了chrome、IE11、Firefox，情况都是这样。

所以可以用嵌多一层页面方式解决，如下：

第一个展示页面（test）：

第二个隐藏页面（test2）：

这样就可以解决了，有人会问为什么要加多一层iframe，因为不嵌iframe页面会重定向，这样就降低了攻击的隐蔽性。另外我们test页面不使用XMLHTTPRequest发送POST请求，是因为有跨域的问题，而form可以跨域post数据。

进阶版：

假如博客园还是有个加关注的接口，已经限制POST，但博文内容是直接贴进HTML（未过滤），那就遭受XSS攻击。那么就可以直接把上面代码嵌入博文，那么只要有人打开我这篇博文，还是会自动关注我，这组合攻击方式称为XSRF。

四、CSRF漏洞检测

检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder。

以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下：

使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。

五、CSRF漏洞防御

目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。

1、尽量使用POST，限制GET

GET接口太容易被拿来做CSRF攻击，看第一个示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。

接口最好限制为POST使用，GET则无效，降低攻击风险。

当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样就增加暴露的可能性。

2、浏览器Cookie策略

IE6、7、8、Safari会默认拦截第三方本地Cookie（Third-party Cookie）的发送。

但是Firefox2、3、Opera、Chrome、Android等不会拦截，所以通过浏览器Cookie策略来防御CSRF攻击不靠谱，只能说是降低了风险。

PS：Cookie分为两种

Session Cookie（在浏览器关闭后，就会失效，保存到内存里），

Third-party Cookie（即只有到了Exprie时间后才会失效的Cookie，这种Cookie会保存到本地）。

PS：另外如果网站返回HTTP头包含P3P Header，那么将允许浏览器发送第三方Cookie。

3、加验证码

验证码，强制用户必须与应用进行交互，才能完成最终请求。在通常情况下，验证码能很好遏制CSRF攻击。

但是出于用户体验考虑，网站不能给所有的操作都加上验证码。

因此验证码只能作为一种辅助手段，不能作为主要解决方案。

4、Referer Check

Referer Check在Web最常见的应用就是“防止图片盗链”。

同理，Referer Check也可以被用于检查请求是否来自合法的“源”（Referer值是否是指定页面，或者网站的域），如果都不是，那么就极可能是CSRF攻击。

但是因为服务器并不是什么时候都能取到Referer，所以也无法作为CSRF防御的主要手段。

但是用Referer Check来监控CSRF攻击的发生，倒是一种可行的方法。

5 、Anti CSRF Token

现在业界对CSRF的防御，一致的做法是使用一个Token（Anti CSRF Token）。

例子：

（1）用户访问某个表单页面。

（2） 服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。

（3）在页面表单附带上Token参数。

（4）用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。

这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。

注意：

CSRF的Token仅仅用于对抗CSRF攻击。当网站同时存在XSS漏洞时候，那这个方案也是空谈。

所以XSS带来的问题，应该使用XSS的防御方案予以解决。

特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

（5）在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。

然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

六、XSS

XSS（cross-site scripting跨域脚本攻击）攻击是最常见的Web攻击，其重点是“跨域”和“客户端执行”。XSS攻击分为三种，分别是：

• Reflected XSS（基于反射的XSS攻击）

• Stored XSS（基于存储的XSS攻击）

• DOM-based or local XSS（基于DOM或本地的XSS攻击）

Reflected XSS

基于反射的XSS攻击，主要依靠站点服务端返回脚本，在客户端触发执行从而发起Web攻击。

例子：

1、做个假设，当亚马逊在搜索书籍，搜不到书的时候显示提交的名称。

2、在搜索框搜索内容，填入“<script>alert('handsome boy')</script>”, 点击搜索。

3、当前端页面没有对返回的数据进行过滤，直接显示在页面上， 这时就会alert那个字符串出来。

4、进而可以构造获取用户cookies的地址，通过QQ群或者垃圾邮件，来让其他人点击这个地址：

PS：这个地址当然是没效的，只是举例子而已。

结论：

如果只是1、2、3步做成功，那也只是自己折腾自己而已，如果第4步能做成功，才是个像样的XSS攻击。

开发安全措施：

1. 前端在显示服务端数据时候，不仅是标签内容需要过滤、转义，就连属性值也都可能需要。

2. 后端接收请求时，验证请求是否为攻击请求，攻击则屏蔽。

标签：

转义：

属性：

如果一个input的value属性值是

就可能出现：

点击input导致攻击脚本被执行，解决方式可以对script或者双引号进行过滤。

Stored XSS

基于存储的XSS攻击，是通过发表带有恶意跨域脚本的帖子/文章，从而把恶意脚本存储在服务器，每个访问该帖子/文章的人就会触发执行。

例子：

1. 发一篇文章，里面包含了恶意脚本

2. 后端没有对文章进行过滤，直接保存文章内容到数据库。

3. 当其他看这篇文章的时候，包含的恶意脚本就会执行。

出现这种情况。

结论：

后端尽可能对提交数据做过滤，在场景需求而不过滤的情况下，前端就需要做些处理了。

开发安全措施：

1. 首要是服务端要进行过滤，因为前端的校验可以被绕过。

2. 当服务端不校验时候，前端要以各种方式过滤里面可能的恶意脚本，例如script标

签，将特殊字符转换成HTML编码。

DOM-based or local XSS

基于DOM或本地的XSS攻击。一般是提供一个免费的wifi，但是提供免费wifi的网关会往你访问的任何页面插入一段脚本或者是直接返回一个钓鱼页面，从而植入恶意脚本。这种直接存在于页面，无须经过服务器返回就是基于本地的XSS攻击。

例子1：

1. 提供一个免费的wifi。

1. 开启一个特殊的DNS服务，将所有域名都解析到我们的电脑上，并把Wifi的DHCP-DNS设置为我们的电脑IP。

2. 之后连上wifi的用户打开任何网站，请求都将被我们截取到。我们根据http头中的host字段来转发到真正服务器上。

3. 收到服务器返回的数据之后，我们就可以实现网页脚本的注入，并返回给用户。

4. 当注入的脚本被执行，用户的浏览器将依次预加载各大网站的常用脚本库。

这个其实就是wifi流量劫持，中间人可以看到用户的每一个请求，可以在页面嵌入恶意代码，使用恶意代码获取用户的信息，可以返回钓鱼页面。

例子2：

1. 还是提供一个免费wifi

2. 在我们电脑上进行抓包

3. 分析数据，可以获取用户的微信朋友圈、邮箱、社交网站帐号数据（HTTP）等。

PS：这个是我的测试，在51job页面登录时进行抓包，可以获取帐号密码。

结论：

这攻击其实跟网站本身没有什么关系，只是数据被中间人获取了而已，而由于HTTP是明文传输的，所以是极可能被窃取的。

总结

XSS攻击的特点就是：尽一切办法在目标网站上执行非目标网站上原有的脚本（某篇文章说的）。本地的XSS攻击的示例2其实不算XSS攻击，只是简单流量劫持。前两种XSS攻击是我们开发时候要注意的，而流量劫持的则可以使用HTTPS提高安全性。