On May 4, 6:39 pm, cbauer <[email protected]> wrote: > In 2.1 some custom HTTP headers were added to GWT RPC with the goal of > preventingXSRFattacks from vectors such as XHR, simple HTML forms, > etc. However, many GWT applications are probably still vulnerable > toXSRFattacks executed with older Flash advertisement player versions. > Search this group for more discussions on this, you are vulnerable if > your users have older Flash plugin versions installed and you are > using GWT RPC to modify server-stored state. > > (Common) protection against this kind ofXSRFattack would be a per- > request token shared by client and server, also detailed > here:http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gw... > > A simple solution is then to include the session identifier as the per- > request token in the request payload, in addition to the session > identifier cookie. The problem so far has been how difficult it is to > transparently add a per-request payload to a GWT RCP request. > Suggestions such as "add another parameter to all your RCP methods" > are risky, as one developer's mistake would create a security problem. > > On the server side, token validation should be transparent, for > example, it should be a servlet filter or some other kind of proxy > that compares the request payload with the current session > (identifier). > > Instead in 2.3 we get > this:http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideSecur... > > The token is a hash of the session identifier. What's wrong with the > session identifier?
The problem with using session ID as XSRF token is that applications mark session cookies as HttpOnly[1] to protect against cookie theft via cross-site scripting (XSS) attacks. This means that client-side code can't access the session ID value in a cookie. > > A custom servlet that produces these tokens is needed. What's wrong > with the standard session cookie handling of the servlet container? It > produces a shard client/server secret already. > > My servlets have to subclass a special servlet to be protected. Why > not a servlet filter that protects _everything_ without potential for > mistakes? Agree, it'd be nice to have a setting to enable XSRF protection everywhere to catch potential coding errors. It's on my TODO list. > > The client API has to be that complex? One tiny mistake and there is > no protection. Could you elaborate on which part of API do you find complex? If server-side code was done correctly, client-side coding mistakes will result in XSRF exception. Meder 1. http://en.wikipedia.org/wiki/HTTP_cookie#HttpOnly_cookie -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
