Ajax和跨站点请求伪造漏洞.docVIP

近日，我们的网站请微软的工程师作了一次漏洞扫描，扫描结果中有两个“跨站点请求伪造漏洞”。通过查资料，我做了一番研究，包括此漏洞的入侵条件，被攻击后的损失以及防范措施等。 在不追求成功率的情况下，跨站点请求伪造的攻击成本相对较低，门槛儿也不高，有点姜太公钓鱼，愿者上钩的味道。实际上，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标签。为防止攻击，应用程序确认标签目标返回一个真正的图像文件。但