白帽子讲Web安全（第 4 章 跨站点请求伪造（ CSRF ））

第 4 章 跨站点请求伪造（ CSRF ）

CSRF 的全名是 Cross Site Request Forgery，翻译成中文就是跨站点请求伪造。

4.1 CSRF 简介

4.2 CSRF 进阶

4.2.1 浏览器的 Cookie 策略

攻击者伪造的请求之所以能够被搜狐服务器验证通过，是因为用户的浏览器成功发送了 Cookie 的缘故。

浏览器所持有的 Cookie 分为两种：

1. “ Session Cookie ”，又称“临时 Cookie ”，保存在浏览器进程的内存空间中；
2. “ Third-party Cookie ”，也称为“本地 Cookie ”，保存在本地。

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

若 CSRF 攻击的目标并不需要使用 Cookie ，则也不必顾虑浏览器的 Cookie 策略了。

4.2.2 P3P 头的副作用（已于2018年8月30日作废）

尽管有些 CSRF 攻击实施起来不需要认证，不需要发送 Cookie ，但是不可否认的是大部分敏感或重要的操作是躲藏在认证之后的。因此浏览器拦截第三方 Cookie 的发送，在某种程度上来说 降低了 CSRF 攻击的威力。可是这一情况在“ P3P 头”介入后变得复杂起来。

P3P Header 是 W3C 制定的一项关于隐私的标准，全称是 The Platform for Privacy Preferences 。

如果网站返回给浏览器的 HTTP 头中包含有 P3P 头，则在某种程度上来说，将允许浏览器发送第三方 Cookie 。在 IE 下即使是 <iframe>、<script> 等标签也将不再拦截第三方 Cookie 的发送。

P3P头的信息，W3C 标准 https://www.w3.org/TR/P3P/

4.2.3 GET？POST？

在 CSRF 攻击流行之初，曾经有一种错误的观点，认为 CSRF 攻击只能由 GET 请求发起。因此很多开发者都认为只要把重要的操作改成只允许 POST 请求，就能防止 CSRF 攻击。

4.2.4 Flash CSRF

4.2.4 CSRF Worm

4.3 CSRF 的防御

4.3.1 验证码

验证码被认为是对抗 CSRF 攻击最简洁而有效的防御方法。

CSRF 攻击的过程，往往是在用户不知情的情况下构造了网络请求。而验证码，则强制用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制 CSRF 攻击。

但是验证码并非万能，很多时候，出于用户体验考虑，网站不能给所有地操作都加上验证码。因此，验证码只能作为防御 CSRF 的一种辅助手段，而不能作为最主要的解决方案。

4.3.2 Referer Check

Referer Check 在互联网中最常见的应用就是“防止图片盗链”。同理，Referer Check 也可以被用于检查请求是否来自合法的“源”。

Referer Check 的缺陷在于，服务器并非什么时候都能取到 Referer 。

4.3.3 Anti CSRF Token

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

4.3.3.1 CSRF 的本质

CSRF 为什么能够攻击成功？其本质原因是 重要操作的所有参数都是可以被攻击者猜测到的。

攻击者只有预测出 URL 的所有参数与参数值，才能成功的构造一个伪造的请求；反之，攻击者将无法攻击成功。

出于这个原因，可以想到一个解决方案：把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值。这是“不可预测性原则”的一种应用。

但是这个方法也存在一些问题。首先，加密或混淆后的 URL 将变得非常难读，对用户非常不友好。其次，如果加密的参数每次都改变，则某些 URL 将无法再被用户收藏。最后，普通的参数如果也被加密或哈希，将会给数据分析工作带来很大的困扰，因为数据分析工作常常需要用到参数的明文。

因此，我们需要一个更加通用的解决方案来帮助解决这个问题。这个方案就是使用 Anti CSRF Token 。

4.3.3.2 Token 的使用原则

防御 CSRF 的 Token，是根据“不可预测性原则”设计的方案，所以 Token 的生成一定要足够随机，需要使用安全的随机数生成器生成 Token 。

Token 的目的不是为了防止重复提交。

使用 Token 时应该注意 Token 的保密性。

CSRF 的 Token 仅仅用于对抗 CSRF 攻击，当 网站还同时存在 XSS 漏洞时，这个方案就会变得无效，因为 XSS 可以模拟客户端浏览器执行任意操作。

XSS 带来的问题，应该使用 XSS 的防御方案给予解决，否则 CSRF 的 Token 防御就是空中楼阁。安全防御的体系是相辅相成、缺一不可。

4.4 小结

CSRF 攻击是攻击者利用用户的身份操作用户账户的一种攻击方式。设计 CSRF 的防御方案必须先理解 CSRF 攻击的原理和本质。

根据“不可预测性原则”，我们通常使用 Anti CSRF Token 来防御 CSRF 攻击。在使用 Token 时，要注意 Token 的保密性和随机性。