Session handling during login with protection against XSRF (cross-site-request-forgery) in GWT

Question

I have implemented a simple GWT application featuring a login service (LoginService) and a worker service (WorkerService). Both GWT-RPC. I have protected all services against XSRF by implementing GWT's latest XsrfProtectedServiceServlet (see GWT Xsrf-Safe Sample Projetct).

Implementing this example, the session id is created in the JSP file, right when a page gets loaded. In that case even if the user does not log in.

Is this a correct approach? Or do I have to create the session id (setting the cookie) in the LoginService? But when implementing it that way, wouldn't the LoginService itself be vulnerable to an XSRF attack?

Thanks, Pascal

Answer 1

First, a short recap of XSRF:

• User surfs to some-attacker.com/evil.html
• evil.html contains e.g. an <img> tag (or some JavaScript that submits a form POST, ...) with the URL "www.your-nice-site.com/doSomeAction"
• This makes the user's browser automatically submit a GET or POST request to your site, and perform the action on the user's behalf. Unfortunately, the user's cookies for www.your-nice-site.com are also sent automatically with the request, so (and here's the problem) if the user is logged in, the request arrives as fully authorized by the user at your server (that is, if your server doesn't require an additional anti-XSRF token).

Now it's easy to see, that XSRF can't be used to attack the login service itself, because at that point, the user isn't authorized yet - the attacker would have to know the user's credentials to perform a login. (If the user is already logged in, then calling the login service should do nothing! [*])

Note: Of course, the attacker may employ other techniques to perform an attack for the user's credentials, most notably: Phishing. Anti-XSRF measures cannot protect you against that.

---

[*] If you have services that cannot be protected with an anti-XSRF token (e.g. a login service), then especially always make sure that they don't return valid JSON/JavaScript containing any valuable information!

If you absolutely have to, then always wrap the response in JavaScript comments (/* */), as explained in http://code.google.com/webtoolkit/articles/security_for_gwt_applications.html#json . Or even better: Prepend the response with while(1);, as explained in Why have "while(1);" in XmlHttpRequest response?. This is a good practice anyway.