In 2.1 some custom HTTP headers were added to GWT RPC with the goal of preventing XSRF attacks from vectors such as XHR, simple HTML forms, etc. However, many GWT applications are probably still vulnerable to XSRF attacks 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 of XSRF attack 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-gwt-applications 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/DevGuideSecurityRpcXsrf.html The token is a hash of the session identifier. What's wrong with the session identifier? 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? The client API has to be that complex? One tiny mistake and there is no protection. -- 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.
