Hi, i''m not really aware about security, i just want to know when should i use protect_from_forgery. Should i use it even on form just available for logged in user? And the second question is how can i pass the authenticity_token value through a simple link (no form). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Dec 3, 8:31 am, "Jean-Sébastien" <jeansebastien....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > i''m not really aware about security, i just want to know when should > i use protect_from_forgery. > Should i use it even on form just available for logged in user? > And the second question is how can i pass the authenticity_token value > through a simple link (no form).You especially want it for something only available to a logged in user (if it''s available to everyone then the attacker might as well do it them self). The super simple example is that you''ve written some banking software, and there is a form on there to send money to a given person. Someone then sends a logged in customer a message saying ''oh, click here and you''ll see anna kournikova''. Instead the link creates and submits a form to the banking website that transfers $10000. The user is already logged in and so has all the cookies etc... and so the request succeeds. In theory you don''t need it for a simple link, since get requests are supposed to have no side effects. Fred --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thank you fred for theory and example, i gonna to implement it (even if i want to see anna kournikova :) ). About link_to: Some of my link_to links send ajax request through jquery. so i need authenticity_token. i could also wrap my links into forms as did usual link_to with method. but i would prefer send authenticity_token key as a parameter. Regards On Dec 3, 10:11 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Dec 3, 8:31 am, "Jean-Sébastien" <jeansebastien....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > Hi, > > i''m not really aware about security, i just want to know when should > > i use protect_from_forgery. > > Should i use it even on form just available for logged in user? > > And the second question is how can i pass the authenticity_token value > > through a simple link (no form). > > You especially want it for something only available to a logged in > user (if it''s available to everyone then the attacker might as well do > it them self). > The super simple example is that you''ve written some banking software, > and there is a form on there to send money to a given person. Someone > then sends a logged in customer a message saying ''oh, click here and > you''ll see anna kournikova''. Instead the link creates and submits a > form to the banking website that transfers $10000. The user is already > logged in and so has all the cookies etc... and so the request > succeeds. > > In theory you don''t need it for a simple link, since get requests are > supposed to have no side effects. > > Fred--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3 Dec 2007, at 09:43, Jean-Sébastien wrote:> > Thank you fred for theory and example, i gonna to implement it (even > if i want to see anna kournikova :) ). > > About link_to: > Some of my link_to links send ajax request through jquery. so i need > authenticity_token. > i could also wrap my links into forms as did usual link_to with > method. but i would prefer send authenticity_token key as a parameter. >Have a peak in form tag helper: def token_tag unless protect_against_forgery? '''' else tag(:input, :type => "hidden", :name => request_forgery_protection_token.to_s, :value => form_authenticity_token) end end Fred> Regards > > On Dec 3, 10:11 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: >> On Dec 3, 8:31 am, "Jean-Sébastien" <jeansebastien....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> >>> Hi, >>> i''m not really aware about security, i just want to know when >>> should >>> i use protect_from_forgery. >>> Should i use it even on form just available for logged in user? >>> And the second question is how can i pass the authenticity_token >>> value >>> through a simple link (no form). >> >> You especially want it for something only available to a logged in >> user (if it''s available to everyone then the attacker might as well >> do >> it them self). >> The super simple example is that you''ve written some banking >> software, >> and there is a form on there to send money to a given person. Someone >> then sends a logged in customer a message saying ''oh, click here and >> you''ll see anna kournikova''. Instead the link creates and submits a >> form to the banking website that transfers $10000. The user is >> already >> logged in and so has all the cookies etc... and so the request >> succeeds. >> >> In theory you don''t need it for a simple link, since get requests are >> supposed to have no side effects. >> >> Fred > >--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
exactly what i was expecting thanks On Dec 3, 11:02 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 3 Dec 2007, at 09:43, Jean-Sébastien wrote: > > > > > Thank you fred for theory and example, i gonna to implement it (even > > if i want to see anna kournikova :) ). > > > About link_to: > > Some of my link_to links send ajax request through jquery. so i need > > authenticity_token. > > i could also wrap my links into forms as did usual link_to with > > method. but i would prefer send authenticity_token key as a parameter. > > Have a peak in form tag helper: > > def token_tag > unless protect_against_forgery? > '''' > else > tag(:input, :type => "hidden", :name => > request_forgery_protection_token.to_s, :value => > form_authenticity_token) > end > end > > Fred > > > Regards > > > On Dec 3, 10:11 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > >> On Dec 3, 8:31 am, "Jean-Sébastien" <jeansebastien....-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > >> wrote: > > >>> Hi, > >>> i''m not really aware about security, i just want to know when > >>> should > >>> i use protect_from_forgery. > >>> Should i use it even on form just available for logged in user? > >>> And the second question is how can i pass the authenticity_token > >>> value > >>> through a simple link (no form). > > >> You especially want it for something only available to a logged in > >> user (if it''s available to everyone then the attacker might as well > >> do > >> it them self). > >> The super simple example is that you''ve written some banking > >> software, > >> and there is a form on there to send money to a given person. Someone > >> then sends a logged in customer a message saying ''oh, click here and > >> you''ll see anna kournikova''. Instead the link creates and submits a > >> form to the banking website that transfers $10000. The user is > >> already > >> logged in and so has all the cookies etc... and so the request > >> succeeds. > > >> In theory you don''t need it for a simple link, since get requests are > >> supposed to have no side effects. > > >> Fred--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> In theory you don''t need it for a simple link, since get requests are > supposed to have no side effects.I seem to recall there being a CSRF attack on Gmail awhile ago that resulted in you getting anyones Contacts list, which was a GET request. I don''t know, maybe GET needs request forgery protection too? Now, this isn''t too widespread unless you''re google or whatever. It is good to know about these things so you can make an informed risk assessment for your site though. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---
On 3 Dec 2007, at 14:43, Rick Olson wrote:> >> In theory you don''t need it for a simple link, since get requests are >> supposed to have no side effects. > > I seem to recall there being a CSRF attack on Gmail awhile ago that > resulted in you getting anyones Contacts list, which was a GET > request. I don''t know, maybe GET needs request forgery protection > too?True I hadn''t thought about that. This is potentially the case whenever there is valuable information that is readable via get (ie i would be worried if I was a bank) Fred> > > Now, this isn''t too widespread unless you''re google or whatever. It > is good to know about these things so you can make an informed risk > assessment for your site though. > > > -- > Rick Olson > http://lighthouseapp.com > http://weblog.techno-weenie.net > http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---
It is nice to see anti-CSRF tokens in forms by default, but assuming an attack can forge cross-site requests, if the attack first forges a "GET /resource/new" request, parses the response for the auth_token, then forges the "POST /resource" with the new auth_token, how does the auth_token provide any security against this kind of attack? Robin On Dec 3 2007, 7:00 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 3 Dec 2007, at 14:43, Rick Olson wrote: > > > > >> In theory you don''t need it for a simple link, since get requests are > >> supposed to have no side effects. > > > I seem to recall there being aCSRFattack on Gmail awhile ago that > > resulted in you getting anyones Contacts list, which was a GET > > request. I don''t know, maybe GET needs request forgery protection > > too? > > True I hadn''t thought about that. This is potentially the case > whenever there is valuable information that is readable via get (ie i > would be worried if I was a bank) > > Fred > > > > > Now, this isn''t too widespread unless you''re google or whatever. It > > is good to know about these things so you can make an informed risk > > assessment for your site though. > > > -- > > Rick Olson > >http://lighthouseapp.com > >http://weblog.techno-weenie.net > >http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---
Because the new auth_token is not from an existing, authorized user with an already established session. -Mike On Jan 6, 8:29 pm, Robin <robi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> It is nice to see anti-CSRF tokens in forms by default, but assuming > an attack can forge cross-site requests, if the attack first forges a > "GET /resource/new" request, parses the response for the auth_token, > then forges the "POST /resource" with the new auth_token, how does the > auth_token provide any security against this kind of attack? > > Robin > > On Dec 3 2007, 7:00 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > On 3 Dec 2007, at 14:43, Rick Olson wrote: > > > >> In theory you don''t need it for a simple link, since get requests are > > >> supposed to have no side effects. > > > > I seem to recall there being aCSRFattack on Gmail awhile ago that > > > resulted in you getting anyones Contacts list, which was a GET > > > request. I don''t know, maybe GET needs request forgery protection > > > too? > > > True I hadn''t thought about that. This is potentially the case > > whenever there is valuable information that is readable via get (ie i > > would be worried if I was a bank) > > > Fred > > > > Now, this isn''t too widespread unless you''re google or whatever. It > > > is good to know about these things so you can make an informed risk > > > assessment for your site though. > > > > -- > > > Rick Olson > > >http://lighthouseapp.com > > >http://weblog.techno-weenie.net > > >http://mephistoblog.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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
So what do I do when I''m faced with a form that either Rails can''t easily produce and needs hand crafting, or if I''m making use of a complex form from a legacy application that''s being re-written in Rails? Mike Subelsky said the following on 07/01/08 11:49 AM:> Because the new auth_token is not from an existing, authorized user > with an already established session. > > -Mike > > On Jan 6, 8:29 pm, Robin <robi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> It is nice to see anti-CSRF tokens in forms by default, but assuming >> an attack can forge cross-site requests, if the attack first forges a >> "GET /resource/new" request, parses the response for the auth_token, >> then forges the "POST /resource" with the new auth_token, how does the >> auth_token provide any security against this kind of attack?-- I''m always interested when [cold callers] try to flog conservatories. Anyone who can actually attach a conservatory to a fourth floor flat stands a marginally better than average chance of winning my custom. (Seen on Usenet) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> So what do I do when I''m faced with a form that either Rails can''t > easily produce and needs hand crafting,Not sure what do you mean by that, but if you can form_authenticity_token will give you value needed for _authenticity_token field if you would like to add it manually.> or if I''m making use of a > complex form from a legacy application that''s being re-written in Rails?Same applies here, I think (though why not to rewrite forms "rails way"?) 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 -~----------~----~----~----~------~----~------~--~---
On Jan 7, 2008 12:24 PM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> wrote:> > So what do I do when I''m faced with a form that either Rails can''t > easily produce and needs hand crafting, or if I''m making use of a > complex form from a legacy application that''s being re-written in Rails?<%= token_tag %> http://dev.rubyonrails.org/browser/trunk/actionpack/lib/action_view/helpers/form_tag_helper.rb#L423 -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---
We are making the assumption that the attack can forge requests on behalf of an authorized user with an established session (cookie). That is the whole point of why CSRF is a real threat, forging requests on behalf of authorized users. The attack is behaving 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 real security? Robin On Jan 7, 8:49 am, Mike Subelsky <subel...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Because the new auth_token is not from an existing, authorized user > with an already established session. > > -Mike > > On Jan 6, 8:29 pm, Robin <robi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > It is nice to see anti-CSRFtokens in forms by default, but assuming > > an attack can forge cross-site requests, if the attack first forges a > > "GET /resource/new" request, parses the response for the auth_token, > > then forges the "POST /resource" with the new auth_token, how does the > > auth_token provide any security against this kind of attack? > > > Robin > > > On Dec 3 2007, 7:00 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > > > > On 3 Dec 2007, at 14:43, Rick Olson wrote: > > > > >> In theory you don''t need it for a simple link, since get requests are > > > >> supposed to have no side effects. > > > > > I seem to recall there being aCSRFattack on Gmail awhile ago that > > > > resulted in you getting anyones Contacts list, which was a GET > > > > request. I don''t know, maybe GET needs request forgery protection > > > > too? > > > > True I hadn''t thought about that. This is potentially the case > > > whenever there is valuable information that is readable via get (ie i > > > would be worried if I was a bank) > > > > Fred > > > > > Now, this isn''t too widespread unless you''re google or whatever. It > > > > is good to know about these things so you can make an informed risk > > > > assessment for your site though. > > > > > -- > > > > Rick Olson > > > >http://lighthouseapp.com > > > >http://weblog.techno-weenie.net > > > >http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---