Put simply, Cross Site Request Forgery (CSRF) allows external parties to make requests to your webapp whilst pretending to be legitimate users using your HTML pages. For a much better explanation, see the original BugTrac posting .
CSRF is not a Rails-specific problem, but for those people allowing unauthorised access to their apps (e.g. Wikis that don’t require a login), it can be a problem.
The accepted solution is to have some server-side code that ensures the request was made from the original page. When generated by the serverside app, any forms (in fact, any URL’s that are serving anything other than static content) should include a server-generated token that expires if not used soon enough. For session-based apps, this token can be generated at login, and used for the duration of the session. When making requests, use a filter to validate the token, and only let them through to the underlying controller if the token is valid.
Malicious scripters generating form requests in an attempt to delete all your wiki content won’t have the token, and won’t be able to cause any damage.
As yet, no code exists to do this in an automatic fashion for Rails, although I’m sure some kind soul will submit a patch soon. :-)
Note: I was not the original author of this page and do not agree with all the points it makes; I’m simply restoring it verbatum from my backup.
especially after reading 37signals article about google cache
i would not use get for any changing stuff at all. POST should be a bit harder to pretend.
—darix?
Yeah, but only a little… See this article along with Paros
There’s also the Security Extensions Plugin by Tim Lucas which gives you this…
Put simply, Cross Site Request Forgery (CSRF) allows external parties to make requests to your webapp whilst pretending to be legitimate users using your HTML pages. For a much better explanation, see the original BugTrac posting .
CSRF is not a Rails-specific problem, but for those people allowing unauthorised access to their apps (e.g. Wikis that don’t require a login), it can be a problem.
The accepted solution is to have some server-side code that ensures the request was made from the original page. When generated by the serverside app, any forms (in fact, any URL’s that are serving anything other than static content) should include a server-generated token that expires if not used soon enough. For session-based apps, this token can be generated at login, and used for the duration of the session. When making requests, use a filter to validate the token, and only let them through to the underlying controller if the token is valid.
Malicious scripters generating form requests in an attempt to delete all your wiki content won’t have the token, and won’t be able to cause any damage.
As yet, no code exists to do this in an automatic fashion for Rails, although I’m sure some kind soul will submit a patch soon. :-)
Note: I was not the original author of this page and do not agree with all the points it makes; I’m simply restoring it verbatum from my backup.
especially after reading 37signals article about google cache
i would not use get for any changing stuff at all. POST should be a bit harder to pretend.
—darix?
Yeah, but only a little… See this article along with Paros
There’s also the Security Extensions Plugin by Tim Lucas which gives you this…