我有一個RESTful API，它有@Consumes（MediaType.JSON）這樣的註釋 - 在這種情況下，CSRF攻擊在這樣的服務上仍然可行嗎？我一直在修改服務器端的CSRFGuard服務，或者從客戶端雙重提交。但是，當我嘗試使用FORM與enctype =「text/plain」POST請求，它不起作用。技術解釋here如果我在我的消費註釋中有MediaType.APPLICATION_FORM_URLENCODED，這將起作用。當我使用POST/PUT/DELETE動詞時，內容協商很有用，但仍然可以訪問可能需要查看的GET。啓用內容類型協商時，JAXRS安撫服務是否容易發生CSRF攻擊？
任何建議或輸入將是偉大的，也請讓我知道，如果你需要更多的信息。
乾杯
JAX-RS被設計成創建被認爲是無狀態的REST API。 跨網站請求僞造不是無狀態應用程序的問題。
Cross Site For Forryry的工作方式是有人可能會欺騙您點擊鏈接或在您的瀏覽器中打開一個鏈接，該鏈接將引導您訪問您登錄的網站，例如某個在線論壇。由於您已經登錄該論壇，攻擊者可以構建一個網址，如下所示：someforum.com/deletethread?id=23454
該論壇程序設計糟糕，會根據會話Cookie識別出您，將確認您有能力刪除該線程，並且實際上將刪除該線程。
一切都是因爲程序驗證您基於會話cookie（上更是以「記住我」的cookie）
REST風格的API有沒有餅乾，沒有狀態請求之間maintaned，所以沒有必要防止會話劫持。
您通常使用RESTFul api進行身份驗證的方式是發送一些額外的頭文件。如果有人欺騙您點擊指向寧靜API的網址，瀏覽器將不會發送額外的標頭，因此不存在任何風險。
總之 - 如果REST API的設計方式應該是無狀態的，那麼不存在跨站點僞造風險，也不需要CSRF保護。
您的RESTful API可能位於安全框架之後，如彈簧安全性，這意味着您需要由框架進行身份驗證。在這種情況下，它會寫入一個cookie來將您標識爲已通過身份驗證的用戶。一旦用戶被識別，那麼通常的服務調用GET/POST/DELETE/PUT數據將可用。所以在這種情況下，服務本身並不是無狀態的，但服務是在具有狀態的安全框架後面。無論如何，我的主要興趣是檢查當內容類型協商啓用時是否有人能夠執行CSRF攻擊，因爲我無法破解它。 – opensourcegeek
這將是一個糟糕的設計。 API客戶端可能是一些應用程序，而不是瀏覽器，並且不會期望收到cookie。在REST API中使用Cookie是非常糟糕的做法。 – Dmitri
當然，現在我們的API使用基本和基於表單的身份驗證來保護。因此，其他一些不是瀏覽器的應用程序通過基本身份驗證，它通過HTTPS在每個請求上發送用戶名和安全令牌。這些是由系統生成的用戶，他們可以訪問部分API。然而，在基於瀏覽器的應用程序中，我必須使用基於表單的身份驗證來驗證用戶。您可以避免通過用戶拖網捕捉每次請求中的委託人，如果其在第一次檢查後保留在會話中。 – opensourcegeek
添加另一個答案，因爲Dmitri的答案混合了服務器端狀態和Cookie。
如果您的服務器通過多個請求將用戶信息存儲在內存中，則應用程序不是無狀態的。這會降低橫向可伸縮性，因爲您需要爲每個請求找到「正確」的服務器。
Cookie只是一種特殊的HTTP頭。它們通常用於識別用戶會話，但不是每個cookie都意味着服務器端狀態。服務器也可以在不啓動會話的情況下使用cookie中的信息。另一方面，使用其他HTTP標頭並不一定意味着您的應用程序自動無狀態。如果您將用戶數據存儲在服務器的內存中，則不是。 Cookie和其他標題之間的區別在於瀏覽器處理它們的方式。對我們來說最重要的是，瀏覽器將在每個後續請求中重新發送它們。如果有人欺騙用戶提出他不想提出的請求，這是有問題的。
這是一個消耗JSON的API的問題嗎？是的，在兩種情況下：
enctype=text/plain：URL編碼的內容是沒有問題的，因爲結果不能有效的JSON。 text/plain是一個問題，如果您的服務器解釋的內容不是純文本而是JSON。如果您的資源注有@Consumes(MediaType.JSON)，則不應該有任何問題，因爲它不會接受text/plain，並且應該返回狀態415。 （請注意，JSON可能會在一天內變成有效的enctype，並且這將不再有效）。Access-Control-Allow-Origin: *。
有趣的知道沒有人對此有意見......或者我的問題不是很清楚嗎？ hmmm – opensourcegeek