XSRF/CSRF and GWT RPC- Cross site request forgery and Google web toolkit

May 30th, 2010 Alex Moffat Posted in EffectiveGWT, GWT | 8 Comments »

This is a minimal set of changes to protect existing GWT 2.0.3 RPC methods from CSRF (aka XSRF) attacks. GWT 2.0.3 has two different RPC mechanisms, the orignal one, and the new direct-eval RPC implementation. I’m going to talk mostly about the orignal RPC mechanism.

There are two parts to the protection. The first relies on the difficulty of setting a header on an HTTP request made from the browser. The only way to add a header to a request via JavaScript is to use an XMLHttpRequest. If you make a simple GET or POST request from a form element or a GET request using an img element or similar you can not modify the headers sent with the request. Access to the XMLHttpRequest is protected by the same origin policy. This means that simply setting a non standard header on the request and then checking on the server that it is present protects against CSRF done via JavaScript because the code setting the header must have been loaded from the server receiving the request. In GWT 2 custom headers are already set on the client for all RPC requests and are checked by the direct-eval RPC RpcServlet, so this protection already exists for direct-eval RPC calls. The only change needed is to add the check to the RemoteServiceServlet. If you look at the source for the doFinish method in the RpcRequestBuilder class you’ll see that two headers, X-GWT-Permutation and X-GWT-Module-Base are added to all XMLHttpRequest RPC calls.

  protected void doFinish(RequestBuilder rb) {
    rb.setHeader(STRONG_NAME_HEADER, GWT.getPermutationStrongName());
    rb.setHeader(MODULE_BASE_HEADER, GWT.getModuleBaseURL());
  }

RpcRequestBuilder is used on the client by both the original and direct-eval RPC mechanisms. The servlet for the server side of the direct-eval RPC is called RpcServlet and if you look at the source for the getClientOracle method you can see

    String permutationStrongName = getPermutationStrongName();
    if (permutationStrongName == null) {
      throw new SecurityException(
          "Blocked request without GWT permutation header (CSRF attack?)");
    }

To add the same protection to the original RPC mechanism you need to add a similar check to the subclasses of RemoteServiceServlet you implement. I use a common subclass of RemoteServiceServlet as a superclass for all my remote service implementations so in that class I overrode the onBeforeRequestDeserialized method to add a check.

@Override
    protected void onBeforeRequestDeserialized(String serializedRequest) {
        String permutationStrongName = getPermutationStrongName();
        if (permutationStrongName == null) {
            throw new SecurityException(
                 "Blocked request without GWT permutation header (CSRF attack?)");
        }
    }

This change will protect against CSRF attacks made from JavaScript. However, there are apparently ways to set headers from Flash that open a window of vulnerability. There’s more information available about other non JavaScript request mechanisms in part two of the Browser Security Handbook. To protect against this I add another header to the request, this one containing the value of the JSESSIONID cookie, which is accessible on the server as the session id. A cookie value is only accessible to code loaded from the server that set the cookie so checking on the server that the value passed from the client is correct protects against attack by non-javascript mechanisms, provided of course they, and the browser they are using, obey the same origin policy for cookies.

Implementing this second protection requires more work. On the server the principle is the same, retrieve the header value and check it, though you have to handle missing sessions and sessions that have just been created and the client isn’t aware of yet. The example code below would work in the onBeforeRequestDeserialize method.

        HttpServletRequest servletRequest = getThreadLocalRequest();
        HttpSession session = servletRequest.getSession(false);
        // If there is currently no session or if the client doesn't know about it yet then don't check.
        // Otherwise the client must provide the id of the session in a header.
        if (session != null && !session.isNew()) {
            String sessionId = servletRequest.getHeader(SESSION_HEADER);
            if (sessionId == null || !sessionId.equals(servletRequest.getSession().getId())) {
                throw new SecurityException(
                    "Blocked request without session header (CSRF attack?)"));
            }
        }

On the client you have to go to more effort to be able to set an additional header, specifically you need to subclass RpcRequestBuilder and then use your subclass when creating your remote service implementation. For example if the subclass is SubRpcRequestBuilder then the code below creates and configures SomeService correctly.

  SomeServiceAsync svc = (SomeServiceAsync)GWT.create(SomeService.class);
  ((ServiceDefTarget) svc).setRpcRequestBuilder(new SubRpcRequestBuilder());

In SubRpcRequestBuilder you can access the JSESSION id cookie and set the session header in an override of the doFinish method

     String sessionId = Cookies.getCookie("JSESSIONID");
     if (sessionId != null) {
         rb.setHeader(SESSION_HEADER, sessionId);
     }

I’m interested if anyone has any suggestions for further security enhancements or holes I’ve overlooked.