csrf attacks

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 :slight_smile: ).

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 :slight_smile: ).

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