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
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
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
exactly what i was expecting thanks
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.
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
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
Because the new auth_token is not from an existing, authorized user with an already established session.
-Mike
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:
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
<%= token_tag %>
http://dev.rubyonrails.org/browser/trunk/actionpack/lib/action_view/helpers/form_tag_helper.rb#L423
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
