Cross-Site Request Forgery (CSRF)

 

Cross-Site Request Forgery (CSRF)

此文摘自Cross-SiteRequest Forgery (CSRF), 01/9/2013,

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

介绍

CSRF是一种网络攻击，迫使终端用户在一个Web应用上执行并不期望的动作。攻击前用户已经通过此Web应用的认证（例如：已登录）。借助网络社交工具（比如邮件和聊天工具）的一点帮助，攻击者便可以让用户执行攻击者指派的动作。成功的CSRF攻击能危及普通用户的数据和操作。如果目标用户是管理员帐号，整个web应用就陷于危险境地。

 

CSRF 攻击有很多名称，包括 XSRF, SeaSurf, Session Riding, Cross-Site Reference Forgery, Hostile Linking。微软在相关文档中称之为One-Clickattack。

 

描述

CSRF诱骗受害人加载有恶意请求的页面。此处的“恶意“是指：利用受害者的ID和权限，执行不是受害人所期望的功能。比如修改受害人的email地址、家庭住址、密码、转账或者购买物品等等。CSRF通常针对的是能影响服务器端状态的功能，但是也用于访问敏感数据。

 

对于大部分网站而言，由于浏览器会自动把与网站相关的认证数据附加到请求中（比如用户的session cookie和IP地址等），所以一旦用户通过了网站的认证，单凭根据这些认证数据，网站是没法区分别出请求是恶意的，还是正常的。

 

正是通过此类途径，攻击者让受害者自己执行这些恶意的行为，比如：购买物品、修改帐号信息、检索帐号信息或者其他功能。

 

有时候，CSRF攻击可能被存放在防护薄弱的网站上。这些薄弱点称为 Stored CSRF flaw。实现的方法是：把包含攻击的IMG 或者 IFRAME tag存储在一个能接受HTML的数据域中，或者采用更加复杂的跨站脚本攻击机制。在网站上存储的CSRF攻击会产生更加严重的危害。因为包含攻击的页面通常是受害者常看的页面，而且受害者当时必定通过了网站认证。

 

针对CSRF攻击的防护措施

 

1.      请求中包含攻击者无法获得的，但是网站可以校验的数据，比如：

a.      涉及安全的HTTP请求包含一个秘密的与特定用户相关的token。攻击者无法在请求中填入正确的token。

 

b.      涉及安全的操作的HTTP请求中必须包含用户的认证数据，比如：支付密码。

 

2.      限制sessioncookie的生命周期，减少用户中着的风险。

 

上述内容来自

http://en.wikipedia.org/wiki/Cross-site_request_forgery

 

无效的防护措施

使用秘密的cookie

任何Cookie均会随每个HTTP请求递交到服务器。所有认证token均会递交，不管当时用户处于正常状态还是处于受骗状态。

只接受POST请求

错误的概念是，采用POST方法后，攻击者不能构造一个恶意的link，CSRF攻击也就无法成型。不幸的是，攻击者有诸多方法诱骗受害者递交一个伪造的POST请求。比如，攻击者可以在自己网站上设置一个页面，里面有包含隐患值的form。这个form由JavaScript自动递交或者由受害者点击后递交。

例子

有很多途径诱拐终端用户从某个Web应用加载信息或者向此网站递交信息。为了执行这么一个攻击，首先必须明白如何产生一个恶意的HTTP请求，让受害人执行。考虑以下例子：Alice想从bank.com给Bob转100元钱。Alice产生的HTTP请求有可能类似于：

 

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

...

...

...

Content-Length: 19;

 

acct=BOB&amount=100

 

但是Maria 观察到bank.com也能通过以下GET方式执行转账功能：

 

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

 

Maria 决定利用这个安全薄弱点让Alice上当。 Maria 先构造了以下URL，让Alice转10万元到自己的帐号(MARIA的)。

 

http://bank.com/transfer.do?acct=MARIA&amount=100000

 

好了,剩下的事情是：Maria必须诱骗Alice提交这个HTTP请求。最简单的方式是发给Alice一个HTML格式的电子邮件，包含以下代码：

 

<ahref="http://bank.com/transfer.do?acct=MARIA&amount=100000">看一下我的新照片吧!</a>

 

如果Alice在bank.com的登录状态中点击这个link，就会转款十万给Maria。但是，有个麻烦事：一旦点击完成，Alice会看到转账结果页面。因此，狡猾的Maria决定通过以下方式把它隐藏在一个0字节的图片中：

 

<imgsrc="http://bank.com/transfer.do?acct=MARIA&amount=100000"width="1" height="1" border="0">

 

Maria把这个tag包含在email中。Alice查看邮件的时候，只会发现一个小方框，提示浏览器不能显示此图片，但是浏览器在尝试显示图片时已经自动把转账请求发给了bank.com。由于没有接受到正确的图片数据（实际上网站返回的是转账结果），浏览器只好显示一个小方框。Maria终于神不知鬼不觉地把Alice给蒙了！