什么是CSRF攻击

本文收集整理了网上相关CSRF的资料，对CSRF攻击进行了一个整合的描述。CSRF作为一种颇具威胁的攻击手段，如果不进行防御，很有可能造成用户的经济损失和个人资料泄露。所以千万不能小看这个攻击，不知不觉就会对网站造成难以磨灭的伤害。

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

这里可以看下IBM developerworks的两篇文章：

• CSRF 攻击的应对之道
• Web 应用程序常见漏洞 CSRF 的入侵检测与防范

上面两篇文章不仅详细描述了什么是CSRF攻击，而且还有讲解相应的防御手段措施。以下资料转载和截取自上面的两篇文章：

CSRF 背景与介绍

CSRF（Cross Site Request Forgery, 跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一。其他安全隐患，比如 SQL 脚本注入，跨站域脚本攻击等在近年来已经逐渐为众人熟知，很多网站也都针对他们进行了防御。然而，对于大多数人来说，CSRF 却依然是一个陌生的概念。即便是大名鼎鼎的 Gmail, 在 2007 年底也存在着 CSRF 漏洞，从而被黑客攻击而使 Gmail 的用户造成巨大的损失。

CSRF 攻击实例

CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。

比如说，受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。

黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。

这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。

大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。

这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

CSRF 攻击的对象

在讨论如何抵御 CSRF 之前，先要明确 CSRF 攻击的对象，也就是要保护的对象。从以上的例子可知，CSRF 攻击是黑客借助受害者的 cookie 骗取服务器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的内容。另外，对于服务器返回的结果，由于浏览器同源策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。所以，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护。

另外微软MSDN上这篇文章也可以参考下： ASP.NET 安全 – 保护您的 ASP.NET 应用程序

跨站点请求伪造 (CSRF)

简介 跨站点请求伪造，即 CSRF（读作 sea-surf），是指有人利用您的浏览器和网站之间的信任关系使用无辜用户的会话执行命令时发生的攻击。

总结下这些文章防御CSRF攻击的防御措施

1. 使用token令牌，就是令牌验证机制，另外如果网站是使用ASP.NET MVC 框架开发的，可以参考这篇文章：ASP.NET MVC 如何防御CSRF攻击(跨站请求伪造)
2. HttpReferrer验证，验证Http Referer字段，判断请求来源（但是这个字段很容易被伪造）
3. 在 HTTP 头中自定义属性并验证
4. 确保攻击者不能通过简单地单击 GET 请求链接来重播请求。 针对 GET 请求的 HTTP 规范意味着 GET 请求应该只用于检索，而不应该用于状态修改。（就是比较重要的数据请求，最好使用POST请求）
5. 确保在攻击者已使用 JavaScript 模拟窗体 POST 请求的情况下不能重播请求。
6. 阻止通过 GET 执行的任何操作。 例如，禁止通过 URL 创建或删除记录。 理想情况下，这些措施需要一些用户交互。 尽管这种方法不能防范更精明的、基于窗体的攻击，但它可以限制大量较容易实现的攻击，例如电子邮件图像示例中描述的攻击类型以及 XSS 遭到破坏的网站中嵌入的基本链接。