Same Origin Policy心得整理

最近被一個朋友念。問我這一年來做了什麼。感覺什麼都說不上來，但認真想了一下，這一年來也是做了很多學習、很多嘗試，也有了很多心得。這些零零碎碎的東西，如果不特別記錄下來，恐怕真的會覺得自己什麼都沒做。

即然如此，我就把最近做的一些學習留在這裡做分享吧。

===========

何謂Same Origin Policy？

https://www.w3.org/Security/wiki/Same_Origin_Policy
https://developer.mozilla.org/zh-TW/docs/Web/Security/Same-origin_policy

Same Origin Policy即同源政策。簡單的說，是現代瀏覽器增加的一種安全政策。要求瀏覽器確保網頁中不同來源的腳本與資源不會被交互存取。

其實在早期的瀏覽器中，是否能交互存取不是重要議題。因為當時的網頁技術還不夠強大、成熟，因此比較沒有注意到這個東西。交互存取反而讓網頁腳本的開發變得更為彈性...或是混亂。想得到的，就是保護各網站間的Cookie。

很快的，駭客們發現了跨站腳本攻擊(XSS)與各種新型態的XSS(比如跨站請求偽造(CSRF))攻擊。能利用交互存取的方便性從瀏覽網頁的羔羊身上偷取資料。駭客們只要設法讓自己的腳本被受害者讀取到，接下來就等於控制了羔羊的瀏覽器。此外，隨著網頁技術的成熟，新興的網頁技術讓網頁程式、腳本變得強大，這更助長了駭客的力量。一個強大的瀏覽器被控制了，就表示使用者的電腦或裝置也可能被控制。

XSS簡單的說就是駭客拿某個第三方的網站當跳板，讓瀏覽該網站的使用者執行到駭客的腳本，然後進行進一步的攻擊。實例就像是十幾二十年前的Javascript炸彈。駭客(這麼low，應該是怪客)，在留言板裡面留下一個Javascript，不斷的跳出警告或是新視窗。然後使用者讀到這個留言的時候，就會被不斷出現的警告或是新視窗搞到煩，甚至是瀏覽器或是電腦當機。

CSRF則是讓使用者讀到駭客更複雜的腳本。腳本的內容可能是呼叫銀行做轉帳。如果被害人正好通過了網路銀行的登入，那麼網路銀行可能會無法分判這個轉帳的請求是駭客的腳本發的？還是被害人發的？因為請求都來自同一個(被害人)、登入過的瀏覽器！(各位不用擔心使用網路銀行。這種攻擊已經行之有年。銀行大都已經有防範機制)

上述的兩類攻擊都有一個特點，就是要讓被害人讀到腳本並執行腳本。駭客的腳本被執行後，被害人瀏覽的網頁的內容根本是雙手奉上。

而同源政策(Same Origin Policy)的實行大幅度的減少這種情況的發生。理由是駭客要把讓被害人執行攻擊腳本是有一定難度的。首先是駭客要設法把腳本搬進中介網站，然後中介網站將腳本展示到被害人的瀏覽器。然而中介網站絕不會輕易的加進來路不明的腳本。同時，許多中介網站也開始檢查輸入的資訊，避免前述Javascript炸彈的情況發生。

這使得駭客只能從其他地方進攻。比如在現代瀏覽器多頁籤的功能下，從A頁攻擊B頁。這種場景通常是A網站的資安比較弱(或甚至是駭客自營的)，然後透過瀏覽器內部資源共享的功能(漏洞)和不同的頁籤做資源的交換。

這種情境下，駭客的腳本與中介網站將被瀏覽器認為是不同來源。因此可以切斷兩者之間的交互作用。進而保護網頁的使用者。

Same Origin Policy的影響

在同源政策的影響下，不同來源的資源、腳本，不會互通有無。瀏覽器負責將非法的存取擋下來。我們也經常可以看到Chrome、Firefox在做安全更新。有一些就是白帽駭客們找到了可以突破同源政策的手段。

然而，同源政策也會降低腳本的彈性。這要怎麼處理呢？底下有做一些說明。

突破Same Origin Policy

https://stackoverflow.com/questions/3076414/ways-to-circumvent-the-same-origin-policy

有一些應用會需要在不同源的腳本或網頁間互取資料。解決方案分兩類：宣告放棄同源保護，以及走其他通道。

如何放棄同源保護
https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS

在Http Header裡面增加「Access-Control-Allow-Origin」。這招叫CORS。

不是單純加上去就可以運作的。詳細可以自己Google查詢。或是看我上面提供的連結。

如何走其他通道突破同源保護

https://hackmd.io/s/H1cY3TTYe#
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

基本上就是用各種方法「間接」的去存取不同源的資源。比方A站的腳本把資源或狀態打到C站；B站的腳本則到C站去取。如果是指令的話，可以改成A站的腳本監聽C站是否有人下了命令。然後B站的腳本發命令到C站。

上面這招可行。但其實有一些更輕便的「定石」可以用。比如postMessage。postMessage就像是網頁頁面裡的Message Queue。開發人員可以透過丟Event到Queue裡面，或是監聽Queue裡面的Event進行兩個站的資源或腳本交互作用。同源政策似乎是認為Message Queue的操作與管理應該是開發人員自己能控制的，所以沒有強加管控。開發人員應自行控制什麼腳本可以被Event驅動、什麼資源可以因Event露出。