2

My partner was testing a web application and he found a XSS vulnerability on a change password module, this module places the old password in a hidden field, then it's possible to use a XSS attack to change a password of a user, because the old password can be got by XSS exploit. Also this module doesn't use a token or CAPTCHA to ensure if a request is valid, then my question is: could this vulnerability be consired as CSRF? Why?

I'm not sure because if I mitigate XSS vulnerability and change the hidden field by text field to ensure users introduce their old password a CSRF could'nt be exploited. My partner told me that it could be considered a CSRF because althought we don't know the old password, the web application doesn't use a token or CAPTCHA so we can change a password using brute force and this a kind of CSRF. Is this correct?

3

I wouldn't classify it as CSRF.

The protection mechanism that is failing here is XSS protection, not CSRF protection; If there would not be an XSS vulnerability, you could not perform a CSRF attack. It is true that all XSS vulnerabilities can be exploited to bypass all CSRF protection that are not challenge-response based (passwords, captchas, etc), but that doesn't mean that all XSS vulnerabilities should be classified as CSRF.

There is also no separate classical CSRF vulnerability here. Even though there is no token protection, the form is protected from CSRF via a challenge-response mechanism as a password is required. Your partner does have a point regarding the bruteforce scenario via CSRF though. I would consider it a vulnerability if there is no bruteforce protection for the form, and I would suggest adding whatever CSRF protection is used in the other modules. I would classify it as a bruteforce vulnerability (via CSRF) though.

Apart from that, the fact that the password is even shown is a vulnerability by itself, as is the fact that the passwords are apparently stored in plaintext; You should first check though that the password is actually given by the application, not by the browser- or a plugin-based password manager.

  • Then do you mean that it must be classified more as bruteforce vulnerability than a CSRF? – hmrojas.p Mar 17 '17 at 23:33
  • 1
    @hmrojas.p Ignoring the separate XSS issue, I would classify it as bruteforce vulnerability, because challenge-response via password is a valid CSRF protection (the password cannot be changed via CSRF without a bruteforce attack). However, the protection I would suggest is adding token-based CSRF protection, as it is easier to implement and more reliable than bruteforce protection. If this is for a report, I would simply call it "Bruteforce of Password Reset via CSRF" or in short "Bruteforce via CSRF" and give it CWE-307. – tim Mar 17 '17 at 23:45
  • 1
    @hmrojas.p While I think my arguments have merit, it is a bit of a judgment call though, as the bruteforce attack would obviously be performed via CSRF. If your partner is determined to classify it as CSRF I wouldn't insist on a different classification, as long as it is made clear what the actual issue is, and as long as all vulnerabilities and their proper solutions are mentioned. – tim Mar 17 '17 at 23:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.