是否在Google App Engine上运行的GWT应用程序受CSRF保护

Question

我正在开发一个在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标头

我可以看到我从谷歌设置的cookie看起来像SID值,但我无法从有效载荷中的序列化Java对象中判断出是否传递了令牌.我也不知道是否正在使用Referer标头.

那么,我担心一个非问题吗？如果没有,这里最好的策略是什么？这是一个很常见的问题,那里必须有标准的解决方案......

Answer 1

如果您将相同的代码放在常规servlet中,那么您肯定容易受到XSRF的攻击.但是因为你正在使用GWT RemoteServiceServlet- 答案取决于你正在使用的GWT的版本.

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

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

参考

1. GWT RPC - 它是否足以抵御CSRF？
2. 关于GWT RPC和XSRF的Lombardi开发博客
3. GWT应用程序的安全性