7

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

Pascal
  • 73
  • 3

1 Answers1

6

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.

Community
  • 1
  • 1
Chris Lercher
  • 36,020
  • 19
  • 96
  • 128
  • It's not quite true that login XSRF is harmless. Say the application is vulnerable to self-XSS: You can inject scripts, but they are only reflected to your user. Let's use the following setup: Create an iframe that loads the application, showing some sensitive data (using the attacker's transient authentication). Wait a bit. Perform XSRF to log the target into a prepared account and run scripts in the origin of the web page, to read out the sensitive data from the other frame. – Niklas B. Aug 06 '14 at 23:59
  • @Niklas: This is true, if it is possible to display sensitive information without sending the XSRF token. Some people make the following mistake: They XSRF-protect only those calls that can change something on the server. That's actually _mostly_ ok, but for reasons like the one you mentioned, and also for the reason I mentioned at the bottom of my answer, it is much better to _also_ protect the calls which retrieve sensitive data. – Chris Lercher Aug 07 '14 at 17:11