五、利用JavaScript将Cookie安全模型降低至同源策略
　　Cookie安全模型要比同源策略更安全一些，但是利用一些JavaScript，可以把cookie的域还原成跟同源策略的document.domain设置相同的安全级别，并且该cookie的path属性可以被完全绕过。
　　我们还是使用前面的大学webmail的例子，这里假设攻击者在http://public-pages.daxue.edu/~attacker/创建了一个web页面，同时该大学在http://webmail.daxue.edu/建有一个webmail系统。如果在http://webmail.daxue.edu/中的某个页面的document.domain="daxue.edu"，假设该页面为http://webmail.daxue.edu/badPage.html，那么攻击者可以通过诱导受害者到达http://public-pages.daxue.edu/~attacker/stealCookies.htm来窃取受害者的cookies，该页包含以下代码：
　　<script>
　　function stealCookies() {
　　var victimsCookies = document.getElementById("iLoveIframes").cookie;
　　sendCookiesSomewhere(victimsCookies);
　　}
　　</script>
　　<iframe id="iLoveIframes"
　　style="display:none"
　　src="http://webmail.daxue.edu/badPage.html">
　　类似的，如果攻击者的个人页面位于http://www.daxue.edu/~attacker/，webmail系统位于http://www.daxue.edu/webmail/，同时webmail的cookie中的路径被设为path=/webmail，那么，攻击者就可以通过诱使受害者浏览 http://www.daxue.edu/~attacker/stealCookies.html来窃取受害者的cookie，其中这个页面包含如下所示的恶意代码：
　　<script>
　　function stealCookies() {
　　var victimsCookies = document.getElementById("iLoveIframes").cookie;
　　sendCookiesSomewhere(victimsCookies);
　　}
　　</script>
　　<iframe id="iLoveIframes"
　　style="display:none"
　　src="http://www.daxue.edu/webmail/anyPage.html">
　　</iframe>
　　六、保护Cookie
　　利用Cookie安全模型中添加的特性，但是不要完全依赖Cookie安全模型中的添加的安全特性。只信任同源策略，并围绕同源策略来打造Web应用程序的安全性。
　　七、Flash的安全模型
　　Flash是一种流行的Web浏览器插件，它近来发行的版本中包含了很多复杂的安全模型以供开发人员根据自己的喜好进行定制。这里我们将介绍Flash的安全模型的各个方面，首先介绍的是JavaScript所不具备的那些特性。
　　Flash的脚本语言称为ActionScript，它与JavaScript非常类似，并且包含了一些从攻击者的角度看来非常感兴趣的一些类：
　　1.Socket类使开发人员可以创建至allowed域的原始TCP套按字连接，这可以用来达到各种目的，比如精心制作带有伪造的各种报头(例如referrer)的HTTP请求。此外，套按字也可用于扫描无法从外部访问的网络计算机和端口。
　　2.ExternalInterface类使开发人员可以从Flash运行浏览器中的JavaScript，以达到各种目的，例如读写document.cookie。
　　3.XML和URLLoader这两个类可以以某用户的名义发送HTTP请求(连带浏览器的Cookie)至allowed域，以达到各种目的，例如跨域请求。
　　默认时，Flash的安全模型与同源策略非常类似。即，来自于某个域腇lash应用只可以读取来自该域的响应。此外，Flash还对HTTP请求的发送做了一些安全限制，但是您可以经过Flash的getURL函数发送跨域的GET请求。此外，Flash不允许通过HTTP装入的Flash应用程序读取用HTTPS载入的响应。需要注意的是，如果在另一个域上的安全策略准许跟Flash应用程序所在域通信的话，Flash却允许跨域通信。安全策略通常是一个名为crossdomain.XML的XML文件，一般位于域的根目录下。从安全角度讲，最糟糕的策略文件可能是下面这样：
　　<cross-domain-policy>
　　<allow-access-from domain="*" />
　　</cross-domain-policy>
　　该策略允许任何Flash应用程序跟存放这个crossdomain.xml文件的服务器(跨域)通信。该策略文件可以任意取名，并且可以放在任何目录下。可以使用下列ActionScript代码加载任意的安全策略文件：
　　System.security.loadPolicyFile("http://public-" +"pages.univeristy.edu/crossdomain.xml");
　　如果它不在服务器的根目录中，那么该政策仅适用于该策略文件所在的目录以及该目录下的所有子目录。举例来说，假设策略文件位于http://public-pages.daxue.edu/~attacker/crossdomain.xml，那么该政策将适用于对http://publicpages.daxue.edu/~attacker/doEvil.html和http://public-pages.daxue.edu/~attacker/moreEvil/doMoreEvil.html的请求，而不对诸如http://public-pages.daxue.edu/~someStudent/familyPictures.html或http://public-pages.daxue.edu/index.html这样的页面有影响。
　　八、反射策略文件
　　策略文件会被Flash“宽大地”解析，因此，如果您可以构造一个会导致服务器发回一个策略文件的HTTP请求，Flash将接受该策略文件。举例来说，http://www.daxue.edu/CourseListing?format=js&amp;callback=这个Ajax请求
　　将得到如下所示的响应：
　　<cross-domain-policy><allow-access-from%20domain="*"/>
　　</cross-domain-policy>() { return {name:"English101",
　　desc:"Read Books"}, {name:"Computers101",
　　desc:"play on computers"}};
　　然后，您可以通过ActionScript加载该策略：
　　System.security.loadPolicyFile("http://www.daxue.edu/" +
　　"CourseListing?format=json&callback=" +
　　"< cross-domain-policy >" +
　　"< allow-access-from%20domain=/"*/"/ >" +
　　"< /cross-domain-policy >");
　　这样会导致该Flash应用程序能够得以跨域访问http://www.daxue.edu/。
　　也能您已经想到了，如果人们可以上载一个文件到包含一个不安全的策略文件的服务器并能够随后在通过HTTP进行检索的话，那么System.security.loadPolicyFile()函数也会跟这个策略文件关联起来。
　　总之，Flash将遵守任何包含跨域策略的文件，除非之前存在任何未闭合的标签或者扩展ASCII字符。注意，Flash Player会完全忽略MIME类型。
　　九、针对策略文件反射的保护措施
　　当把用户定义的数据返回给该用户时，应当把HTML中的大于号〉换码为>并且把字符<转换为<，或者直接将其删除。
　　十、结束语
　　在浏览器中已经建立了一些安全措施——即同源策略和Cookie安全模型。此外，一些浏览器插件，诸如Flash Player、Outlook Express 以及Acrobat Reader等，带来了更多的安全问题和安全措施。然而，如果攻击者可以强迫用户执行源自特定域的JavaScript的话，这些额外的安全措施总是倾向于削弱同源策略的力量。
　　跨站脚本攻击(XSS)技术能够强迫用户执行攻击者以受害者名义在某个域上选择的脚本，如JavaScript、VBScript、ActionScript，等等。XSS要求某个域上的Web应用程序能够提供(即供应、返回)被攻击者所控制的字符。因此，攻击者可以向页面注入代码，而这些代码将来会在这个有弱点的域的上下文中执行。攻击者精心构造出供受害者运行的恶意代码之后，他还必须诱骗受害者单击一个链接。该链接一经点击，马上就会启动攻击活动。这些内容将在下一篇中加以介绍。

上一页123下一页