I have been doing a bit of dvwa (damn vulnerable web application) and I have a question on CSRF.

There is an additional parameter, a csrf token, which is submitted in the get request. All the answers I saw on the web uses xss to trigger the password change.

I thought of a different way and was wondering if my answer was right?

Basically what I do is create a php script on attacker website which requests the dvwa csrf page, collects the user_token issued to the attacker page then use that token to further submit the password, new_password and the user_token.

I tried doing this (request two pages and using the user token of one page on another)

  • Please edit your question to clarify exactly what your question is. I don't know what you're asking. Are you looking for more of a discussion? – Daisetsu Nov 8 '18 at 19:16

One of the critical requirements of a properly-implemented CSRF protection is that the anti-CSRF token needs to be unique for each user. The attacker's web server can get a token from the vulnerable site, but it won't (well, shouldn't) be the victim's token. If the site issues the same anti-CSRF token to all users, then the site is vulnerable to CSRF; just go retrieve the anti-CSRF token using your own user account, and use it to attack other users.

Doing this client-side (the attacker web site, rather than web server, retrieves the token) won't work because of the same-origin policy (unless the vulnerable site also has an extremely insecure CORS configuration, which is a whole different vulnerability). The attacker can cause the victim's browser to request a page on the target site, but the attacker's site cannot see what the response is, so it won't be able to find out the victim's anti-CSRF token that way. If this comes as a surprise to you, go read about same-origin policy; it's one of the most critical protections a web browser offers (without it, you could never safely be signed into one site and browsing another one).


Typically a CSRF token is supposed to be generated Client-Side in the Javascript so that your browser tabs are sandboxed apart from each other and use different tokens even though you are on the same machine. This means the server never gives out CSRF tokens that you can request.

  • 3
    This is wrong. The server needs to know what the expected value of the anti-CSRF token is, and the attacker (acting as the client, here) needs to not be able to influence that value. Otherwise, the attacker would simply set the anti-CSRF token to a value of their choosing, and send that value with the forged request. – CBHacking Nov 8 '18 at 20:26
  • 2
    I thought I read that they were normally generated client side, but I tried finding my source and that does not seem commonplace, or advisable. I always thought that sounded strange. Thanks for the correction. – Nosajimiki Nov 8 '18 at 20:59

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.