Re: [Rails-core] HttpOnly cookies by default
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. On Tuesday, May 27, 2014 at 9:56:58 AM UTC-7, Stephen Touset wrote: 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 javascript: On Mon, May 19, 2014 at 5:34 AM, Gabriel Sobrinho gabriel@gmail.com javascript: wrote: 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. On Sunday, May 18, 2014 4:25:35 PM UTC-3, Matt jones wrote: 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 On May 17, 2014, at 9:12 AM, Gabriel Sobrinho gabriel@gmail.com wrote: 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? On Friday, May 16, 2014 7:07:42 PM UTC-3, fedesoria wrote: I would like to see this happen, since when dealing with Enterprise Vulnerability Scans it always comes up. On Monday, January 7, 2013 2:09:42 PM UTC-8, Stephen Touset wrote: 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 -- 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. -- 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 javascript:. To post to this group, send email to rubyonra...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- 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-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at
Re: [Rails-core] HttpOnly cookies by default
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 step...@touset.org On Mon, May 19, 2014 at 5:34 AM, Gabriel Sobrinho gabriel.sobri...@gmail.com wrote: 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. On Sunday, May 18, 2014 4:25:35 PM UTC-3, Matt jones wrote: 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 On May 17, 2014, at 9:12 AM, Gabriel Sobrinho gabriel@gmail.comjavascript: wrote: 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? On Friday, May 16, 2014 7:07:42 PM UTC-3, fedesoria wrote: I would like to see this happen, since when dealing with Enterprise Vulnerability Scans it always comes up. On Monday, January 7, 2013 2:09:42 PM UTC-8, Stephen Touset wrote: 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 -- 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 javascript:. To post to this group, send email to rubyonra...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- 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-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- 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-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] HttpOnly cookies by default
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. On Sunday, May 18, 2014 4:25:35 PM UTC-3, Matt jones wrote: 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 On May 17, 2014, at 9:12 AM, Gabriel Sobrinho gabriel@gmail.comjavascript: wrote: 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? On Friday, May 16, 2014 7:07:42 PM UTC-3, fedesoria wrote: I would like to see this happen, since when dealing with Enterprise Vulnerability Scans it always comes up. On Monday, January 7, 2013 2:09:42 PM UTC-8, Stephen Touset wrote: 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 -- 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 javascript:. To post to this group, send email to rubyonra...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- 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-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
Re: [Rails-core] HttpOnly cookies by default
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 On May 17, 2014, at 9:12 AM, Gabriel Sobrinho gabriel.sobri...@gmail.com wrote: 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? On Friday, May 16, 2014 7:07:42 PM UTC-3, fedesoria wrote: I would like to see this happen, since when dealing with Enterprise Vulnerability Scans it always comes up. On Monday, January 7, 2013 2:09:42 PM UTC-8, Stephen Touset wrote: 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 -- 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-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
[Rails-core] HttpOnly cookies by default
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 -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/5j4eYHz-d1AJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
