By default the form post CSRF protection in Rails creates an authenticity token for a user that only changes when the user’s session changes. One of our customers did a security audit of our site and flagged that as an issue.
The auditor’s statement was that if we also had a XSS vulnerability that an attacker could grab another user’s authenticity token and make use of it for CSRF attacks until the user’s session expired.
But is seems to me that if we had an XSS vulnerability like that an attacker could just as easily grab another user’s session cookie and login as that user directly. Or even just make calls to our REST Api from script as the user being attacked. Being able to mount a CSRF attack doesn’t seem any worse in such a situation… the problem would be the XSS vulnerability.
Have I missed something? Is there a real problem with the default CSRF protection in Rails?
You are entirely correct. Token based CSRF protection is the most common and as long as you test your application for XSS you should be fine.
There are cases where CSRF can still be stopped regardless of XSS. For instance, for your password change forum, require that they know the current password. A hacker will be unable to forge this request unless he knows the current password, a moot point.
Another method is to require a Captcha to be solve for that request. I recommend using reCapthca.