爲什麼瀏覽器允許CSRF？

Question

我對網絡安全非常陌生，當我閱讀更多有關不同攻擊媒介的信息時，我的想法很容易讓他們首先被允許。這就像網絡被設計成具有破壞性的安全模式並且容易受到攻擊。

我也很驚訝於模糊和不準確的信息量。例如，起初單原產地政策聽起來不錯，然後我讀到它只適用於XHR，哦順便說一句，實際上並沒有阻止XHR交叉源POST，這是傳統的CSRF攻擊。很高興我一直在閱讀。

還有一個Origin頭文件，服務器可以使用它來確保請求來自正確的位置 - 但是oops，它在不同瀏覽器中設置不一致，如果未設置，則不能相當肯定，如果這是因爲一個相同的來源請求，或者只是沒有得到它的某些瀏覽器（可能是一個IMG標籤？）的請求類型。繼續閱讀。

所以權利似乎是在會話cookie中設置一個CSRF令牌，並將該令牌添加到窗體/鏈接，然後在提交時將它們與服務器端進行比較。在理論上（並且爲了這個問題可以排除所有XSS攻擊），另一個選項卡的CSRF嘗試可能會向包含該cookie的表單發出POST請求，但沒有將表單輸入元素設置爲匹配的令牌（因爲它無法從cookie中讀取令牌），因此服務器將拒絕該請求。工作但kludgy，並確保你永遠不會忘記檢查！

爲了保持這一想法在第二秒，這裏是我的問題 - 爲什麼瀏覽器發送會話cookie在一個請求中發出的頁面不是來源的cookie？

我的意思是，瀏覽器將拒絕發送cookie 到不同的領域有很好的理由，但很樂意從不同來源給他們？如果他們不這樣做會破壞嗎？它是否會成爲CSRF的強大防禦，只需要服務器去做他們正在做的事情 - 檢查有效的會話cookie？

編輯：也許這是一個嘗試改善情況？ https://tools.ietf.org/html/draft-west-origin-cookies-01

Answer 1

我非常新的網絡安全，併爲我閱讀更多關於 不同攻擊媒介，我真不可思議，他們被允許在 首位。這就像網絡設計的破壞性安全 模型，並容易受到攻擊。

所有真實的。它從來沒有被設計成首先是安全的。該網站最初設計爲一個靜態文檔管理和共享系統，該系統允許直接鏈接到不同機器上的資源。

你今天看到的動態網頁是一個雜牌。我們可以通過CSRF令牌，HTTP頭等來解決這個問題，但是如果你在沒有做這些事情的情況下建立一個動態網站，那麼它很可能會變得脆弱（並且讓像我這樣的人能夠工作）。

結帳its history in the Wikipedia article。

我也很驚訝於模糊和不準確的信息量。例如，對於 的例子，起初單一原產地政策聽起來不錯，然後我 認爲它只適用於XHR，哦，順便說一句，並不是 實際上阻止XHR交叉來源POST，這是傳統的CSRF 攻擊。很高興我一直在閱讀。

也主要是真的。同源策略也適用於窗口和框架（例如，如果exam​​ple.com包含iframe的iframe，example.com不能通過JavaScript更改example.org的內容）。是的，可以創建跨域XHR，但如果未啓用CORS，則無法讀取響應。這確實可以保護CSRF令牌不被盜用，但正如你所說，如果你不使用CSRF保護，那麼就會出現CSRF漏洞。

其他防禦措施（如adding a custom header）可用於緩解CSRF，因爲自定義標頭無法跨域發送。

XHRs以前不能訪問任何跨域的內容，這被認爲是太大的限制，因此CORS的出現。以前，無論如何，表單可以訪問不同的域名，因此不被視爲特別危險的操作。只要適當的控制措施到位，它仍然不是。

還有服務器可以使用，以確保 請求從正確的地方來了一個Origin標 - 但哎呀，它是跨瀏覽器設置 不一致，如果沒有設置，你不能是 相當肯定，如果這是因爲一個同源請求，或請求 類型，只是沒有得到它的某些瀏覽器（可能是一個IMG標籤？）。 繼續閱讀。

確實如此。請參閱this answer。

爲什麼將瀏覽器會話cookie在 從一個網頁，是不是cookie的由來起源的請求？

因爲很多事情會以其他方式破壞。有無數的表單被設計爲從靜態網站提交到進行後端處理的動態網站。

有一個新的standard for "same-site" cookies。一個不太乾燥的解釋是here。

基本上cookie可以設置一個新的屬性SameSite。在strict模式下，當原點不同時不發送cookie。在lax模式中，只有在方法是例如POST，這是CSRF漏洞主要存在的地方。

你鏈接到的是早期的草稿。