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 bu trying to overwrite it using the same name, also / path but setting date expires to current timestamp? So the path is what I'm considering changing. What you guys think? Thanks in advance for any kind of help. Jan W dniu piątek, 1 czerwca 2012 02:47:28 UTC-4 użytkownik Josh napisał: > > 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 > > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
