2013-05-14 77 views
0

在添加了GWT RPC XSRF保護後,RPC調用中應該有什麼不同?GWT RPC XSRF保護

我跟着這個職位(GWT (2.4.0) + XSRFhttps://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf)中提到的變化,得到了GWT RPC XSRF上班,我看到我的RPC調用包裹在「com.google.gwt.user.client.rpc.XsrfToken」,然而我仍然可以攔截在提琴手中的請求,並改變請求讓我得到其他東西,我想在這種保護之後,我將無法做到這一點?

我可以改變getFirstURL在Fidder酒店原始請求讓我另一個有效參數,說:「getSecondURL

http://127.0.0.1:8888/myapp/|AC7025AD520A4366B89A555020174220|com.google.gwt.user.client.rpc.XsrfToken/4254043109|EC4AE16148312F61EB4C4DA365F2F4B2|com.myapp.service.MyService|getFirstURL 

回答

1

你描述的不是XSRF,這是一箇中間人。爲了防止MITM,人們必須使用HTTPS(或者簽名請求,但這在瀏覽器中是不切實際的,如果可能的話)。

爲了簡化,XSRF是關於攻擊者網站僞造受害者站點的跨站點請求(因此是名稱),並利用現有的cookie(或其他)來驗證用戶,從而獲得對其個人資料和/或代表他進行更改。爲了減輕這一點,服務器使用用戶會話驗證每個請求與會話相關聯的令牌,但這是請求有效載荷的一部分(cookie由瀏覽器自動添加,因此您不需要知道它必須由提出請求的一方知道令牌,攻擊者可能不知道有效的令牌)。

+0

謝謝湯姆,這有幫助!但是,那麼我如何在原始RPC請求中模擬XSRF攻擊,以及如何測試GWT RPC XSRF修復是否正常工作,需要一種方法來模擬這種攻擊? – Jay 2013-05-14 13:53:57