Access-Control-Allow-Origin是否足以防止XSRF攻擊？

我們正在構建一個運行在JBoss中的Java Spring/Hibernate後端的應用程序。前端是AngularJS。Access-Control-Allow-Origin是否足以防止XSRF攻擊？

我們還沒有做任何事情來設置服務器端的XSRF令牌。我們也沒有（還沒有）要求允許其他域訪問我們的網絡資源。

我想我會試着看看我們的網站是否容易受到XSRF攻擊，所以我建立了一個惡意web應用程序，使用Angular的$ http.post（）發佈到我們的真實應用程序的網址之一。我登錄到真正的應用程序，然後我嘗試從惡意應用程序發佈。

在瀏覽器中我得到了一個401的響應和看到的錯誤：

XMLHttpRequest cannot load http://localhost:8080/user/delete. No 
'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://localhost:6543' is therefore not allowed access. The response 
had HTTP status code 401.

服務器端是不設置設置訪問控制允許來源的響應從而出現上述錯誤。

所以我的問題是，簡單地從響應頭中省略Access-Control-Allow-Origin足以防止XSRF攻擊？

即使Access-Control-Allow-Origin沒有設置，我是否仍然可以在我的網站上執行XSRF攻擊？如果是這樣如何？我想演示這個攻擊。

謝謝。

來源

2014-10-22 lostdorje

不，這是不夠的。即使瀏覽器提供了'Access-Control-Allow-Origin'錯誤，該請求仍然由瀏覽器完成。如果是由攻擊頁面中指定withCredentials：

$http.post(url, {withCredentials: true, ...})

那麼這個請求將被髮送到與受害人的身份驗證Cookie您的域名，這意味着要求http://www.example.com:8080/user/delete會成功。

而且，這一請求也可以不使用XHR標準的HTML表單製作：

<form method="post" action="http://www.example.com:8080/user/delete">

和JavaScript將只被用來提交表單而不是使請求本身。

保護您的系統免受CSRF攻擊的簡單方法是檢查自定義標頭，如X-Requested-With或Origin標頭。如果不啓用CORS服務器端，則無法發送X-Requested-With跨域。然而，Synchronizer Token Pattern仍然是CSRF預防的最強方法，因爲它不受瀏覽器插件（如previous flaw in Flash）中的缺陷的限制，該瀏覽器插件允許發送通常不可能從瀏覽器發送的頭文件。

來源

2014-10-23 11:00:22 SilverlightFox

太好了，謝謝。這正是我正在尋找的。 – lostdorje 2014-10-23 11:36:27

我可能說得太快了。將'withCredentials'設置爲true沒有任何效果。我還修改了$ httpProvider.defaults.headers.common ['X-Requested-With'] ='XMLHttpRequest'與'withCredentials'的組合，我無法想出讓請求成功的變體。 – lostdorje 2014-10-24 02:37:28

@lostdorje：確保您在瀏覽器中啓用了第三方Cookie，並且您可以驗證是否使用攔截代理髮送了Cookie（某些開發工具實際上並未顯示Cookie，因爲同源策略）。我[前幾天回答了一個非常類似的問題]（http://security.stackexchange.com/a/71082/8340），但是這是來自攻擊者的觀點。 – SilverlightFox 2014-10-24 09:48:31

Access-Control-Allow-Origin是否足以防止XSRF攻擊？

回答

相關問題