爲什麼跨域AJAX請求被標記爲「安全風險」？

默認情況下，瀏覽器不允許跨站點AJAX請求。爲什麼跨域AJAX請求被標記爲「安全風險」？

據我所知，一個不好設想的跨域請求可能是一個安全風險。如果我採用html或外部網站的javascript，並將其「呈現」到我的網站中，那就是一個問題。這個外部代碼可以用於很多不好的事情 - 比如訪問當前用戶的會話數據。

但如果我只請求JSON或XML數據，我用一個正確的庫來解析JSON（不只是使用eval）我怎麼也想不到，這將是一個安全隱患。可能發生的更糟的是，來自該網站的內容無法正確呈現。

我錯過了什麼？簡單地通過發送一些惡意數據來破壞讀取json/xml的頁面是否可能？

2012-02-10 kikito

'默認情況下，瀏覽器不允許跨站點requests.'這句話需要一點拋光。你在談論XHR嗎？你在說cookie嗎？因爲通常瀏覽器允許跨域請求：可以使用指向遠程域的錨點或表單，並且當用戶點擊此鏈接時，跨域請求將毫無問題地執行。 – 2012-02-10 13:01:30

可能的重複http://stackoverflow.com/q/9222822和http://stackoverflow.com/q/9169038 – Gumbo 2012-02-10 13:04:08

@DarinDimitrov你是對的。我改變了這句話。 – kikito 2012-02-10 16:14:32

的風險是不是發出請求的網站。

例如：

愛麗絲訪問她的銀行和日誌中
然後，她訪問邪惡網站。
邪惡的網站使用JavaScript來使Alice的瀏覽器，以請求她的銀行
她的銀行與Alice的賬戶細節應答，並將其傳遞給JavaScript
中的JavaScript，然後將它們傳遞到惡魔網站

簡而言之，它可以防止攻擊者從任何Alice擁有憑據的站點（以及防火牆之後的站點，例如Alice的企業Intranet）讀取私人數據。

請注意，這不會阻止不依賴於能夠從站點讀取數據的攻擊（CSRF），但是如果沒有相同來源策略，標準防禦對抗CSRF將很容易被破壞。

來源

2012-02-10 13:00:00 Quentin

你錯了。這不受同源策略的保護。 – Gumbo 2012-02-10 13:02:56

@Gumbo - 我發現了這個例子中的缺陷，並在您發表評論時進行編輯。 – Quentin 2012-02-10 13:08:09

嗯。如果我正確理解這一點，那麼您的意思是用戶會話在瀏覽器中共享？我的印象是服務器能夠區分不同的打開的窗口/標籤。「嘿，這個請求來自不同的窗口，返回未經授權的響應代碼」 - 種類。情況並非如此嗎？ – kikito 2012-02-10 16:32:57

你與你的第二點重新JSON/XML絕對正確的。在採取適當的預防措施時，從另一個域接收JSON沒有風險。即使服務器決定返回一些令人討厭的腳本，您也可以通過適當的數據解析來有效地管理風險。事實上，這正是JSONP攻擊如此受歡迎的原因（例如，請參閱twitter的搜索API）。

已經我們看到HTML5兼容的瀏覽器引入了跨域通信新的對象和標準（的postMessage - http://dev.w3.org/html5/postmsg/和跨來源資源共享 - http://www.w3.org/TR/cors/）。

來源

2012-02-10 13:06:26 osahyoun

這些是非常有趣的鏈接，謝謝！ – kikito 2012-02-10 16:25:18

我寧願這種類型的事情的處理方式與瀏覽器請求訪問您的麥克風，地理位置數據或網絡攝像頭的方式相同。只需在瀏覽器窗口頂部顯示一個欄，詢問example.com頁面的權限即可訪問data.example.com或mybank.com中的數據。如果您使用CORS或JSONP，那麼欄不會出現。如果你不這樣做，你會得到權限欄。 – TxRegex 2014-03-24 17:27:14

爲什麼跨域AJAX請求被標記爲「安全風險」？

回答

相關問題