While reading all the hubhub about Google, I also read a bit about cross site request forgery (CSRF). The solution for CSRF appears to be: a hidden form variable from the session cookie (which I believe is already a salted-hash of the session id) included on the form, and verify that the requests are POST''ed and include the hidden form variable. Here''s my thoughts. Change start_form_tag to automatically include the hidden form variable. Include a default verify that all POST''s have the hidden form variable. First, am I missing anything? Second, shouldn''t this, or something like it, be the default in Rails? Jack Christensen
On 8 May 2005, at 21:43, Jack Christensen wrote:> The solution for CSRF appears to be: a hidden form variable from > the session cookie (which I believe is already a salted-hash of the > session id) included on the form, and verify that the requests are > POST''ed and include the hidden form variable. > > Here''s my thoughts. > > Change start_form_tag to automatically include the hidden form > variable. > > Include a default verify that all POST''s have the hidden form > variable. > > First, am I missing anything? > > Second, shouldn''t this, or something like it, be the default in Rails?Yes yes yes yes yes. And no. While Rails should definitely, absolutely include out-of-the-box support for CSRF prevention, I don''t think it should be on by default - if only because I''m very wary of "magic" features like that which don''t have a clear explanation. That said, it should be insanely easy to turn on (an extra argument to start_form_tag, supported by some kind of global preference that can be set in the application.rb file). This feature would be a big bonus for the Rails marketing effort as well, not that it really needs one ;) Cheers, Simon Willison http://simon.incutio.com/
>> Yes yes yes yes yes. And no. While Rails should definitely, > absolutely include out-of-the-box support for CSRF prevention, I > don''t think it should be on by default - if only because I''m very > wary of "magic" features like that which don''t have a clear > explanation. That said, it should be insanely easy to turn on (an > extra argument to start_form_tag, supported by some kind of global > preference that can be set in the application.rb file). > > This feature would be a big bonus for the Rails marketing effort as > well, not that it really needs one ;) +1 from me! While we are speeking of Security and the Web. Fellow Mac folks, I hope you have disabled "open safe files after download" in Safari: http://blog.innerewut.de/articles/2005/05/09/apple-s-dashboard-and-security Greets, Jonathan -- Jonathan Weiss jw-eM0Q5iXcOashFhg+JK9F0w@public.gmane.org http://blog.innerewut.de
On Monday, May 9, 2005, 7:08:37 AM, Simon wrote:>> Second, shouldn''t this, or something like it, be the default in Rails?> Yes yes yes yes yes. And no. While Rails should definitely, > absolutely include out-of-the-box support for CSRF prevention, I > don''t think it should be on by default - if only because I''m very > wary of "magic" features like that which don''t have a clear > explanation. That said, it should be insanely easy to turn on (an > extra argument to start_form_tag, supported by some kind of global > preference that can be set in the application.rb file).Your reasoning is not a convincing case for it not being enabled by default. There''s already plenty of magic in Rails, and Rails eschews the kind of configuration you''re talking about. It should only not be default if there''s a compelling use case where you wouldn''t use the feature. Cheers, Gavin
On 9 May 2005, at 01:06, Gavin Sinclair wrote:>> Yes yes yes yes yes. And no. While Rails should definitely, >> absolutely include out-of-the-box support for CSRF prevention, I >> don''t think it should be on by default - if only because I''m very >> wary of "magic" features like that which don''t have a clear >> explanation. That said, it should be insanely easy to turn on (an >> extra argument to start_form_tag, supported by some kind of global >> preference that can be set in the application.rb file). >> > > Your reasoning is not a convincing case for it not being enabled by > default. There''s already plenty of magic in Rails, and Rails eschews > the kind of configuration you''re talking about. > > It should only not be default if there''s a compelling use case where > you wouldn''t use the feature.Fair enough. In that case, make it super-easy to turn off (on a global or per-form basis) and I''ll be happy. Cheers, Simon
On 09/05/2005, at 10:06 AM, Gavin Sinclair wrote:> On Monday, May 9, 2005, 7:08:37 AM, Simon wrote: > >>> Second, shouldn''t this, or something like it, be the default in >>> Rails? > >> Yes yes yes yes yes. And no. While Rails should definitely, >> absolutely include out-of-the-box support for CSRF prevention, I >> don''t think it should be on by default - if only because I''m very >> wary of "magic" features like that which don''t have a clear >> explanation. That said, it should be insanely easy to turn on (an >> extra argument to start_form_tag, supported by some kind of global >> preference that can be set in the application.rb file). > > Your reasoning is not a convincing case for it not being enabled by > default. There''s already plenty of magic in Rails, and Rails eschews > the kind of configuration you''re talking about. > > It should only not be default if there''s a compelling use case where > you wouldn''t use the feature.It''s a bit like the HTML escaping syntax ("<%=h") that A LOT of people seem to be forgetting to use. We can not automatically provide a secure application for free -- the Rails programmer must be aware of web app security to make a secure application. I''d hate for people to feel comfortable and say "We''re using Rails, so it must be secure", so with this I believe we should provide the option, but it should be disabled by default. Also, IMO Rails should be optimised for the public use case: a form on a site that''s not behind authentication and doesn''t need form security. Maybe the login generator can automatically set the correct flags to turn on form security for secured controllers/actions? - tim lucas
On 09/05/2005, at 11:02 AM, Tim Lucas wrote:> Maybe the login generator can automatically set the correct flags to > turn on form security for secured controllers/actions?And it should also set the proper HTTP headers (e.g. "Cache-Control: private, no-store, must-revalidate") - tim lucas