HttpOnly cookies by default

[Stephen Touset]

Earlier, someone proposed on the GH issues tracker that Rails default all cookies to HttpOnly[1]. Rails already makes the session cookie HttpOnly, but given a general to keep Rails secure-by-default, it would probably be best if *all* cookies defaulted to HttpOnly. This would be a compatibility-breaking change, but it wouldn't be difficult to add a configuration option that can be defaulted to false for existing Rails apps that are upgraded.

I'm more than happy to write the code for this change, but wanted to discuss it here first to see if anyone objects strongly. Josh Peek had concerns with backwards compatibility, but I think my proposal above for a configuration option should satisfy them. Anyone care to weigh in?

[1] https://github.com/rails/rails/issues/1449

[fedesoria]

I would like to see this happen, since when dealing with Enterprise Vulnerability Scans it always comes up.

[Gabriel Sobrinho]

I would argue that if you have some information that can't be hijacked and even parsed on javascript (httponly cookies can't be read on javascript at all), why would you use cookies instead of the rails session?

[Rodrigo Rosenfeld Rosas]

I don't think you can use Rails sessions without cookies support...

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Matt Jones]

I’ve had to resort to some pretty weird cookie stuff when passing data between a Rails app and non-Rails applications. The session is handy, but parsing it anywhere but in Rails is difficult and *updating* it outside of Rails is more difficult.

—Matt Jones

[Gabriel Sobrinho]

I can't be sure but using cookies for that sounds the wrong solution for me, you have better options like a shared database, a redis instance may work.

You'll need to use a cookie to share a session identifier (I would use a uuid) between the applications but reducing it to just one cookie may mitigate the need to mark all shared cookies as http only, but I don't know your environment, so please don't take this a recommendation ;)

About rails, I would be concerned to backwards compatibility too, but we need to have access to both options (httponly and not httponly).

Something like cookies.secure[:key] = 'value' and cookies[:key] = 'value' may work but it won't be secure as default.

If we are choosing for security first, we may have cookies.insecure[:key] = 'value' or something like that.

[Stephen Touset]

In that case, even that shared cookie should likely be HttpOnly anyway.

I'm not quite following why anyone would really oppose such a change here — Rails needs to maintain a strong secure-by-default stance, and every case where developers have to opt-in to security is a case where many developers will not. As long as there's a flag that's set to the current behavior for existing projects, and defaults to secure behavior for new projects, there shouldn't be any backward-compatibility concerns. 

If you need to access a cookie in JS, set it in JS or disable HttpOnly for that specific cookie. If a developer doesn't upfront anticipate it being used in JS, then it shouldn't be *allowed* to be accessed from there.

--
Stephen Touset
ste...@touset.org

You received this message because you are subscribed to a topic in the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubyonrails-core/yDzoifkfqvc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubyonrails-co...@googlegroups.com.

[david....@hired.com]

Is this proposal dead? I would like to see this as well. It seems like a default worth having, and an optional way to turn it off solves the backwards compatibility problem.