CSRF prevention?

[Josh]

Hi,

How are people preventing CSRF in their applications using
GileadRPCServiceExporter and other gwt-sl abstractions (transparently
meaning without adding a CSRF-security-token parameter to each remote
service method)? Common ways with GWT is to pass the security token
as a url parameter (which for behind the scenes ajax requests isn't
too horrible) or custom http header. In fact GWT now generates X-GWT-
Permutation header built in for you, but the old style rpc
RemoteServiceServlet doesn't check or enforce this, which seems like
gwt-sl is built upon. Does gwt-sl support the standard GWT CSRF
protection headers, or is there an easy way to plugin custom pre
request (check parameter/header) and post response (cookie setting)
filters without having to write extra servlet filters from scratch on
top of gwt-sl? CSRF prevention is such an important security
precaution, and usually often forgotten by web application developers,
making this as simple and transparent as possible would be great,
especially if it could integrate with GWT standards.

References:
http://jectbd.com/?p=1351
https://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications
http://stackoverflow.com/questions/2609834/gwt-rpc-does-it-do-enough-to-protect-against-csrf

Thanks,
~Josh

[George Georgovassilis]

Hello Josh,

My understanding is that once the browser application has been
compromised (i.e. by html injection) any type of request can be forged
there (i.e. by flash) - see the answer in the discussion to the 3rd
link you posted. As far as I can read from the RemoteServiceServlet
code, the RPC class does honour the X-GWT parameters, so it's built-in
behavior.

> References:http://jectbd.com/?p=1351https://groups.google.com/group/Google-Web-Toolkit/web/security-for-g...http://stackoverflow.com/questions/2609834/gwt-rpc-does-it-do-enough-...
>
> Thanks,
> ~Josh

[Josh]

Hi George,

Thanks for your response. Yes if your application has an injection
vulnerability (i.e. XSS) or have a user using an ancient unpatched
version of flash, you are screwed anyway in many respects, and must
protect against that in other ways. But if it doesn't have other
vulnerabilities, and you are just trying to protect against CSRF
initiated from other applications/sites or links/html via email, etc
while logged into your application session, the GWT custom header
checking seems to be adequate, simple, and transparent.

So I dug a little deeper into the GWT source code. You are right, as
of version 2.1.0 GWT's RemoteServiceServlet finally checks for the X-
GWT-Permutation header by calling checkPermutationStrongName() inside
its processCall() method just like RpcServlet had in 2.0.x I was
still using GWT 2.0.4 which didn't make that check, so I upgraded to
GWT 2.1.0 and tested again. Using the TamperData plugin for Firefox,
I would remove the X-GWT-* headers completely from the request, yet
the calls still succeeded where they should fail with a security
error. So then I dug a little deeper into the GWT-SL code (I'm using
1.0). I'm using GileadRPCServiceExporter, which extends
GWTRPCServiceExporter, which completely overrides the processCall()
method of RemoteServiceServlet, so the call to
checkPermutationStrongName() is never performed.

It looks like you need to add a call to checkPermutationStrongName()
as the first line in the processCall(String) method of
GWTRPCServiceExporter to accurately emulate and override the
functionality of GWT's RemoteServiceServlet and protect against CSRF.

To verify this, I created a custom subclass of
GileadRPCServiceExporter in my code which overrides processCall and
does the check (see below) and configured my beans to use that
instead. It now correctly generates an error response if the X-GWT-
Permutation header isn't present. This is a decent workaround, but
would be better for everyone if the core code handled it instead.


public class CSRFProtectedGileadRPCServiceExporter extends
GileadRPCServiceExporter
{
private static final long serialVersionUID = 1L;

@Override
public String processCall(String payload) throws
SerializationException
{
checkPermutationStrongName();
return super.processCall(payload);
}
}

Thanks,
~Josh


On Nov 11, 12:15 am, George Georgovassilis

> > References:http://jectbd.com/?p=1351https://groups.google.com/group/Google-Web-T......
>
> > Thanks,
> > ~Josh
>
>

[George Georgovassilis]

Thank you Josh for the thorough analysis :-)

I'll have a look this weekend and try to push out a new release