3

我正在开发一个在 Google App Engine 上运行的 GWT 应用程序，并且想知道我是否需要担心跨站点请求伪造或者是否会自动为我处理？

对于每个需要身份验证的 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 攻击，一些策略是：

  1. 在请求有效负载中添加身份验证令牌，而不仅仅是检查 cookie
  2. 检查 HTTP Referer 标头

我可以看到我从 Google 设置了带有 SID 值的 cookie，但是我无法从有效负载中的序列化 Java 对象中判断是否传递了令牌。我也不知道是否使用了Referer 标头。

那么，我是否担心没有问题？如果不是，这里最好的策略是什么？这是一个足够普遍的问题，必须有标准的解决方案......

4

1 回答 1

6

如果您将相同的代码放在常规 servlet 中，您肯定会受到 XSRF 的攻击。但是由于您使用RemoteServiceServlet的是 GWT - 答案取决于您使用的 GWT 版本。

从尚未发布的 GWT 2.1 开始，RPC 机制添加请求标头并验证 RemoteServiceServlet 中是否存在这些标头。这有其局限性——特别是旧版本的 flash 允许您从不同的域发送请求标头，但这确实使潜在攻击者的事情变得更加困难。

如果您想充分保护自己免受 XSRF 的侵害，请参阅Lombardi 的开发博客。该博客讨论了两种技术。第一个是简单的更改，将 2.1 端口更改为旧版本的 GWT。第二种方法需要将会话标识符复制为请求参数，并且是防止 XSRF 的推荐方法。

参考

  1. GWT RPC - 它是否足以防止 CSRF？
  2. 关于 GWT RPC 和 XSRF 的 Lombardi 开发博客
  3. GWT 应用程序的安全性
于 2010-06-05T17:01:46.210 回答