是一个在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保护

回答

相关问题