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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Jan 13, 4:50 pm, "Rimantas Liubertas" <riman...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > 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 > --http://rimantas.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 <img src="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/ to http://bank.com/ this kind of Ajax request is forbiden by "same orgin policy". Regards, Rimantas -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---