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).
On Dec 3, 8:31 am, “Jean-Sébastien” [email protected]
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
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 C. [email protected]
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 O.
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com
On 3 Dec 2007, at 14:43, Rick O. 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
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 C. [email protected]
Because the new auth_token is not from an existing, authorized user
with an already established session.
-Mike
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
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:
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)
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
On Jan 7, 2008 12:24 PM, Anton J Aylward [email protected] 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 O.
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com
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