base under attack
ethical hacking, penetration testing, IT security and other news

A common cross site request forgery protection method is requiring a unique token to be submitted with each request. Rails uses a token that is submitted only with POST requests, and that token stays the same throughout the entire session, regardless of what form is being submitted. This is an effective way to mitigate most CSRF attacks because an attack launched from another site cannot feasibly know the unique token for that session.

However, if a XSS vulnerability exists on the same site, it becomes trivial to circumvent this protection. Why? Because if you can put javascript on the page, you can grab the token right off the page and submit it with your forged request automatically.

Of course, this attack vector requires the XSS to run on the same site as the CSRF. Ok, maybe it’s not cross site anymore, but it’s still request forgery. Imagine a blog application having a XSS vulnerability in the comment feature. An unprivileged user could submit malicious code, and when an administrator views that comment, it would make the forged request using the token off that same page. Remember, when Rails’ protect from forgery is enabled, it uses the same token for all forms in that session, so you could grab the token off of one page and use it to forge a request to another.

Is this a flaw in Rails CSRF protection? I don’t think so. As in many other attacks - XSS serves as the enabler. Combining XSS with CSRF is not only a way to automate the process (sometimes to the extent of creating a worm), but it also allows you to bypass some protection methods.