# CSRF protection

**URL:** <https://www.ruby-forum.com/t/csrf-protection/125938>\
**Category:** Rails\
**Created:** [January 14, 2008, 12:59am UTC](https://www.ruby-forum.com/t/csrf-protection/125938 "2008-01-14T00:59:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![robin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e5b9ba/32.png) [@robin](https://www.ruby-forum.com/u/robin)\
**Post date:** [January 14, 2008, 12:59am UTC](https://www.ruby-forum.com/t/csrf-protection/125938/1 "2008-01-14T00:59:17Z")

</div>

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?

Thanks,

Robin

---

<div class="post-metadata">

**Author:** ![robin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e5b9ba/32.png) [@robin](https://www.ruby-forum.com/u/robin)\
**Post date:** [January 14, 2008, 1:51am UTC](https://www.ruby-forum.com/t/csrf-protection/125938/2 "2008-01-14T01:51:55Z")

</div>

> 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?

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 🙂

## Regards, Rimantas

[http://rimantas.com/](http://rimantas.com/)

---

<div class="post-metadata">

**Author:** ![robin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e5b9ba/32.png) [@robin](https://www.ruby-forum.com/u/robin)\
**Post date:** [January 14, 2008, 6:49am UTC](https://www.ruby-forum.com/t/csrf-protection/125938/3 "2008-01-14T06:49:23Z")

</div>

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?

Thanks,

Robin

---

<div class="post-metadata">

**Author:** ![robin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e5b9ba/32.png) [@robin](https://www.ruby-forum.com/u/robin)\
**Post date:** [January 14, 2008, 10:49pm UTC](https://www.ruby-forum.com/t/csrf-protection/125938/4 "2008-01-14T22:49:57Z")

</div>

> 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/](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/](http://bank.com/)… by simply having ![](http://bank.com/...) 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/](http://evil.com/) to [http://bank.com/](http://bank.com/) — this kind of Ajax request is  
forbiden by “same  
orgin policy”.

## Regards, Rimantas

[http://rimantas.com/](http://rimantas.com/)