CSRF 攻击是什么

说明: 本文大部分借鉴wiki-跨站请求伪造, 另一部分来自文章wiki-Cross-Site Request Forgery

定义

csrf 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造.是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。. CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应

攻击的细节

攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。补充: 还可能更改账号所绑定的邮箱地址或者密码等.

例子

假如 Alice 在 bank.com 向 Bob 汇款 10000, 那么攻击将会由以下两步骤组成:

• 创建一个 URL 或者 script
• 利用社交工程欺骗 Alice 执行代码

GET 场景

如果 bank.com 把查询参数放到 URL 中, 那么 Alice 向 Bob 转账的操作可以简化为如下:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria 根据 bank.com 网站请求的结构, 将 Bob 名字替换为她自己的, 还把金额变大:
http://bank.com/transfer.do?acct=MARIA&amount=100000

那么这个充满恶意的 URL ,被 Maria 放到 a 标签中, 并且利用欺骗语言吸引 Alice 点击:
View my Pictures!

或者放到一个 长度和宽度都为0 的图片的src 中(图片不用用户点击, 自己就发起请求):

如果这张图片放到邮件中, Alice 根本就不会发现什么. 然而浏览器还是会将请求提交到 bank.com 的后台中.

一个真实的事件是发生在2008 年的 uTorrent exploit

POST 场景

假设 bank.com 现在使用 post 请求来传递参数的, 那么这个请求可以简化为:

POST http://bank.com/transfer.do HTTP/1.1
...
acct=BOB&amount=100

这种情况下, a 标签和 img 标签都无法发送 post 请求, 但是可以使用 FORM 来完成:

我们还可以利用 JavaScript 来让文档载入的时候就发送这个请求:

.....

其他的 HTTP 请求方法场景

假设现在银行使用的是 PUT 将数据放到一个JSON 中发送到后台中:

PUT http://bank.com/transfer.do HTTP/1.1

{ "acct":"BOB", "amount":100 }

那么我们可以利用内嵌的 JavaScript :

幸运的是这段 PUT 请求并不会发送, 因为 同源策略 的限制. 除非你的后台设置了

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: PUT

总结

不论是 GET 请求还是 POST 请求, 如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失10000资金。

这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。