I am uncertain that the auth_token provides any real protection
against CSRF.
At best, the auth_token protects against a blind POST, but it does not
provide security because an attack can get a valid auth_token with a
GET and then perform the POST.
Assuming that an attack can forge requests on behalf of an authorized
user with an established session (cookie), nothing prevents the attack
from first fetching the form and valid token, then submitting the form
with valid token on behalf of the user.
The attack can behave just like the authorized user would: GET the
form and token, then POST the form and token, so how does the
auth_token provide any protection against CSRF?
The attack can behave just like the authorized user would: GET the
form and token, then POST the form and token, so how does the
auth_token provide any protection against CSRF?
Ok, try to answer the question “how do attacker gets form AND token with
CSRF? (let’s assume, that XSS is not an option)” and maybe then it will
be more clear, why token provides protection
The attacker can do an Ajax request for the form, parse the token,
then use the token to post the form as another Ajax request. Are you
saying that the attacker would not be able to parse the token in CSRF
because that would be considered XSS?
The attacker can do an Ajax request for the form, parse the token,
then use the token to post the form as another Ajax request.
Are you
saying that the attacker would not be able to parse the token in CSRF
because that would be considered XSS?
That’s the point: attacker cannot issue Ajax request.
Let’s say you have some malicious page on http://evil.com/. If your
victim
visits that page, you can make his browser issue GET request, let’s say
to his
bank site http://bank.com/… by simply having on
that malicious page. Attacker can also submit form with POST request
from that
malicious page using Javascript. But attacker cannot issue
XMLHTTPRequest from http://evil.com/ to http://bank.com/ — this kind of Ajax request is
forbiden by “same
orgin policy”.
