To prevent XSS attack rails generates an authenticity_token for every form. This token has to be present in with every request other then 'ge't. I have noticed that this token is same accross the application..i think for a particular session.. This token can be extracted by javascript and a new create/update/ delete request can be successfully executed. Then authentication_token is of no use. Correct me if I am wrong?
Regards, Pankaj
Yes, but it prevents a third-party site from doing something like this (yes, a variation on this really happened)
<form action="http://twitter.com/statuses/" method="post" id="hax"> <input type="hidden" name="status[text]" value="OMG hax!!" /> </form> <script>$('hax').submit();</script>
Also from a third party website, one can request a page that has a form, parse that page and get the authenticity_token, then construct a post request with this authenticity_token.
Regards, Pankaj
The authenticity token is there first and foremost to prevent CSRF (Cross-site request forgery - Wikipedia, note that CSRF != XSS) and it works very well in that regard, like Court mentions. AFAIK it's not supposed to be an ultimate solution to haxory. It's very hard if not impossible to build protection against all hacks into the framework, it's something the application developer has to take care of. However, like said authenticity_token is a good cure against CSRF and requires zero intervention from you as a developer.
//jarkko
Also, to get back to your statement above... Yes, a third party website can do that but *it won't have an existing session available*. So even if it is intelligent enough to work with session cookies, it will get a brand-new, unauthenticated session. Thus it shouldn't be able to do anything dangerous.
However, the idea of CSRF is that a user *already logged in* will be tricked to post to the site from a third-party page without knowing about it, thus bypassing the authentication. And this is what authenticity_token prevents, because the third party can't possibly know the authenticity token for the specific user session and can't load the page holding the form on-the-fly to grab the token because of the same-origin policy.
//jarkko
The authenticity token is there first and foremost to prevent CSRF (http://en.wikipedia.org/wiki/Cross- site_request_forgery , note that CSRF != XSS) and it works very well in that regard, like Court mentions. AFAIK it's not supposed to be an ultimate solution to haxory. It's very hard if not impossible to build protection against all hacks into the framework, it's something the application developer has to take care of. However, like said authenticity_token is a good cure against CSRF and requires zero intervention from you as a developer.
thanks for that CSRF != XSS . If it doesnot provide complete solution, everyone should know about it...so that they donot assume that it is.
Also, to get back to your statement above... Yes, a third party
website can do that but *it won't have an existing session available*.
So even if it is intelligent enough to work with session cookies, it
will get a brand-new, unauthenticated session. Thus it shouldn't be
able to do anything dangerous.
Yes i forgot about the session thing..But my original thoughts were related to CSRF..
However, the idea of CSRF is that a user *already logged in* will be
tricked to post to the site from a third-party page without knowing
about it, thus bypassing the authentication.
This i assume is done through some javascript..which finds it way onto the users "logged in" page somehow....and transfers the cookie to the third party site.
And this is what
authenticity_token prevents, because the third party can't possibly
know the authenticity token for the specific user session and can't
load the page holding the form on-the-fly to grab the token because of
the same-origin policy.
If the script can transfer the cookie, it can also transfer the authentication_token. So now the 3rd party application has both cookie and the token :).
Regards, Pankaj
I
That can't happen: javascript can't read cookies from domains it wasn't served from.
Fred
That can't happen: javascript can't read cookies from domains it
wasn't served from.Fred
the javascript would be served from the same website... consider a forum...u enter some javascript in comments.....when another user opens the forum thread, the javascript u entered would be executed...that is the way i suppose how CSRF works...correct me if i'm wrong.. . The javascript may not send the cookie to the 3rd party website(where the cookie would be rebuilt etc etc..)...it may itself construct some post request(eg to transfer money from the users account to the hackers account)
Regards, Pankaj
I don't think it's up to a framework to solve all potential security issues in an application. If certain security issues are common in many applications it could be cool to extract the solutions for these problems and either publish them in a plugin or merge them into Rails. If you're interested it would be great if you could do a proof of concept for these issues your seeing and write up a patch.
Manfred
That can't happen: javascript can't read cookies from domains it wasn't served from.
Fred
the javascript would be served from the same website...
No, it wouldn't. It would be served from the forum website.
consider a forum...u enter some javascript in comments.....when another user opens the forum thread, the javascript u entered would be executed...that is the way i suppose how CSRF works...correct me if i'm wrong..
You are wrong. The javascript served from the forum thread can not read cookies from the target site and thus cannot build the needed authenticity token. And even if it could read the cookies, it would also need to know the secret key used to build the token.
If you are talking about a case where the forum site would be both the target and the source of the malicious code, then it would be a different thing. However, it wouldn't really be cross-site anymore. Also, that is something you as a site developer can and should do something about. You should never let users enter arbitrary javascript onto your site. However, you cannot prevent other site owners from been lax about security, and thus need to secure yourself against CSRF.
If the script can transfer the cookie, it can also transfer the authentication_token. So now the 3rd party application has both cookie and the token :).
Please re-read the CSRF page on Wikipedia. It seems that you don't really understand what CSRF is about. It's not about Javascript run on your site, it's about third-party page sending requests to your site (from javascript or even using something like image tags). That third party page does not have access to the cookies of your site.
If it doesnot provide complete solution, everyone should know about it...so that they donot assume that it is.
Define a complete solution. Oh, right, there is no such thing.
I'm sure no one has said that authenticity_token would be a complete solution to web app security and I have a hard time thinking many people would ever assume that.
Like I (and Manfred) said before, it is hard to build shields against even specific threats on the framework level. CSRF is probably one of the few low-hanging fruits. A general solution for all threats is just a pipedream. But if you find a generic solution against specific cases you encounter that would be easy to implement, go ahead and send a patch.
//jarkko
the javascript would be served from the same website... consider a forum...u enter some javascript in comments.....when another user opens the forum thread, the javascript u entered would be executed...that is the way i suppose how CSRF works...correct me if i'm wrong.. .
You are describing XSS, not CSRF.
XSS is basically getting a script to run when a user views a page, i.e. your forum comments example.
CSRF, as Jarkko stated, is about sending requests to your server which are automatically authenticated, usually by the cookie information that the browser sends for that domain.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks