同源策略的威脅模型是什麼？

http://en.wikipedia.org/wiki/Same_origin_policy 同源策略的威脅模型是什麼？

相同的原產地策略可防止一個站點的腳本與另一個站點通話。維基說這是一個「重要的安全概念」，但我不清楚它阻止了什麼威脅。

據我所知，一個網站的cookies不應與另一個網站共享，但可以（並且）單獨實施。

CORS標準http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing提供了繞過相同原產地策略的合法系統。據推測，它不允許同一來源政策旨在阻止的任何威脅。

看着CORS，我更不清楚誰會受到保護。 CORS由瀏覽器強制執行，因此它不能保護瀏覽器的任何網站。這些限制是由腳本想要與之交談的站點決定的，所以它似乎無法保護任何站點的用戶。

那麼，什麼是相同的原產地政策？

來源

2011-07-19 Gordon Wrigley

作爲示例，它可以防止Farmville檢查您的銀行賬戶餘額。或者，更糟糕的是，將您要發送的表單（在輸入PIN/TAN之後）搞亂，以便獲得所有的錢。

CORS主要是一個網站的標準，確保他們不需要這種保護。它基本上說「任何網站的腳本都可以與我交談，沒有安全可能被破壞」。所以它確實允許SOP禁止的東西，在不需要保護的地方以及跨域網站都是有利的。考慮配合。

來源

2011-07-19 08:34:13 Waldheinz

如何在沒有訪問cookie的情況下執行此操作？或者我錯誤地保護了cookies？ –

可以通過將'withCredentials'請求屬性設置爲'true'來發送Cookie與CORS請求。由於JavaScript無論如何都可以訪問cookie，因此在那裏建立額外的障礙沒有任何好處。關於這個問題的一個很好的閱讀是在這裏：http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ – Waldheinz

該文章@EricLaw提到，「Same Origin Policy Part 1: No Peeking」是好的。

這就是爲什麼我們需要的「同源策略」一個簡單的例子：

有可能通過使用iframe（「內聯框架」的地方另一個HTML文檔中的一個框架，以顯示自己的網頁，其他網頁）。假設您顯示www.yourbank.com。用戶輸入他們的銀行信息。如果您可以閱讀該頁面的內部HTML（需要使用腳本），則可以輕鬆閱讀銀行帳戶信息和繁榮。安全漏洞。

因此，我們需要相同的來源策略來確保一個網頁無法使用腳本來讀取另一個網頁的信息。

來源

2012-05-27 18:40:32

同源策略的目的是爲了避免惡意網站M讀取信息從受信任的站點A使用A用戶的權限（即授權餅乾）的威脅。這是一個瀏覽器策略，而不是服務器策略或HTTP標準，旨在緩解其他瀏覽器策略的風險 - 在聯繫站點A時從站點A發送cookie。

請注意，沒有什麼可以阻止M在瀏覽器外部訪問A。它可以發送儘可能多的請求。但它不會這樣做，因爲A的未知用戶的權限可能會發生在瀏覽器中。

另請注意，政策禁止從的M頁從A讀取。它不會保護A服務器免受請求的影響。特別是，瀏覽器將允許跨域POSTS-cookie和全部從M到A。該威脅被稱爲Cross-Site Request Forgery;它不會被同源策略所緩解，因此服務器保護自己是非常重要的。

來源

2017-01-19 08:20:28

同源策略的威脅模型是什麼？

回答

相關問題