XSRF protection using GWT example guide broken for Glassfish/ Jetty using JSESSIONID

[Josh]

Hi,

I recently re-engineered some custom XSRF/CSRF protection code in my open source GWT-based application to use the new recommended protection introduced in GWT 2.3 as described in https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf .  Since I develop and deploy mainly in Tomcat all seemed well.  However some users of the project deploy to Glassfish and Jetty Java Servlet Containers, both of which immediately started having problems with all RPC calls getting blocked throwing a "java.lang.IllegalArgumentException: Duplicate cookie! Cookie override attack?" exception.

Looking into why, I've determined the problem being JSESSIONID, the session cookie and what GWT recommends to base XSRF token from, is in both application and root path for the host for different reasons, causing the exception to be thrown when the application sees both cookies in scope: (tracked on http://code.google.com/p/webpasswordsafe/issues/detail?id=58)

What steps will reproduce the problem?
1. Glassfish- visit admin console (http://host:4848/ creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for /WPS
2. Although on different ports, cookie spec doesn't care and both instances of JSESSIONID cookie are in scope to WPS, the GWT Google code sees both when it calls getCookie() and throws an exception "java.lang.IllegalArgumentException: Duplicate cookie! Cookie override attack?" and doesn't allow any requests to work.

1. Jetty- visit one of their sample servlets (i.e. http://host:8080/dump/info creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS creates JSESSIONID cookie for /WPS
2. Although different contexts, Jetty servlet sets its at root path so both are in scope to WPS, blah blah blah same exception and reason as the Glassfish example above.

There is no way to configure the GWT code to ignore the duplicate cookie check without modifying their code.  It would be ideal if it just checked for and cared about the cookies defined in the /WPS application context and ignored the others or allowed a way to configure it to call com.google.gwt.user.server.Util.getCookie() passing true (allow duplicates) as the last parameter rather than hardcoding false.  Admittedly this may not be possible in the former case, and not completely secure in the later case.  But basing this all on the JSESSIONID in real world usage isn't working either.

The workaround when I had this same issue when I was rolling out my own XSRF protection code previously to GWT 2.3 was to use a different unique cookie name that basically just duplicated the last JSESSIONID value and set that extra cookie when that session was first created.  You'd think if this new way was Google's "official" documented and mandated way to protect against XSRF, even using JSESSIONID in their example, it would "just work" out of the box.  But clearly not, unless their code was never tested with Jetty or Glassfish.  Very surprising.

Is there a preferred way to handle this from the GWT team that isn't documented, or is my kludge workaround the only way?  Preferably a solution that works for all servlet containers, I know there are Tomcat-specific, Jetty-specific, etc settings to tweak default JSESSIONID behavior but those are not standard and even worse kludges.

Thanks for your attention to this and any advice as far as best practices,

~Josh

[Jan Przybylo]

GWT team appears to be veeeery reponsive... :\

I have the same problem and still can't find any solution...

Does anyone know how to fix it? maybe I should be setting all cookies with / path and remove invalid cookies by trying to overwrite them using the same name, also / path and setting date expires to current timestamp? So the path is what I'm considering changing. 

What do you guys think?

Thanks in advance for any kind of help.

Jan

[Jens]

You can create a new base class for your servlets and override XsrfProtectedServiceServlet.validateXsrfToken() to adjust it to your needs.

-- J.