Charlie over at thehackersplace.org sent me this email (snipped for reading) about a XSS and a CSRF vulnerability in gameplay.co.uk (a big online game retailer):
the gameplay password change doesnt request the old password so a script could be made to automatically change the password.
Actually more interesting than the XSS is the CSRF in my mind. In this particular example the CSRF does not require any user interaction to perform one of the most significant site functions (password change). Maybe this isn’t that big of a site, considering it’s not a community site, but the premise is the same. Requiring user interaction (like requesting that the user type their old password in) is a pretty common sense way to stop that particular attack. It’s safe to assume that if they have your password already, you have bigger issues, but even still, omitting a one time token on the page that can’t be faked that must be seen on the next page is another way to reduce the threat.
Notice I don’t say solve, I say reduce. That’s also assuming that on the page in question there isn’t an XSS vulnerability that can read that one time token. One time tokens definitely aren’t 100%, they must be on pristine pages to function properly. Anyway, thanks to Charlie for the info!