更新：GWT 2.3引入了一個更好的機制來對抗XSRF攻擊。見http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.htmlGWT RPC - 它是否足以抵禦CSRF？
GWT公司RPC機制並在每個HTTP請求下面的東西 -
HTTP請求始終是一個POST，並且在服務器端GET方法拋出異常（方法不支持）。
另外，如果這些標頭沒有設置或者有錯誤的值，服務器將失敗處理，並且可能會出現「可能的CSRF？」異常。或者是這個效果的東西。
問題是：這足以防止CSRF嗎？有沒有一種方法來設置自定義標題和更改純粹的跨站點請求僞造方法中的內容類型？
如果這個GWT RPC正在被瀏覽器使用，那麼它對於CSRF是100％易受攻擊的。內容類型可以在html <form>元素中設置。 X-GWT-Permutation和X-GWT-Module-Base不在Flash的黑名單banned headers。因此可以使用閃存進行CSRF攻擊。您可以信任CSRF保護的唯一標頭元素是「引薦者」，但這並不總是最好的方法。儘可能使用基於令牌的CSRF保護。
下面是我寫的一些漏洞，應該對我所描述的晦澀攻擊提供一些啓示。一個閃光漏洞這將看起來像this和 here是一個js/html漏洞，它改變了內容類型。
我的漏洞是爲Flex 3.2編寫的，並且規則在Flex 4（Flash 10）中發生了變化。這裏是latest rules，大多數頭文件只能對POST請求進行操作。使用navigateTo()的CSRF
我不知道，如果有一個簡單的方法（我是在尋找出極大的興趣，也！），但至少似乎有以一些先進的方式來實現任意頭的任意跨站點請求：http://www.springerlink.com/content/h65wj72526715701/我沒有買過這篇論文，但是摘要和介紹確實聽起來很有趣。
也許有人在這裏已經閱讀了論文的完整版本，並且可以擴展一點點？
我提出了我寫的Flash源代碼，它修改了http頭併發布了利用csrf漏洞。 – rook 2010-04-10 00:15:11
@rook：但請重新發布。 – user2284570 2016-07-17 21:14:33
我知道我問過這個問題，但經過大約一天的研究（感謝來自Rook的指針！），我想我已經得到了答案。
GWT提供的開箱即用功能不會保護您免受CSRF的侵害。您必須採取記錄在Security for GWT Applications中的步驟來保證安全。
GWT RPC將「content-type」標頭設置爲「text/x-gwt-rpc; charset = utf-8」。雖然我沒有找到使用HTML表單設置的方法，但在Flash中這樣做很簡單。
自定義標頭-X-GWT-Permutation和X-GWT-Module-Base有點棘手。他們不能使用HTML進行設置。另外，他們不能使用Flash設置，除非您的服務器明確允許它在crossdomain.xml中。請參閱Flash Player 10 Security。
另外，當一個SWF文件，希望 發送自定義HTTP標頭的任何地方 比自己的主持人出身的其他 必須有 HTTP服務器上的策略文件到該請求被 發送。此策略文件必須 枚舉SWF文件的主機 來源（或更大的一組主機），因爲 被允許向該主機發送自定義請求 標頭。
現在，GWT的RPC有兩種口味。有舊的自定義序列化格式RPC和新的基於JSON的de-RPC。 AFAICT，客戶端代碼始終設置這些請求標頭。舊式的RPC現在不會在服務器端強制執行這些標頭，因此可能發生CSRF攻擊。新的de-RPC風格強制執行這些頭文件，因此可能或不可能攻擊它們。總的來說，我會說如果你關心安全性，確保你在你的請求中發送強烈的CSRF令牌，並且不要求依靠GWT來阻止它。
@sri，以下是用於設置標題的新規則：http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html您只能在POST上設置它們，而常見的是黑色根據您發佈的所有信息，可以使用我在跨站點文件上傳漏洞利用中使用的方法爲POST請求控制「X-GWT-Permutation」標題元素。 – rook 2010-04-13 16:52:40
查看更改'pragma：no-cache'標頭元素的示例代碼： http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html#URLRequestHeader%28%29 如果編譯我的代碼時遇到困難，您應該嘗試編譯示例。 – rook 2010-04-13 16:55:22
您的回答正是我一直在尋找的內容，但它可以追溯到2010年。我嘗試使用現代版本的閃存編寫針對舊式RPC的PoC CSRF攻擊。你知道這是否仍然有可能嗎？由於目標_doesn'_沒有_crossdomain，xml_。它看起來像我的Flash客戶端發送一個請求_crossdomain，xml_到服務器，意識到沒有這樣的文件，然後不繼續發出我的CSRF有效載荷。新版本的Flash基本上阻止了這種攻擊，即使在舊式的RPC上也是如此？ – Juicy 2016-07-19 15:48:05
GWT 2.3引入了一個更好的機制來對抗XSRF攻擊。請參閱GWT RPC XSRF protection
已更新該問題，這樣任何人訪問此頁面都可以輕鬆找到它。謝謝！ – 2011-09-08 07:12:38
是否有任何獨立方驗證當前（GWT 2.8.1）XsrfTokenServlet實現是否提供了一種防止XSRF的安全方法？ – user1050755 2017-05-18 13:26:36
XmlHttpRequest，Flash和其他一系列技術可以設置自定義瀏覽器標頭 - 但是同源策略將啓用並阻止其他站點發出請求。除非服務器具有寬鬆的crossdomain.xml，或者將Access-Control-Allow-Origin返回到任意網站，請求將如何工作？ 這隻會讓我們留下形式/圖像/ iframe等，其中same-origin-policy不適用。但我不知道他們可以設置自定義http標題的方式。 那麼，它是如何脆弱？ – 2010-04-09 18:56:24
..是的，我同意令牌基於csrf保護是最好的方式，但我想了解他們的方法的缺陷。 – 2010-04-09 18:57:08
@sri非常好的問題。爲了取消這個漏洞，你必須利用Flash的一個鮮爲人知的特性。我已經發布了2個用來描述我所描述的漏洞，我鼓勵你使用它們。 （如果您至少沒有易受攻擊的軟件，您可以看到POST請求正在發送到另一個域，但由於SOP，腳本無法「看到」響應） – rook 2010-04-09 20:24:31