Question

I am reading the tutorial at

http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

It states

Remember – you must never rely on the
sessionID sent to your server in the
cookie header ; look only at the
sessionID that your GWT app sends
explicitly in the payload of messages
to your server.

Is it use to prevent http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

With this mythology, is it sufficient enough to prevent to above attack?

Answer 1

Yes, it is sufficient to prevent Cross Site Request Forgery.

The sessionid in the cookie cannot be trusted. Say a user is logged on to mysite.com and session id is in the cookie. Now the user clicks on a link to evilsite.com. evilsite.com has code like this

<img src="http://mysite.com/transfermoney.jsp?amount=1000.." />

The browser will make a request to mysite.com, and it will also send along the cookie with the session id. The thing to understand here is that evilsite.com cannot read the cookie, but it can still get its job done.

Browser same-origin policy prevents evilsite.com from reading the session identifier whether its in the cookie or embedded in html page. But because browser automatically sends the cookie to your server even if the resource was requested from the html code in another domain, you have XSRF.

To prevent this, it is recommended to put the session identifier as a request parameter. If its added as a request parameter, evilsite.com cannot access the identifier, and hence cannot put it in the img src attribute.

However, do remember that if your site has XSS vulnerabilities, nothing can prevent you from XSRF. Put it another way, if you have XSS vulnerabilities, an attacker wouldn’t even care about doing XSRF.