是一個在Google App Engine上運行的GWT應用程序，受CSRF保護

我正在開發一個在Google App Engine上運行的GWT應用程序，並想知道我是否需要擔心跨網站請求僞造或者是否會自動照顧我？是一個在Google App Engine上運行的GWT應用程序，受CSRF保護

對於需要驗證每一個RPC請求，我有以下代碼：

public class BookServiceImpl extends RemoteServiceServlet implements 
BookService { 
    public void deleteInventory(Key<Inventory> inventoryKey) throws NotLoggedInException, InvalidStateException, NotFoundException { 
     DAO dao = new DAO(); 
      // This will throw NotLoggedInException if user is not logged in 
     User user = dao.getCurrentUser(); 
      // Do deletion here 
    } 
} 

public final class DAO extends DAOBase { 
    public User getCurrentUser() throws NotLoggedInException { 
      currentUser = UserServiceFactory.getUserService().getCurrentUser(); 
      if(currentUser == null) { 
       throw new NotLoggedInException(); 
      } 
     return currentUser; 
    }

我無法找到如何在UserService檢查認證的任何文件。依靠上面的代碼還是需要更多？我在這個初學者，但是從我的理解，以避免CSRF攻擊的一些策略是：

增加一個認證令牌請求負載，而不是僅僅檢查一個cookie
檢查HTTP Referer標頭

我可以看到，我已經從谷歌設定是什麼樣子的SID值餅乾，但我可以從序列化的Java對象的有效載荷，如果被通過或不令牌不出來。我也不知道Referer頭是否被使用。

那麼，我擔心一個非問題？如果不是，這裏最好的策略是什麼？這是一個常見的問題，必須有標準的解決方案在那裏......

來源

2010-06-05 user27478

如果你要把相同的代碼放在一個普通的servlet中，你肯定會容易受到XSRF的攻擊。但是由於您使用的是GWTs RemoteServiceServlet - 答案取決於您使用的GWT版本。

從尚未發佈的GWT 2.1開始，RPC機制添加請求標頭並驗證RemoteServiceServlet中是否存在這些標頭。 This has its limitations - 特別是，舊版本的Flash允許您從不同域發送請求標頭，但它確實會讓潛在攻擊者變得更加困難。

如果您想充分保護自己免受XSRF的傷害，請參閱Lombardi's Development blog。博客討論了兩種技術。首先是一個簡單的變化，端口2.1更改爲舊版本的GWT。第二種方法要求將會話標識符作爲請求參數進行復制，並且是防止XSRF的推薦方法。

參考

來源

2010-06-05 17:01:46

是一個在Google App Engine上運行的GWT應用程序，受CSRF保護

回答

相關問題