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
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/IVFdY56zeEYJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment