Understanding the Rails Authenticity Token

Question

I am running into some issues regarding the Authenticity Token in Rails  as I have many times now   But I really don t want to just solve this problem and go on  I would really like to understand the Authenticity token  Well  my question is  do you have some complete source of information on this subject or would you spend your time to explain in details here

User · Answer

The authenticity token is designed so that you know your form is being submitted from your website. It is generated from the machine on which it runs with a unique identifier that only your machine can know, thus helping prevent cross-site request forgery attacks.

If you are simply having difficulty with rails denying your AJAX script access, you can use

<%= form_authenticity_token %>

to generate the correct token when you are creating your form.

You can read more about it in the documentation.

User · Answer

The Authenticity Token is rails  method to prevent  cross-site request forgery  CSRF or XSRF  attacks    To put it simple  it makes sure that the PUT   POST   DELETE  methods that can modify content  requests to your web app are made from the client s browser and not from a third party  an attacker  that has access to a cookie created on the client side

User · Answer

What is CSRF   The Authenticity Token is a countermeasure to Cross-Site Request Forgery  CSRF   What is CSRF  you ask   It s a way that an attacker can potentially hijack sessions without even knowing session tokens    Scenario    Visit your bank s site  log in  Then visit the attacker s site  e g  sponsored ad from an untrusted organization   Attacker s page includes form with same fields as the bank s  Transfer Funds  form  Attacker knows your account info  and has pre-filled form fields to transfer money from your account to attacker s account  Attacker s page includes Javascript that submits form to your bank  When form gets submitted  browser includes your cookies for the bank site  including the session token  Bank transfers money to attacker s account  The form can be in an iframe that is invisible  so you never know the attack occurred   This is called Cross-Site Request Forgery  CSRF      CSRF solution    Server can mark forms that came from the server itself Every form must contain an additional authentication token as a hidden field  Token must be unpredictable  attacker can t guess it   Server provides valid token in forms in its pages  Server checks token when form posted  rejects forms without proper token   Example token  session identifier encrypted with server secret key  Rails automatically generates such tokens  see the authenticity token input field in every form

User · Answer

What is an authentication token    This is a random string used by rails application to make sure that the user is requesting or performing an action from the app page  not from another app or site   Why is an authentication token is necessary    To protect your app or site from cross-site request forgery   How to add an authentication token to a form    If you are generating a form using form for tag an authentication token is automatically added else you can use  lt    csrf meta tag   gt

User · Answer

since Authenticity Token is so important  and in Rails 3 0  you can use    lt    token tag nil   gt    to create    lt input name  authenticity token  type  hidden  value  token value  gt    anywhere

User · Answer

Methods Where authenticity token is required     authenticity token is required in case of idempotent methods like post  put and delete  Because Idempotent methods are affecting to data    Why It is Required     It is required to prevent from evil actions  authenticity token is stored in session  whenever a form is created on web pages for creating or updating to resources then a authenticity token is stored in hidden field and it sent with form on server  Before executing action user sent authenticity token is cross checked with authenticity token stored in session  If authenticity token is same then process is continue otherwise it does not perform actions

User · Answer

Minimal attack example that would be prevented  CSRF  On my website evil com I convince you to submit the following form    lt form action  http   bank com transfer  method  post  gt     lt p gt  lt input type  hidden  name  to       value  ciro  gt  lt  p gt     lt p gt  lt input type  hidden  name  ammount  value  100  gt  lt  p gt     lt p gt  lt button type  submit  gt CLICK TO GET PRIZE    lt  button gt  lt  p gt   lt  form gt    If you are logged into your bank through session cookies  then the cookies would be sent and the transfer would be made without you even knowing it   That is were the CSRF token comes into play    with the GET response that that returned the form  Rails sends a very long random hidden parameter when the browser makes the POST request  it will send the parameter along  and the server will only accept it if it matches   So the form on an authentic browser would look like    lt form action  http   bank com transfer  method  post  gt     lt p gt  lt input type  hidden  name  authenticity token  value  j DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s    gt  lt  p gt     lt p gt  lt input type  hidden  name  to                  value  ciro  gt  lt  p gt     lt p gt  lt input type  hidden  name  ammount             value  100  gt  lt  p gt     lt p gt  lt button type  submit  gt Send 100  to Ciro  lt  button gt  lt  p gt   lt  form gt    Thus  my attack would fail  since it was not sending the authenticity token parameter  and there is no way I could have guessed it since it is a huge random number   This prevention technique is called Synchronizer Token Pattern   Same Origin Policy  But what if the attacker made two requests with JavaScript  one to read the token  and the second one to make the transfer   The synchronizer token pattern alone is not enough to prevent that   This is where the Same Origin Policy comes to the rescue  as I have explained at  https   security stackexchange com questions 8264 why-is-the-same-origin-policy-so-important 72569 72569  How Rails sends the tokens  Covered at  Rails  How Does csrf meta tag Work   Basically    HTML helpers like form tag add a hidden field to the form for you if it s not a GET form AJAX is dealt with automatically by jquery-ujs  which reads the token from the meta elements added to your header by csrf meta tags  present in the default template   and adds it to any request made   uJS also tries to update the token in forms in outdated cached fragments    Other prevention approaches   check if certain headers is present e g  X-Requested-With    What  39 s the point of the X-Requested-With header  https   security stackexchange com questions 23371 csrf-protection-with-custom-headers-and-without-validating-token Is an X-Requested-With header server check sufficient to protect against a CSRF for an ajax-driven application   check the value of the Origin header  https   security stackexchange com questions 91165 why-is-the-synchronizer-token-pattern-preferred-over-the-origin-header-check-to re-authentication  ask user for password again  This should be done for every critical operation  bank login and money transfers  password changes in most websites   in case your site ever gets XSSed  The downside is that the user has to type the password multiple times  which is tiresome  and increases the chances of keylogging   shoulder surfing

User · Answer

What happens  When the user views a form to create  update  or destroy a resource  the Rails app creates a random authenticity token  stores this token in the session  and places it in a hidden field in the form  When the user submits the form  Rails looks for the authenticity token  compares it to the one stored in the session  and if they match the request is allowed to continue   Why it happens  Since the authenticity token is stored in the session  the client cannot know its value  This prevents people from submitting forms to a Rails app without viewing the form within that app itself  Imagine that you are using service A  you logged into the service and everything is ok  Now imagine that you went to use service B  and you saw a picture you like  and pressed on the picture to view a larger size of it  Now  if some evil code was there at service B  it might send a request to service A  which you are logged into   and ask to delete your account  by sending a request to http   serviceA com close account  This is what is known as CSRF  Cross Site Request Forgery    If service A is using authenticity tokens  this attack vector is no longer applicable  since the request from service B would not contain the correct authenticity token  and will not be allowed to continue   API docs describes details about meta tag      CSRF protection is turned on with the protect from forgery method    which checks the token and resets the session if it doesn t match what   was expected  A call to this method is generated for new Rails   applications by default    The token parameter is named authenticity token by default  The name   and value of this token must be added to every layout that renders   forms by including csrf meta tags in the HTML head    Notes  Keep in mind  Rails only verifies not idempotent methods  POST  PUT PATCH and DELETE   GET request are not checked for authenticity token  Why  because the HTTP specification states that GET requests is idempotent and should not create  alter  or destroy resources at the server  and the request should be idempotent  if you run the same command multiple times  you should get the same result every time    Also the real implementation is a bit more complicated as defined in the beginning  ensuring better security  Rails does not issue the same stored token with every form  Neither does it generate and store a different token every time  It generates and stores a cryptographic hash in a session and issues new cryptographic tokens  which can be matched against the stored one  every time a page is rendered  See request forgery protection rb   Lessons  Use authenticity token to protect your not idempotent methods  POST  PUT PATCH  and DELETE   Also make sure not to allow any GET requests that could potentially modify resources on the server     EDIT  Check the comment by  erturne regarding GET requests being idempotent  He explains it in a better way than I have done here

User · Answer

The authenticity token is used to prevent Cross-Site Request Forgery attacks  CSRF   To understand the authenticity token  you must first understand CSRF attacks   CSRF  Suppose that you are the author of bank com  You have a form on your site that is used to transfer money to a different account with a GET request     A hacker could just send an HTTP request to the server saying GET  transfer amount  1000000 amp account-to 999999  right     Wrong  The hackers attack won t work  The server will basically think      Huh  Who is this guy trying to initiate a transfer  It s not the owner of the account  that s for sure    How does the server know this  Because there s no session id cookie authenticating the requester   When you sign in with your username and password  the server sets a session id cookie on your browser  That way  you don t have to authenticate each request with your username and password  When your browser sends the session id cookie  the server knows      Oh  that s John Doe  He signed in successfully 2 5 minutes ago  He s good to go    A hacker might think      Hmm  A normal HTTP request won t work  but if I could get my hand on that session id cookie  I d be golden    The users browser has a bunch of cookies set for the bank com domain  Every time the user makes a request to the bank com domain  all of the cookies get sent along  Including the session id cookie   So if a hacker could get you to make the GET request that transfers money into his account  he d be successful  How could he trick you into doing so   With Cross Site Request Forgery   It s pretty simply  actually  The hacker could just get you to visit his website  On his website  he could have the following image tag    lt img src  http   bank com transfer amount  1000000 amp account-to 999999  gt    When the users browser comes across that image tag  it ll be making a GET request to that url  And since the request comes from his browser  it ll send with it all of the cookies associated with bank com  If the user had recently signed in to bank com    the session id cookie will be set  and the server will think that the user meant to transfer  1 000 000 to account 999999        Well  just don t visit dangerous sites and you ll be fine    That isn t enough  What if someone posts that image to Facebook and it appears on your wall  What if it s injected into a site you re visiting with a XSS attack      It s not so bad  Only GET requests are vulnerable    Not true  A form that sends a POST request can be dynamically generated  Here s the example from the Rails Guide on Security    lt a href  http   www harmless com   onclick     var f   document createElement  form      f style display    none     this parentNode appendChild f     f method    POST     f action    http   www example com account destroy     f submit      return false   gt To the harmless survey lt  a gt    Authenticity Token  When your ApplicationController has this   protect from forgery with   exception   This    lt    form tag do   gt    Form contents  lt   end   gt    Is compiled into this    lt form accept-charset  UTF-8  action     method  post  gt     lt input name  utf8  type  hidden  value   amp  x2713     gt     lt input name  authenticity token  type  hidden  value  J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX 8Cts     gt    Form contents  lt  form gt    In particular  the following is generated    lt input name  authenticity token  type  hidden  value  J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX 8Cts     gt    To protect against CSRF attacks  if Rails doesn t see the authenticity token sent along with a request  it won t consider the request safe   How is an attacker supposed to know what this token is  A different value is generated randomly each time the form is generated     A Cross Site Scripting  XSS  attack - that s how  But that s a different vulnerability for a different day

User · Answer

Beware the Authenticity Token mechanism can result in race conditions if you have multiple  concurrent requests from the same client  In this situation your server can generate multiple authenticity tokens when there should only be one  and the client receiving the earlier token in a form will fail on it s next request because the session cookie token has been overwritten  There is a write up on this problem and a not entirely trivial solution here  http   www paulbutcher com 2007 05 race-conditions-in-rails-sessions-and-how-to-fix-them

[ruby-on-rails] Understanding the Rails Authenticity Token

Examples related to ruby-on-rails

Examples related to ruby

Examples related to authenticity-token