# CSRF protection

**URL:** <https://discuss.rubyonrails.org/t/csrf-protection/23143>\
**Category:** rubyonrails-talk\
**Created:** [January 13, 2008, 11:58pm UTC](https://discuss.rubyonrails.org/t/csrf-protection/23143 "2008-01-13T23:58:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Robin1](https://avatars.discourse-cdn.com/v4/letter/r/ce73a5/32.png) [@Robin1](https://discuss.rubyonrails.org/u/Robin1)\
**Post date:** [January 13, 2008, 11:58pm UTC](https://discuss.rubyonrails.org/t/csrf-protection/23143/1 "2008-01-13T23:58:22Z")

</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:** ![Rimantas\_Liubertas](https://avatars.discourse-cdn.com/v4/letter/r/e8c25b/32.png) [@Rimantas\_Liubertas](https://discuss.rubyonrails.org/u/Rimantas_Liubertas)\
**Post date:** [January 14, 2008, 12:50am UTC](https://discuss.rubyonrails.org/t/csrf-protection/23143/2 "2008-01-14T00:50:47Z")

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

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

---

<div class="post-metadata">

**Author:** ![Robin1](https://avatars.discourse-cdn.com/v4/letter/r/ce73a5/32.png) [@Robin1](https://discuss.rubyonrails.org/u/Robin1)\
**Post date:** [January 14, 2008, 5:48am UTC](https://discuss.rubyonrails.org/t/csrf-protection/23143/3 "2008-01-14T05:48:14Z")

</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:** ![Rimantas\_Liubertas](https://avatars.discourse-cdn.com/v4/letter/r/e8c25b/32.png) [@Rimantas\_Liubertas](https://discuss.rubyonrails.org/u/Rimantas_Liubertas)\
**Post date:** [January 14, 2008, 9:48pm UTC](https://discuss.rubyonrails.org/t/csrf-protection/23143/4 "2008-01-14T21:48:53Z")

</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 \<img src="[http://bank.com/...&quot;&gt](http://bank.com/...&quot;&gt); 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