Ajax与跨站点请求伪造漏洞

近日，我们的网站请微软的工程师作了一次漏洞扫描，扫描结果中有两个“跨站点请求伪造漏洞”。

通过查资料，我做了一番研究，包括此漏洞的入侵条件，被攻击后的损失以及防范措施等。

在不追求成功率的情况下，跨站点请求伪造的攻击成本相对较低，门槛儿也不高，有点姜太公钓鱼，愿者上钩的味道。

实际上，JE就从一定程度上存在此漏洞，不过根据我的实验结果，JE已经从很大程度上防范了此攻击，所以风险不大。

下面我来讲解一下如何利用JE的此漏洞干点儿坏事。

鉴于这里都是Ajax高手，以下说明中尽量避免出现代码，只说原理。

有兴趣的话自己动手一试便知。

攻击目标：让被攻击者A在自己不知情的情况下给B发送若干条站内短信。

步骤：
1. 确定JE发送站内短信的http请求地址，参数等。

你自己可以随便给一个好友发送一条站内短信，同时使用httpwatch或firebug记录请求内容即可。

2. 发布一个有诱惑性的网页，上面写些技术文章或者别的能吸引A的东西。

最重要的是，要有一个指向JE的超链接。

3. 在上述网页中跑一段JS代码，这段代码循环调用第1步中你记录的地址以及包含你自己构造的短信内容的请求参数。

注意，请求要用post方式发送，因为JE已经在发端信的请求处理上禁用了get方式。

至此，大功告成，剩下的就是等着A登录JE。

一旦他登录，你的JS代码就可以发起攻击了。

B下次上线后会收到A发送的若干条站内短信，而短信内容完全由你决定。

以上就是跨站点请求伪造的基本思路。

真的这么简单吗？当然不是，以上攻击需要至少两个条件才能成功。

首先，A要使用IE6这种经过他自己确认就可以跨站点发送请求的浏览器（所谓愿者上钩），而FF和chrome都不允许。

其次，A打开JE后没有关闭你的页面，这就要看你的造化了。

其实正是因为JE禁止了get请求，才使得这个攻击的成功率大打折扣。

如果其他被攻击的站点允许发送get请求，那么我们就可以大大地强化攻击。

那就是跨域的利器img和script。

只要给这两个html元素的src赋值，它们便会自动发起跨域请求，而且浏览器不会给出任何安全提示。

设想一个极其粗糙的银行网站如果具备被攻击的条件的话将会是什么后果？你完全不需要知道客户的卡号和密码就可以把他的钱轻松转帐了。

实际上早期的gmail就存在这样的漏洞，攻击者可以轻松搞到被攻击者的联系人列表。

如何防范呢？目前我了解的有两种思路。

方案一：每个请求都带上一个由服务器生成的随机参数。

然后在服务器端和对该参数，如果和下发的随机数不同，则可以认为有人在伪造请求。

因为攻击者无法知道他本次攻击的http请求需要带什么样的随机数才是有效的。

方案二：跨域伪造之所以能成功，主要决定因素是攻击者的页面和稍候被打开的目标页面共享session信息。

受害者登录后，攻击者的页面通过ajax向被攻击网站的关键业务发起的请求便自动带上了合法的session信息。

但是，根据javascript的同源策略可知，挂有A域名的窗口，不能获取挂有B域名窗口中的任何信息，不管B是如何被打开的。

据此，我们有了另一套防范策略。

在客户
端的每个要保护的业务链接上增加一个参数sessionId，这个参数可以通过js从cookie中获得。

然后，在务器端获取此参数，并同真正的sessionId做对比，如果不同，则认为请求是伪造的。

因为攻击者的窗口无法从被攻击网站的窗口中取得这个sessionId。

据说很多ajax框架都已经自带了此功能。

希望我已经把问题说清楚了，请大家讨论。

跨站点请求伪造（cross-site request forgery，XSRF）要求使用与前面描述的框架注入攻击类似的传送机制。

但是，XSRF 并不需要攻击者向用户显示任何欺骗性的内容。

相反，攻击者只需创建一个看似无害的Web站点，致使用户的浏览器直接向易受攻击的应用程序提交一个请求，执行某种有利于攻击者的"无意"操作。

前面说过，浏览器的同源策略并不阻止一个Web站点向另一个域发布请求的示例。

但是，它确实阻止提出请求的Web站点处理跨域请求的响应。

因此，与本站点请求伪造攻击不同，XSRF 攻击只是一种"单向"攻击。

所以，在纯粹的XSRF攻击中，要想实施Samy蠕虫中的多阶段操作是不可能的。

2004年，Dave Armstrong 在eBay 应用程序中发现一个典型的XSRF漏洞。

攻击者可以设计一个URL，使得请求这个URL的用户对某个拍卖品给出任意标价。

一个第三方Web站点可以诱使访问者请求这个URL，以致于任何访问这个Web站点的eBay 用户都会报出一个标价。

而且，进行调整后，我们还可以在相同eBay应用程序的一个保存型OSRF攻击中利用这个漏洞。

应用程序允许用户在拍卖品描述中插入<img>标签。

为防止攻击，应用程序确认标签目标返回一个真正的图像文件。

但是，攻击者也可以在上述位置插入一个指向站外服务器的链接（它在创建拍卖品时返回一幅合法的图像），并随后用一个返回他专门设计的XSR FURL的HTTP重定向代替这个链接。

因此，任何查看拍卖品的用户都会在不知情的情况下给出一个标价。

欲知攻击详情，请查阅最初在Bugtraq 上发表的文章：http://archive.cert.uni-stuttgart.de/bugtrag/2005/04 /msg00279.html。

注解应用程序确认站外图像方面的漏洞被称为"检查时间，使用时间"（TOCTOU）漏洞，因为某个数据在一个时间确认，却在另一个时间使用，使得攻击者能够在确认与使用时间间隔之间修改这个值。

1. 利用XSRF漏洞
XSRF漏洞主要出现在HTTP cookie被用于传送会话令牌的地方。

一旦应用程序已经在用户的浏览器中设定一个cookie，他们的浏览器会自动在随后的每个请求中将这个cookie 返回给应用程序。

无论请求是源自应用程序提供的一个链接、从其他地方（如电子邮件或另一个Web站点）收到的一个URL或者是其他来源，它都会这样做。

如果应用程序并未采取防范措施，防止令牌滥用，那么它就易于受到XSRF攻击。

渗透测试步骤
根据在应用程序解析过程中得到的结果（请参阅第4章了解相关内容），检查应用程序的关键功能。

找到一项应用程序功能，它可用于代表不知情的用户执行某种敏感操作，并且使用攻击者能够提前决定的请求参数，也就是说，其中并不包含任何会话令牌或其他无法预测的数据。

例如：
创建一个HTML页面，它不需要进行任何用户交互即可提出想要的请求。

对于GET请求，可以使用一个<img>标签，并通过src参数设置易受攻击的URL。

对于POST请求，可以建立一个表单，其中包含实施攻击所需全部相关参数的隐藏字段，并将其目标设为易受攻击的URL。

可以使用JavaScript在页面加载时自动提交该表单。

登录应用程序后，使用相同的浏览器加载专门设计的HTML页面。

确认应用程序是否执行想要的操作。

2. 防止XSRF漏洞
由于浏览器自动在随后的每个请求中将cookie返回给发布cookie的Web服务器，XSRF 漏洞因此产生。

如果一个Web应用程序主要依赖HTTPcookie 传送会话令牌，那么它本身就易于受到这种攻击。

只要不是以上述形式完全依赖于cookie传送会话令牌，就可以防止XSRF攻击。

电子银行这些最为注意安全的应用程序常常使用HTML表单中的隐藏字段传送会话令牌。

当每次提交请求时，应用程序除确认会话cookie 外，还核实表单是否传送了正确的令牌。

如果一个应用程序以这种方式运作，那么攻击者只有提前获悉在隐藏字段中传送的令牌值，才能实施XSRF攻击。

如果这样，那么攻击者已经劫持了用户的会话，根本不必实施任何XSRF攻击。

不要犯下错误，依靠HTTP Referer消息头指出一个请求是源自站内还是站外。

Referer可以使用旧版的Flash 修改或用一个元刷新标签（meta refresh tag）完全伪装。

通常而言，使用Referer消息头并不能为Web应用程序提供强大的安全防御基础。

在一些应用程序中，阻止XSRF 攻击的防御措施要求用户完成几个步骤，以执行转账之类的敏感操作。

如果这样，那么为实现有效防御，应用程序必须在多步骤处理过程中使用某种令牌或nonce。

通常，在第一个阶段，应用程序在一个隐藏表单字段中放入一个令牌；在第二个阶段，它确认这个令牌是否被提交。

由于XSRF攻击是单向性的，因此实施攻击的Web站点无法从第一个阶段获得令牌，然后在第二个阶段提交。

如果应用程序使用这两个步骤，但并不保证令牌的安全，那么这种防御就形同虚设，因为实施XSRF 攻击的攻击者只需轮流提出两个必要的请求，或者（常常是）直接进入第二个请求。

通过XSS突破反XSRF防御
人们常称，如果应用程序中包含任何XSS漏洞，那么反XSRF防御机制就可以被突破。

这种说法并不完全正确。

但是，支持这种观点的思考方法是正确的；因为XSS有效载荷在本站执行，可以与应用程序进行双向交互，所以它们能够从应用程序的响应中获取令牌，并在随后的请求中提交这些令牌。

然而，如果一个本身得到阻止XSRF 的防御机制保护的页面也包含反射型XSS漏洞，那么这
种漏洞并不能用于突破防御。

记住，在反射型XSS攻击中，最初的请求是一个跨站点请求。

这时，攻击者设计一个URL或者一个POST请求，其中包含随后被复制到应用程序的响应中的恶意输入。

但是，如果易受攻击的页面实施了反XSRF 防御，那么攻击者要想实施有效攻击，其专门设计的请求中必须已经包含必要的令牌。

如果其中没有所需令牌，应用程序将会拒绝攻击者提出的请求，同时包含反射型XSS漏洞的代码路径也不会执行。

这时，问题并不在于注入的JavaScript是否能够读取应用程序响应中的任何令牌（当然它能），而在于如何首先将JavaScript注入一个包含那些令牌的响应中。

通常，在下面两种情况下，可以利用XSS漏洞突破反XSRF防御。

如果受保护的功能中存在任何XSS漏洞，那么攻击者总可以利用这些漏洞突破反XSRF防御。

通过保存型攻击注入的JavaScript可直接读取包含在保存脚本的应用程序中的令牌。

如果应用程序仅对一部分通过验证的功能采用反XSRF 防御，并且一项未防御XSRF的功能中存在一个反射型XSS漏洞，那么攻击者就可以利用这个漏洞来突破反XSRF防御。

例如，如果一个应用程序仅采用反XSRF令牌保护转账功能的第二个步骤，那么攻击者就可以利用反射型XSS攻击从其他步骤中突破防御。

通过这个漏洞注入的一段脚本可以向第一个转账步骤提出一个站内请求，截取令牌，然后使用这个令牌进入第二个步骤。

攻击之所以能够成功，是因为第一个没有采取XSRF 防御的转账步骤返回了访问受保护页面所需的令牌。

仅依赖HTTPcookie 实现第一个步骤，意味着攻击者可以利用它访问保护第二个步骤的令牌，从而实施有效攻击。

朝阳区朝阳北路四季星河路6号。