跨源資源共享（CORS） - 我在這里遺漏了什么？

Question

我正在閱讀有關CORS的內容 ，我認為實施既簡單又有效。

但是，除非我遺漏了什么，否則我認為該規范中缺少一大部分內容。 據我了解，根據請求的來源（以及可選地包括憑證）決定是否允許訪問其資源的外國站點。 這可以。

但是，如果頁面上的惡意代碼想要將用戶的敏感信息發布到外部站點，該怎么辦？ 外國站點顯然將驗證請求。 因此，如果我沒有遺漏某些東西，CORS實際上會更容易竊取敏感信息。

我認為如果原始網站還可以提供其頁面允許訪問的不可變服務器列表，那將更有意義。

所以擴展的序列將是：

1. 提供包含可接受的CORS服務器列表的頁面（abc.com，xyz.com等）
2. 頁面想要向abc.com發出XHR請求 - 瀏覽器允許這樣做，因為它在允許列表中並且身份驗證正常進行
3. Page想要向malicious.com發出XHR請求 - 請求在本地（即瀏覽器）拒絕，因為服務器不在列表中。

我知道惡意代碼仍然可以使用JSONP來完成其臟工作，但我認為CORS的完整實現意味着關閉腳本標記多站點漏洞。

我還檢查了官方的CORS規范（ http://www.w3.org/TR/cors ），但沒有找到任何關於這個問題的提及。

Answer 1

但是，如果頁面上的惡意代碼想要將用戶的敏感信息發布到外部站點，該怎么辦？

怎么樣？ 你可以在沒有CORS的情況下做到這一點。 即使回到Netscape 2，您也始終能夠通過簡單的GET和POST請求將信息傳輸到任何第三方站點，這些請求由接口引起，如form.submit() ， new Image或設置window.location 。

如果惡意代碼可以訪問敏感信息，那么您已經完全丟失了。

3）Page想要向malicious.com發出XHR請求 - 請求在本地拒絕

為什么頁面會嘗試向尚未列入白名單的網站發出XHR請求？

如果您正在嘗試防止因XSS漏洞而注入的惡意腳本的操作，那么您正在嘗試修復症狀，而不是原因。

Answer 2

您的擔憂完全有效。

然而，更令人擔憂的是，不需要存在任何惡意代碼來利用它。 有許多基於DOM的跨站點腳本漏洞，允許攻擊者利用您描述的問題並將惡意JavaScript插入到易受攻擊的網頁中。 問題不僅僅是數據可以發送的地方，而是可以從中接收數據的地方。

我在這里更詳細地討論這個問題：

• http://isisblogs.poly.edu/2011/06/22/cross-origin-resource-inclusion/
• http://files.meetup.com/2461862/Cross-Origin%20Resource%20Inclusion%20-%20Revision%203.pdf

Answer 3

在我看來，CORS純粹在擴展可能的東西，並試圖安全地進行。 我認為這顯然是一種保守的舉動。 在更安全的情況下對其他標簽（腳本/圖像）制定更嚴格的跨域策略會破壞大量現有代碼，並使采用新技術變得更加困難。 希望有一些事情可以解決這個安全漏洞，但我認為他們需要先確保一個簡單的過渡。

Answer 4

我還檢查了官方的CORS規范 ，但沒有找到任何關於這個問題的提及。

對。 CORS規范正在解決一個完全不同的問題。 你錯了，它會讓問題變得更糟 - 它使問題既不好也不壞，因為一旦惡意腳本在你的頁面上運行，它就已經可以在任何地方發送數據了。

好消息，不過，是有一個廣泛實施的規范，解決了這個問題： 內容安全-政策 。 它允許您指示瀏覽器限制頁面的功能。

例如，您可以告訴瀏覽器不要執行任何內聯腳本，這將立即擊敗許多XSS攻擊。 或者 - 正如您在此處所要求的那樣 - 您可以明確告訴瀏覽器允許頁面與哪些域聯系。

Answer 5

問題不在於網站可以訪問已有權訪問的其他網站資源。 問題是域之一 - 如果我在我的公司使用瀏覽器，並且ajax腳本惡意地決定嘗試10.0.0.1（可能是我的網關），它可能只是因為請求現在來自我的訪問電腦（也許是10.0.0.2）。

所以解決方案 - CORS。 我不是說它是最好的，但是解決了這個問題。

1）如果網關無法返回'bobthehacker.com'接受的原始標題， 則瀏覽器拒絕該請求。 這可以處理舊的或未准備好的服務器。

2）如果網關僅允許來自myinternaldomain.com域的項目，它將拒絕'bobthehacker.com'的ORIGIN。 在SIMPLE CORS的情況下，它實際上仍會返回結果。 默認情況下; 您可以將服務器配置為甚至不這樣做。 然后在不被瀏覽器加載的情況下丟棄結果。

3）最后，即使它接受某些域，您也可以控制接受和拒絕的頭，以使來自這些站點的請求符合某種形狀。

注意 - ORIGIN和OPTIONS標頭由請求者控制 - 顯然，創建自己的HTTP請求的人可以在其中放置他們想要的任何內容。 然而，現代的CORS兼容瀏覽器WONT可以做到這一點。 瀏覽器控制着交互。 瀏覽器阻止bobthehacker.com訪問網關。 那是你缺少的部分。

Answer 6

我分享大衛的擔憂。 必須逐層構建安全性，並且源服務器提供的白名單似乎是一種好方法。

此外，此白名單可用於關閉現有漏洞（表單，腳本標記等），可以安全地假設服務白名單的服務器旨在避免后向兼容性問題。