https://github.com/rails/rails/issues/12374#issuecomment-29446761 Here in discussion I proposed to deprecate JS responder because this technique is insecure and not pragmatic way to transfer data. It can be exploited in this way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html i find this bug very often so i know what i''m talking about. With it attacker can steal user data and authenticity_token if templates with form were leaked too. -- 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+unsubscribe@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/groups/opt_out.
On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote:> https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this > way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too.Removing it seems fine to me, but I suppose we should deprecate it first. Don''t people need to specifically say "render js: whatever"? I think 100% of "render js:" cases can be implemented using JSON. But maybe I am wrong. -- Aaron Patterson http://tenderlovemaking.com/ -- 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+unsubscribe@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/groups/opt_out.
A lot of people use the js responder with ujs, but there are often bugs with how jQuery handles the automatic code execution of js ajax responses, so I agree, it''s something I wouldn''t mind deprecating. One reason people tend to use js responders is to use js.erb to embed values from ruby into the returned js, but I think a better way to do this is to use json and HTML data attributes to embed values when necessary. On Nov 28, 2013 3:49 PM, "Aaron Patterson" <tenderlove@ruby-lang.org> wrote:> On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: > > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > > > Here in discussion I proposed to deprecate JS responder because this > > technique is insecure and not pragmatic way to transfer data. > > It can be exploited in this > > way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > > > i find this bug very often so i know what i''m talking about. With it > > attacker can steal user data and authenticity_token if templates with > form > > were leaked too. > > Removing it seems fine to me, but I suppose we should deprecate it > first. Don''t people need to specifically say "render js: whatever"? > > I think 100% of "render js:" cases can be implemented using JSON. But > maybe I am wrong. > > -- > Aaron Patterson > http://tenderlovemaking.com/ > > -- > 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+unsubscribe@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/groups/opt_out. >-- 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+unsubscribe@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/groups/opt_out.
I am not against removing this (I personally don''t have use for this anymore), but the reason behind the removal this seems unclear to me. If it''s just "let''s remove this because no one uses this anymore" (and if that''s true), or "Rails want to discourage this type of architecture in favour of moving these type of processing to the client", then fine. But I am not sure if I fully understand the security angle here. Specifically, in Egor''s blog post: 1. *"Broken concept & architecture. This feels as weird as the client-side sending code that is going to be evaled on the server-side... wait... Rails programmers had similar thing for a while :/"* But in the context of a web application, by definition you are always sending JavaScript code from your server to be eval()-ed in the client (browser) :) Whether the code is in /assets/javascript or in your controller, there''s really no difference here. So I''ll have to assume you are talking about eval()-ing code that contains user-supplied data that''s bad. Which is fair enough, considering there''s usually a safer way to do this (encoding the user-supplied data as JSON first). But as Andrew pointed out on the Github issue, there might be legitimate use cases for using this to return code that does NOT contain user-supplied data. I think those use cases needs to be understood properly (and we need to investigate/suggest alternatives for those cases) to ensure we are not removing a useful feature just because it''s subject to abuse. 2. *"**Escaping user content and putting it into Javascript can be more painful and having more pitfalls then normal HTML escaping. ... **There can be more special characters and XSS you should care about.**"* Is this not already adequately addressed by the escaping helpers Rails provide? If so, regardless of whether we remove the js responder, those issues should be reported and fixed in Rails itself. I just opened https://github.com/rails/rails/pull/13073 yesterday to patch json_escape to make it useful again (please provide feedback), and I plan to submit another PR to improve the docs on escape_javascript to make the intended use cases more clear. If it is already possible to correctly escape input for use in the JS responder, just that it''s difficult to do it correctly, the problem might not lie in the JS responder pre-se and we should take this opportunity to address them. 3. *"JSONP-like data leaking. If app accepts GET request and responds with Javascript containing private data in it attacker can use fake JS functions to leak data from the response."* I assume you are talking about CSRF attacks where a page on a third-party domain can make requests to your site on your user''s behalf. But like you said, this problem also exists in JSONP. In fact, it''s probably much easier to exploit this in JSONP (because you can control the name of the callback) than a JS response that updates a certain part of the page. So I''m not sure if this is really JS responder''s fault. And like Andrew said, in his use case there''s nothing to leak. Maybe I am not understanding this point correctly. If you can provide some examples based on the apps you see in the field it will be very helpful. 4. *"UPD as pointed out on HN evaling response will mess with your global namespace and there is no way to jump into closure you created request in.."* (I suppose this is not related to security.) If you are doing a lot you should definitely architect your client-side JavaScript properly, that I agree 100% (I mainly write full-blown single page apps these day for my day job, so believe me when I say we are in agreement :). But in cases where you are delivering a small, simple payload to update a small part of the page, I don''t know if that''s super evil and should be strongly discouraged. I don''t do this, so I''m not really in a good position to defend it. Again, maybe it''s just a case of "no one uses this anymore so it''s not worth supporting", and that''s fine by me. But you brought up security, so I want to make sure we address your concerns properly. Godfrey On Thu, Nov 28, 2013 at 1:02 PM, Steve Schwartz <steve@alfajango.com> wrote:> A lot of people use the js responder with ujs, but there are often bugs > with how jQuery handles the automatic code execution of js ajax responses, > so I agree, it''s something I wouldn''t mind deprecating. > > One reason people tend to use js responders is to use js.erb to embed > values from ruby into the returned js, but I think a better way to do this > is to use json and HTML data attributes to embed values when necessary. > On Nov 28, 2013 3:49 PM, "Aaron Patterson" <tenderlove@ruby-lang.org> > wrote: > >> On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: >> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> > >> > Here in discussion I proposed to deprecate JS responder because this >> > technique is insecure and not pragmatic way to transfer data. >> > It can be exploited in this >> > way >> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> > >> > i find this bug very often so i know what i''m talking about. With it >> > attacker can steal user data and authenticity_token if templates with >> form >> > were leaked too. >> >> Removing it seems fine to me, but I suppose we should deprecate it >> first. Don''t people need to specifically say "render js: whatever"? >> >> I think 100% of "render js:" cases can be implemented using JSON. But >> maybe I am wrong. >> >> -- >> Aaron Patterson >> http://tenderlovemaking.com/ >> >> -- >> 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+unsubscribe@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/groups/opt_out. >> > -- > 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+unsubscribe@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/groups/opt_out. >-- 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+unsubscribe@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/groups/opt_out.
I believe the primary use case for js responder is remote forms, where you are not doing the request yourself, so a js response is the simplest and most natural approach there. This is not inherently insecure so should not be deprecated just because it does not feel good to some. On Thursday, November 28, 2013 3:49:40 PM UTC-5, Aaron Patterson wrote:> > On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: > > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > > > Here in discussion I proposed to deprecate JS responder because this > > technique is insecure and not pragmatic way to transfer data. > > It can be exploited in this > > way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > > > i find this bug very often so i know what i''m talking about. With it > > attacker can steal user data and authenticity_token if templates with > form > > were leaked too. > > Removing it seems fine to me, but I suppose we should deprecate it > first. Don''t people need to specifically say "render js: whatever"? > > I think 100% of "render js:" cases can be implemented using JSON. But > maybe I am wrong. > > -- > Aaron Patterson > http://tenderlovemaking.com/ >-- 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+unsubscribe@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/groups/opt_out.
A lot of the proposed issues aren''t really too bad IMO, they''re mainly just related to one developer''s preferences and taste over another. I personally don''t think returning JS from an ajax call is much (if any) worse than returning HTML. It''s all just your server rendering some markup/code for the browser to interpret. However, from the UJS side, the main issue with using JS as the response, is that the user has no control over the exact context of the automatic eval being done by jQuery, or exactly when during the callback sequence the code is eval''d. This actually caused code to break at one point due to a jQuery update, which would cause issues if your returned JS replaced the element that triggered the UJS remote (ajax) call. See: https://github.com/rails/jquery-ujs/issues/223#issuecomment-2791098 That being said, I''m not necessarily in the "we should deprecate this" camp. I''m somewhat indifferent. Deprecation means one less thing to maintain (and would allow me to delete all of one line in UJS). -- Steve Schwartz On Thursday, November 28, 2013 at 4:45 PM, Alex wrote:> I believe the primary use case for js responder is remote forms, where you are not doing the request yourself, so a js response is the simplest and most natural approach there. This is not inherently insecure so should not be deprecated just because it does not feel good to some. > > On Thursday, November 28, 2013 3:49:40 PM UTC-5, Aaron Patterson wrote: > > On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: > > > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > > > > > Here in discussion I proposed to deprecate JS responder because this > > > technique is insecure and not pragmatic way to transfer data. > > > It can be exploited in this > > > way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > > > > > i find this bug very often so i know what i''m talking about. With it > > > attacker can steal user data and authenticity_token if templates with form > > > were leaked too. > > > > Removing it seems fine to me, but I suppose we should deprecate it > > first. Don''t people need to specifically say "render js: whatever"? > > > > I think 100% of "render js:" cases can be implemented using JSON. But > > maybe I am wrong. > > > > -- > > Aaron Patterson > > http://tenderlovemaking.com/ > -- > 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+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
About the HTML rendering use case, I would point out that it could be adequately solved using render_to_string, and IMHO more elegantly, since the related JS could be included in the assets, and so organized toghether with the other JS source. I can''t think about use cases where RJS is preferable over render :json, does anyone do? Il giorno giovedì 28 novembre 2013 22:42:26 UTC+1, Godfrey Chan ha scritto:> > I am not against removing this (I personally don''t have use for this > anymore), but the reason behind the removal this seems unclear to me. > > If it''s just "let''s remove this because no one uses this anymore" (and if > that''s true), or "Rails want to discourage this type of architecture in > favour of moving these type of processing to the client", then fine. But I > am not sure if I fully understand the security angle here. > > Specifically, in Egor''s blog post: > > > 1. *"Broken concept & architecture. This feels as weird as the > client-side sending code that is going to be evaled on the server-side... > wait... Rails programmers had similar thing for a while :/"* > > But in the context of a web application, by definition you are > always sending JavaScript code from your server to be eval()-ed in the > client (browser) :) Whether the code is in /assets/javascript or in your > controller, there''s really no difference here. > > So I''ll have to assume you are talking about eval()-ing code that contains > user-supplied data that''s bad. Which is fair enough, considering there''s > usually a safer way to do this (encoding the user-supplied data as JSON > first). > > But as Andrew pointed out on the Github issue, there might be legitimate > use cases for using this to return code that does NOT contain user-supplied > data. I think those use cases needs to be understood properly (and we need > to investigate/suggest alternatives for those cases) to ensure we are not > removing a useful feature just because it''s subject to abuse. > > > 2. *"**Escaping user content and putting it into Javascript can be more > painful and having more pitfalls then normal HTML escaping. ... **There > can be more special characters and XSS you should care about.**"* > > Is this not already adequately addressed by the escaping helpers Rails > provide? If so, regardless of whether we remove the js responder, those > issues should be reported and fixed in Rails itself. I just opened > https://github.com/rails/rails/pull/13073 yesterday to patch json_escape > to make it useful again (please provide feedback), and I plan to submit > another PR to improve the docs on escape_javascript to make the intended > use cases more clear. > > If it is already possible to correctly escape input for use in the JS > responder, just that it''s difficult to do it correctly, the problem might > not lie in the JS responder pre-se and we should take this opportunity to > address them. > > 3. *"JSONP-like data leaking. If app accepts GET request and responds > with Javascript containing private data in it attacker can use fake JS > functions to leak data from the response."* > > I assume you are talking about CSRF attacks where a page on a third-party > domain can make requests to your site on your user''s behalf. But like you > said, this problem also exists in JSONP. In fact, it''s probably much easier > to exploit this in JSONP (because you can control the name of the callback) > than a JS response that updates a certain part of the page. So I''m not sure > if this is really JS responder''s fault. And like Andrew said, in his use > case there''s nothing to leak. > > Maybe I am not understanding this point correctly. If you can provide some > examples based on the apps you see in the field it will be very helpful. > > 4. *"UPD as pointed out on HN evaling response will mess with your global > namespace and there is no way to jump into closure you created request > in.."* > > (I suppose this is not related to security.) > > If you are doing a lot you should definitely architect your client-side > JavaScript properly, that I agree 100% (I mainly write full-blown single > page apps these day for my day job, so believe me when I say we are in > agreement :). But in cases where you are delivering a small, simple payload > to update a small part of the page, I don''t know if that''s super evil and > should be strongly discouraged. > > I don''t do this, so I''m not really in a good position to defend it. Again, > maybe it''s just a case of "no one uses this anymore so it''s not worth > supporting", and that''s fine by me. But you brought up security, so I want > to make sure we address your concerns properly. > > Godfrey > > > > On Thu, Nov 28, 2013 at 1:02 PM, Steve Schwartz <st...@alfajango.com<javascript:> > > wrote: > >> A lot of people use the js responder with ujs, but there are often bugs >> with how jQuery handles the automatic code execution of js ajax responses, >> so I agree, it''s something I wouldn''t mind deprecating. >> >> One reason people tend to use js responders is to use js.erb to embed >> values from ruby into the returned js, but I think a better way to do this >> is to use json and HTML data attributes to embed values when necessary. >> On Nov 28, 2013 3:49 PM, "Aaron Patterson" <tende...@ruby-lang.org<javascript:>> >> wrote: >> >>> On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: >>> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 >>> > >>> > Here in discussion I proposed to deprecate JS responder because this >>> > technique is insecure and not pragmatic way to transfer data. >>> > It can be exploited in this >>> > way >>> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >>> > >>> > i find this bug very often so i know what i''m talking about. With it >>> > attacker can steal user data and authenticity_token if templates with >>> form >>> > were leaked too. >>> >>> Removing it seems fine to me, but I suppose we should deprecate it >>> first. Don''t people need to specifically say "render js: whatever"? >>> >>> I think 100% of "render js:" cases can be implemented using JSON. But >>> maybe I am wrong. >>> >>> -- >>> Aaron Patterson >>> http://tenderlovemaking.com/ >>> >>> -- >>> 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.com<javascript:> >>> . >>> Visit this group at http://groups.google.com/group/rubyonrails-core. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> -- >> 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.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> > >-- 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+unsubscribe@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/groups/opt_out.
I am -1 for deprecating the js responders Personally I find using the js.erb templates much easier, more DRY and more expressive then returning a HTML string as a JSON element. Any JavaScript in the js.erb should be specific to initializing the rendered HTML and would exist in the event handler of the AJAX call anyways, so having it in the assets seems of little benefit. All the reusable code should live in the assets either way. It does not seem like removing it provides any benefit to the people who would prefer to use all JSON. So, other than forcing a preference on the community, why deprecate it? On Thu, Nov 28, 2013 at 7:34 PM, Maurizio De Santis < desantis.maurizio@gmail.com> wrote:> About the HTML rendering use case, I would point out that it could be > adequately solved using render_to_string, and IMHO more elegantly, since > the related JS could be included in the assets, and so organized toghether > with the other JS source. > > I can''t think about use cases where RJS is preferable over render :json, > does anyone do? > > Il giorno giovedì 28 novembre 2013 22:42:26 UTC+1, Godfrey Chan ha scritto: >> >> I am not against removing this (I personally don''t have use for this >> anymore), but the reason behind the removal this seems unclear to me. >> >> If it''s just "let''s remove this because no one uses this anymore" (and if >> that''s true), or "Rails want to discourage this type of architecture in >> favour of moving these type of processing to the client", then fine. But I >> am not sure if I fully understand the security angle here. >> >> Specifically, in Egor''s blog post: >> >> >> 1. *"Broken concept & architecture. This feels as weird as the >> client-side sending code that is going to be evaled on the server-side... >> wait... Rails programmers had similar thing for a while :/"* >> >> But in the context of a web application, by definition you are >> always sending JavaScript code from your server to be eval()-ed in the >> client (browser) :) Whether the code is in /assets/javascript or in your >> controller, there''s really no difference here. >> >> So I''ll have to assume you are talking about eval()-ing code that >> contains user-supplied data that''s bad. Which is fair enough, considering >> there''s usually a safer way to do this (encoding the user-supplied data as >> JSON first). >> >> But as Andrew pointed out on the Github issue, there might be legitimate >> use cases for using this to return code that does NOT contain user-supplied >> data. I think those use cases needs to be understood properly (and we need >> to investigate/suggest alternatives for those cases) to ensure we are not >> removing a useful feature just because it''s subject to abuse. >> >> >> 2. *"**Escaping user content and putting it into Javascript can be more >> painful and having more pitfalls then normal HTML escaping. ... **There >> can be more special characters and XSS you should care about.**"* >> >> Is this not already adequately addressed by the escaping helpers Rails >> provide? If so, regardless of whether we remove the js responder, those >> issues should be reported and fixed in Rails itself. I just opened >> https://github.com/rails/rails/pull/13073 yesterday to patch json_escape >> to make it useful again (please provide feedback), and I plan to submit >> another PR to improve the docs on escape_javascript to make the intended >> use cases more clear. >> >> If it is already possible to correctly escape input for use in the JS >> responder, just that it''s difficult to do it correctly, the problem might >> not lie in the JS responder pre-se and we should take this opportunity to >> address them. >> >> 3. *"JSONP-like data leaking. If app accepts GET request and responds >> with Javascript containing private data in it attacker can use fake JS >> functions to leak data from the response."* >> >> I assume you are talking about CSRF attacks where a page on a third-party >> domain can make requests to your site on your user''s behalf. But like you >> said, this problem also exists in JSONP. In fact, it''s probably much easier >> to exploit this in JSONP (because you can control the name of the callback) >> than a JS response that updates a certain part of the page. So I''m not sure >> if this is really JS responder''s fault. And like Andrew said, in his use >> case there''s nothing to leak. >> >> Maybe I am not understanding this point correctly. If you can provide >> some examples based on the apps you see in the field it will be very >> helpful. >> >> 4. *"UPD as pointed out on HN evaling response will mess with your >> global namespace and there is no way to jump into closure you created >> request in.."* >> >> (I suppose this is not related to security.) >> >> If you are doing a lot you should definitely architect your client-side >> JavaScript properly, that I agree 100% (I mainly write full-blown single >> page apps these day for my day job, so believe me when I say we are in >> agreement :). But in cases where you are delivering a small, simple payload >> to update a small part of the page, I don''t know if that''s super evil and >> should be strongly discouraged. >> >> I don''t do this, so I''m not really in a good position to defend it. >> Again, maybe it''s just a case of "no one uses this anymore so it''s not >> worth supporting", and that''s fine by me. But you brought up security, so I >> want to make sure we address your concerns properly. >> >> Godfrey >> >> >> >> On Thu, Nov 28, 2013 at 1:02 PM, Steve Schwartz <st...@alfajango.com>wrote: >> >>> A lot of people use the js responder with ujs, but there are often bugs >>> with how jQuery handles the automatic code execution of js ajax responses, >>> so I agree, it''s something I wouldn''t mind deprecating. >>> >>> One reason people tend to use js responders is to use js.erb to embed >>> values from ruby into the returned js, but I think a better way to do this >>> is to use json and HTML data attributes to embed values when necessary. >>> On Nov 28, 2013 3:49 PM, "Aaron Patterson" <tende...@ruby-lang.org> >>> wrote: >>> >>>> On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: >>>> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 >>>> > >>>> > Here in discussion I proposed to deprecate JS responder because this >>>> > technique is insecure and not pragmatic way to transfer data. >>>> > It can be exploited in this >>>> > way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like- >>>> techniques.html >>>> > >>>> > i find this bug very often so i know what i''m talking about. With it >>>> > attacker can steal user data and authenticity_token if templates with >>>> form >>>> > were leaked too. >>>> >>>> Removing it seems fine to me, but I suppose we should deprecate it >>>> first. Don''t people need to specifically say "render js: whatever"? >>>> >>>> I think 100% of "render js:" cases can be implemented using JSON. But >>>> maybe I am wrong. >>>> >>>> -- >>>> Aaron Patterson >>>> http://tenderlovemaking.com/ >>>> >>>> -- >>>> 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/groups/opt_out. >>>> >>> -- >>> 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/groups/opt_out. >>> >> >> -- > 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+unsubscribe@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/groups/opt_out. >-- Scott Johnson -- 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+unsubscribe@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/groups/opt_out.
>Maybe I am not understanding this point correctly. If you can provide someexamples based on the apps you see in the field it will be very helpful. I found this leaking on Redmine, Gitlab and Spree + tons of client apps i audit. On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
Focus on security concern. I repeat - any GET accessible .js.erb IS a vulnerability because leaks all data it has inside. All "i use it because it''s fast/convenient" means nothing if it''s a vulnerable technique. IMO On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
Normally can be exploited this way:
function $(){ return {html: function(){
console.log(''LEAKED'',arguments);}}};
document.write(''<script
src="http://SITE/objects.js"></script>'')
On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov
wrote:>
> https://github.com/rails/rails/issues/12374#issuecomment-29446761
>
> Here in discussion I proposed to deprecate JS responder because this
> technique is insecure and not pragmatic way to transfer data.
> It can be exploited in this way
> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html
>
> i find this bug very often so i know what i''m talking about. With
it
> attacker can steal user data and authenticity_token if templates with form
> were leaked too.
>
>
>
>
--
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+unsubscribe@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/groups/opt_out.
Not only are js.erb templates not deprecated, they are a great way to develop an application with Ajax responses where you can reuse your server-side templates. It''s fine to explore ways to make this more secure by default, but the fundamental development style of returning JS as a response is both architecturally sound and an integral part of Rails. So that''s not going anywhere. So let''s instead explore ways of having better escaping tools, warnings, or defaults that''ll work with the wonders of RJS. -- 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+unsubscribe@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/groups/opt_out.
@dhh as i mentioned above for GET request this will always be a security breach. So leaving it for POST only? Doesn''t make sense. Also https://twitter.com/homakov/status/406426491937759232 On Friday, November 29, 2013 10:11:06 PM UTC+7, DHH wrote:> > Not only are js.erb templates not deprecated, they are a great way to > develop an application with Ajax responses where you can reuse your > server-side templates. It''s fine to explore ways to make this more secure > by default, but the fundamental development style of returning JS as a > response is both architecturally sound and an integral part of Rails. So > that''s not going anywhere. > > So let''s instead explore ways of having better escaping tools, warnings, > or defaults that''ll work with the wonders of RJS. >-- 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+unsubscribe@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/groups/opt_out.
On Friday, November 29, 2013 10:27:15 PM UTC+7, Egor Homakov wrote:> > @dhh as i mentioned above for GET request this will always be a security > breach. So leaving it for POST only? Doesn''t make sense. > Also https://twitter.com/homakov/status/406426491937759232 > > On Friday, November 29, 2013 10:11:06 PM UTC+7, DHH wrote: >> >> Not only are js.erb templates not deprecated, they are a great way to >> develop an application with Ajax responses where you can reuse your >> server-side templates. It''s fine to explore ways to make this more secure >> by default, but the fundamental development style of returning JS as a >> response is both architecturally sound and an integral part of Rails. So >> that''s not going anywhere. >> >> So let''s instead explore ways of having better escaping tools, warnings, >> or defaults that''ll work with the wonders of RJS. >> >-- 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+unsubscribe@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/groups/opt_out.
Right, I agree that if used incorrectly this be a vector for CSRF attacks. But like you said, this is also a problem for JSONP, which is by far way more popular. So unless we also remove JSONP there problem you are complaining is still there, no? Maybe we should improve the documentation to point out that you should not be using cookies to authenticate "private" JSONP/JS endpoints? Perhaps we can make it easier to do token-based authentication for API requests? Because personally I don''t see JSONP going away. Godfrey On Fri, Nov 29, 2013 at 2:55 AM, Egor Homakov <homakov@gmail.com> wrote:> Focus on security concern. I repeat - any GET accessible .js.erb IS a > vulnerability because leaks all data it has inside. > All "i use it because it''s fast/convenient" means nothing if it''s a > vulnerable technique. IMO > > > On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: > >> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> >> Here in discussion I proposed to deprecate JS responder because this >> technique is insecure and not pragmatic way to transfer data. >> It can be exploited in this way http://homakov.blogspot. >> com/2013/05/do-not-use-rjs-like-techniques.html >> >> i find this bug very often so i know what i''m talking about. With it >> attacker can steal user data and authenticity_token if templates with form >> were leaked too. >> >> >> >> -- > 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+unsubscribe@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/groups/opt_out. >-- 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+unsubscribe@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/groups/opt_out.
On Fri, Nov 29, 2013 at 7:27 AM, Egor Homakov <homakov@gmail.com> wrote:> @dhh as i mentioned above for GET request this will always be a security > breach. >GET requests using Cookies for authentication. That returns non-public data. -- 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+unsubscribe@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/groups/opt_out.
It''s not very proper comparison. Nobody uses JSOPN w/o *a reason*. Autocomplete, as maximum. And security concern of jSONP is way more known than RJS bug (did you see articles on this topic but mine?)>Maybe we should improve the documentation to point out that you should notbe using cookies to authenticate "private" JSONP/JS endpoints IMO, it should be fixed somewhere in code, not in documentation. People don''t read it periodically. Not using cookies for JS responses breaks the idea of templating. For API people should use JSON(P). Why JS? On Saturday, November 30, 2013 7:43:51 AM UTC+7, Godfrey Chan wrote:> > Right, I agree that if used incorrectly this be a vector for CSRF attacks. > But like you said, this is also a problem for JSONP, which is by far way > more popular. So unless we also remove JSONP there problem you are > complaining is still there, no? > > Maybe we should improve the documentation to point out that you should not > be using cookies to authenticate "private" JSONP/JS endpoints? Perhaps we > can make it easier to do token-based authentication for API requests? > > Because personally I don''t see JSONP going away. > > Godfrey > > > On Fri, Nov 29, 2013 at 2:55 AM, Egor Homakov <hom...@gmail.com<javascript:> > > wrote: > >> Focus on security concern. I repeat - any GET accessible .js.erb IS a >> vulnerability because leaks all data it has inside. >> All "i use it because it''s fast/convenient" means nothing if it''s a >> vulnerable technique. IMO >> >> >> On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >> >>> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >>> >>> Here in discussion I proposed to deprecate JS responder because this >>> technique is insecure and not pragmatic way to transfer data. >>> It can be exploited in this way http://homakov.blogspot. >>> com/2013/05/do-not-use-rjs-like-techniques.html >>> >>> i find this bug very often so i know what i''m talking about. With it >>> attacker can steal user data and authenticity_token if templates with form >>> were leaked too. >>> >>> >>> >>> -- >> 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.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> > >-- 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+unsubscribe@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/groups/opt_out.
>GET requests using Cookies for authentication. That returns non-publicdata. most of the time this is the case. JS templates return whole forms with authenticity_token in it! On Saturday, November 30, 2013 7:45:08 AM UTC+7, Godfrey Chan wrote:> > > On Fri, Nov 29, 2013 at 7:27 AM, Egor Homakov <hom...@gmail.com<javascript:> > > wrote: > >> @dhh as i mentioned above for GET request this will always be a security >> breach. >> > > GET requests using Cookies for authentication. That returns non-public > data. >-- 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+unsubscribe@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/groups/opt_out.
Thanks for the explanation. I now better understand the point you made in your original argument and the security concern you raised.> >GET requests using Cookies for authentication. That returns non-publicdata.> most of the time this is the case. JS templates return whole forms withauthenticity_token in it! My point here is not that "JS endpoints that uses cookie + return private data" isn''t a common misuse, that I''m sure you are more qualified to give an opinion than I do, based on the apps you work on. My point is I don''t think that this is inherently flawed and fundamentally impossible to fix (and hence we *must* remove it). Not using cookies for auth is one possible way to fix, but as you pointed out...> Not using cookies for JS responses breaks the idea of templating. For APIpeople should use JSON(P). Why JS? And I think you are quite right. Having to deal with alternative authentication scheme that does not rely (only) on cookies, on both the client and the server side, probably cancels out a lot of the benefits of using JS responses (simplicity etc). However, I think there are probably something else that Rails can do to fix the security concerns you have. For example, we can automatically wrap all JS responses with something like... if(<%= an_array_of_whitelisted_hosts %>.indexOf(window.location.host) > 0){ // ... the actual response goes here ... } What do you think about this? It seems like this would be quite easy for Rails to implement. We can turn this on by default with the list defaults to request.host and provide a way to opt out. Would that address your concerns? Again, I personally don''t use this feature, so I don''t have a strong opinion on whether it should be kept in core. I''m just focusing on the security concerns you raised and see what we can do to make Rails better. And I suspect there are ways to make this feature more secure by default without removing it. Godfrey On Fri, Nov 29, 2013 at 6:05 PM, Egor Homakov <homakov@gmail.com> wrote:> It''s not very proper comparison. Nobody uses JSOPN w/o *a reason*. > Autocomplete, as maximum. And security concern of jSONP is way more known > than RJS bug (did you see articles on this topic but mine?) > > >Maybe we should improve the documentation to point out that you should > not be using cookies to authenticate "private" JSONP/JS endpoints > IMO, it should be fixed somewhere in code, not in documentation. People > don''t read it periodically. > Not using cookies for JS responses breaks the idea of templating. For API > people should use JSON(P). Why JS? > > > On Saturday, November 30, 2013 7:43:51 AM UTC+7, Godfrey Chan wrote: > >> Right, I agree that if used incorrectly this be a vector for CSRF attacks. >> But like you said, this is also a problem for JSONP, which is by far way >> more popular. So unless we also remove JSONP there problem you are >> complaining is still there, no? >> >> Maybe we should improve the documentation to point out that you should >> not be using cookies to authenticate "private" JSONP/JS endpoints? Perhaps >> we can make it easier to do token-based authentication for API requests? >> >> Because personally I don''t see JSONP going away. >> >> Godfrey >> >> >> On Fri, Nov 29, 2013 at 2:55 AM, Egor Homakov <hom...@gmail.com> wrote: >> >>> Focus on security concern. I repeat - any GET accessible .js.erb IS a >>> vulnerability because leaks all data it has inside. >>> All "i use it because it''s fast/convenient" means nothing if it''s a >>> vulnerable technique. IMO >>> >>> >>> On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >>> >>>> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >>>> >>>> Here in discussion I proposed to deprecate JS responder because this >>>> technique is insecure and not pragmatic way to transfer data. >>>> It can be exploited in this way http://homakov.blogspot.co >>>> m/2013/05/do-not-use-rjs-like-techniques.html >>>> >>>> i find this bug very often so i know what i''m talking about. With it >>>> attacker can steal user data and authenticity_token if templates with form >>>> were leaked too. >>>> >>>> >>>> >>>> -- >>> 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/groups/opt_out. >>> >> >> -- > 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+unsubscribe@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/groups/opt_out. >-- 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+unsubscribe@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/groups/opt_out.
location.__defineGetter__(''host'',function(){return
''google.com''})
undefined
location.host
"google.com"
On Saturday, November 30, 2013 9:45:38 AM UTC+7, Godfrey Chan
wrote:>
>
> Thanks for the explanation. I now better understand the point you made in
> your original argument and the security concern you raised.
>
> > >GET requests using Cookies for authentication. That returns
non-public
> data.
> > most of the time this is the case. JS templates return whole forms
with
> authenticity_token in it!
>
> My point here is not that "JS endpoints that uses cookie + return
private
> data" isn''t a common misuse, that I''m sure you are
more qualified to give
> an opinion than I do, based on the apps you work on. My point is I
don''t
> think that this is inherently flawed and fundamentally impossible to fix
> (and hence we *must* remove it). Not using cookies for auth is one possible
> way to fix, but as you pointed out...
>
> > Not using cookies for JS responses breaks the idea of templating. For
> API people should use JSON(P). Why JS?
>
> And I think you are quite right. Having to deal with alternative
> authentication scheme that does not rely (only) on cookies, on both the
> client and the server side, probably cancels out a lot of the benefits of
> using JS responses (simplicity etc).
>
> However, I think there are probably something else that Rails can do to
> fix the security concerns you have. For example, we can automatically wrap
> all JS responses with something like...
>
> if(<%= an_array_of_whitelisted_hosts %>.indexOf(window.location.host)
> 0){
> // ... the actual response goes here ...
> }
>
> What do you think about this? It seems like this would be quite easy for
> Rails to implement. We can turn this on by default with the list defaults
> to request.host and provide a way to opt out. Would that address your
> concerns?
>
> Again, I personally don''t use this feature, so I don''t
have a strong
> opinion on whether it should be kept in core. I''m just focusing on
the
> security concerns you raised and see what we can do to make Rails better.
> And I suspect there are ways to make this feature more secure by default
> without removing it.
>
> Godfrey
>
>
>
> On Fri, Nov 29, 2013 at 6:05 PM, Egor Homakov
<hom...@gmail.com<javascript:>
> > wrote:
>
>> It''s not very proper comparison. Nobody uses JSOPN w/o *a
reason*.
>> Autocomplete, as maximum. And security concern of jSONP is way more
known
>> than RJS bug (did you see articles on this topic but mine?)
>>
>> >Maybe we should improve the documentation to point out that you
should
>> not be using cookies to authenticate "private" JSONP/JS
endpoints
>> IMO, it should be fixed somewhere in code, not in documentation. People
>> don''t read it periodically.
>> Not using cookies for JS responses breaks the idea of templating. For
API
>> people should use JSON(P). Why JS?
>>
>>
>> On Saturday, November 30, 2013 7:43:51 AM UTC+7, Godfrey Chan wrote:
>>
>>> Right, I agree that if used incorrectly this be a vector for CSRF
attacks.
>>> But like you said, this is also a problem for JSONP, which is by
far
>>> way more popular. So unless we also remove JSONP there problem you
are
>>> complaining is still there, no?
>>>
>>> Maybe we should improve the documentation to point out that you
should
>>> not be using cookies to authenticate "private" JSONP/JS
endpoints? Perhaps
>>> we can make it easier to do token-based authentication for API
requests?
>>>
>>> Because personally I don''t see JSONP going away.
>>>
>>> Godfrey
>>>
>>>
>>> On Fri, Nov 29, 2013 at 2:55 AM, Egor Homakov
<hom...@gmail.com> wrote:
>>>
>>>> Focus on security concern. I repeat - any GET accessible
.js.erb IS a
>>>> vulnerability because leaks all data it has inside.
>>>> All "i use it because it''s fast/convenient"
means nothing if it''s a
>>>> vulnerable technique. IMO
>>>>
>>>>
>>>> On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov
wrote:
>>>>
>>>>>
https://github.com/rails/rails/issues/12374#issuecomment-29446761
>>>>>
>>>>> Here in discussion I proposed to deprecate JS responder
because this
>>>>> technique is insecure and not pragmatic way to transfer
data.
>>>>> It can be exploited in this way http://homakov.blogspot.co
>>>>> m/2013/05/do-not-use-rjs-like-techniques.html
>>>>>
>>>>> i find this bug very often so i know what i''m
talking about. With it
>>>>> attacker can steal user data and authenticity_token if
templates with form
>>>>> were leaked too.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>> 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/groups/opt_out.
>>>>
>>>
>>> --
>> 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.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
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+unsubscribe@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/groups/opt_out.
Since POSTs already require a csrf token, the rjs calls should do the same thing. Make them require the auth token in the url, or even better, have rails generate a hash of the auth token and the url and compare on the server. Thus you can''t call any rjs without using rails helpers to generate the correct url and matching token, and the new token would not be leaking the original csrf token via url or referer. It''s effectively using methods similar to how we build APIs with hmac signing of the request, but in a lightweight form and only in the background for RJS (or whatever else you want to protect, I suppose). This seems a little out of the scope of the core rails project, though? -- 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+unsubscribe@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/groups/opt_out.
Homakov, What Godfrey suggest may be implemented on the server side instead of client side without being hacked so easily? We may raise an exception by default when the host is not allowed, assuming that request.host is trustable. On Saturday, November 30, 2013 7:49:42 AM UTC-2, Courtenay Gasking wrote:> > Since POSTs already require a csrf token, the rjs calls should do the same > thing. Make them require the auth token in the url, or even better, have > rails generate a hash of the auth token and the url and compare on the > server. Thus you can''t call any rjs without using rails helpers to generate > the correct url and matching token, and the new token would not be leaking > the original csrf token via url or referer. It''s effectively using methods > similar to how we build APIs with hmac signing of the request, but in a > lightweight form and only in the background for RJS (or whatever else you > want to protect, I suppose). This seems a little out of the scope of the > core rails project, though? >-- 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+unsubscribe@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/groups/opt_out.
Not that would require to configure the application host manually like: Rails.application.config.host = ''example.com'' Rails.application.config.hosts = %w(example.com example.com.br) On Saturday, November 30, 2013 12:32:30 PM UTC-2, Gabriel Sobrinho wrote:> > Homakov, > > What Godfrey suggest may be implemented on the server side instead of > client side without being hacked so easily? > > We may raise an exception by default when the host is not allowed, > assuming that request.host is trustable. > > On Saturday, November 30, 2013 7:49:42 AM UTC-2, Courtenay Gasking wrote: >> >> Since POSTs already require a csrf token, the rjs calls should do the >> same thing. Make them require the auth token in the url, or even better, >> have rails generate a hash of the auth token and the url and compare on the >> server. Thus you can''t call any rjs without using rails helpers to generate >> the correct url and matching token, and the new token would not be leaking >> the original csrf token via url or referer. It''s effectively using methods >> similar to how we build APIs with hmac signing of the request, but in a >> lightweight form and only in the background for RJS (or whatever else you >> want to protect, I suppose). This seems a little out of the scope of the >> core rails project, though? >> >-- 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+unsubscribe@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/groups/opt_out.
Nevermind, it is not safe since the information about who is requesting is a header that can be changed. On Saturday, November 30, 2013 12:33:26 PM UTC-2, Gabriel Sobrinho wrote:> > Not that would require to configure the application host manually like: > > Rails.application.config.host = ''example.com'' > > Rails.application.config.hosts = %w(example.com example.com.br) > > > On Saturday, November 30, 2013 12:32:30 PM UTC-2, Gabriel Sobrinho wrote: >> >> Homakov, >> >> What Godfrey suggest may be implemented on the server side instead of >> client side without being hacked so easily? >> >> We may raise an exception by default when the host is not allowed, >> assuming that request.host is trustable. >> >> On Saturday, November 30, 2013 7:49:42 AM UTC-2, Courtenay Gasking wrote: >>> >>> Since POSTs already require a csrf token, the rjs calls should do the >>> same thing. Make them require the auth token in the url, or even better, >>> have rails generate a hash of the auth token and the url and compare on the >>> server. Thus you can''t call any rjs without using rails helpers to generate >>> the correct url and matching token, and the new token would not be leaking >>> the original csrf token via url or referer. It''s effectively using methods >>> similar to how we build APIs with hmac signing of the request, but in a >>> lightweight form and only in the background for RJS (or whatever else you >>> want to protect, I suppose). This seems a little out of the scope of the >>> core rails project, though? >>> >>-- 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+unsubscribe@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/groups/opt_out.
What about prefixing while(1) on the beginning of js responses with rack middleware, and then stripping them out client side? http://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses This is the solution used by Facebook and Google. http://blag.7tonlnu.pl/blog/2012/09/27/json-hijacking-in-rails/ -- 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+unsubscribe@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/groups/opt_out.
This might work out, but damnit, isn''t everyone agreed here that "returning JS" is 2008 style? Rails should move on, to API-like servers and single page apps, not necessarily breaking old school tools, but such a dinosaur should be considered as a bad & insecure practise. Why patch it then at all? On Sunday, December 1, 2013 2:19:09 AM UTC+7, Brian D. Armstrong wrote:> > What about prefixing while(1) on the beginning of js responses with rack > middleware, and then stripping them out client side? > > > http://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses > > This is the solution used by Facebook and Google. > > http://blag.7tonlnu.pl/blog/2012/09/27/json-hijacking-in-rails/ > >-- 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+unsubscribe@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/groups/opt_out.
http://homakov.blogspot.com/2013/11/rjs-leaking-vulnerability-in-multiple.html Related post On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
> > Rails should move on, to API-like servers and single page apps, not > necessarily breaking old school tools, but such a dinosaur should be > considered as a bad & insecure practise. Why patch it then at all?Single page apps are not everyone''s cup of tea. Maybe I am old school but I like to keep on the server side everything I can because I have more control there. On Sunday, December 1, 2013 5:27:21 AM UTC+1, Egor Homakov wrote:> > This might work out, but damnit, isn''t everyone agreed here that > "returning JS" is 2008 style? > > Rails should move on, to API-like servers and single page apps, not > necessarily breaking old school tools, but such a dinosaur should be > considered as a bad & insecure practise. Why patch it then at all? > > > On Sunday, December 1, 2013 2:19:09 AM UTC+7, Brian D. Armstrong wrote: >> >> What about prefixing while(1) on the beginning of js responses with rack >> middleware, and then stripping them out client side? >> >> >> http://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses >> >> This is the solution used by Facebook and Google. >> >> http://blag.7tonlnu.pl/blog/2012/09/27/json-hijacking-in-rails/ >> >>-- 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+unsubscribe@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/groups/opt_out.
Would a solution be to prevent rails apps from serving "non static" JS from GET requests. Assets served from the asset pipeline would be allowed. JS returned via controllers/views would need explicitly defined permission to be served via a GET request. On Sun, Dec 1, 2013 at 11:28 PM, Greg Molnar <molnargerg@gmail.com> wrote:> Rails should move on, to API-like servers and single page apps, not >> necessarily breaking old school tools, but such a dinosaur should be >> considered as a bad & insecure practise. Why patch it then at all? > > Single page apps are not everyone''s cup of tea. Maybe I am old school but > I like to keep on the server side everything I can because I have more > control there. > > On Sunday, December 1, 2013 5:27:21 AM UTC+1, Egor Homakov wrote: >> >> This might work out, but damnit, isn''t everyone agreed here that >> "returning JS" is 2008 style? >> >> Rails should move on, to API-like servers and single page apps, not >> necessarily breaking old school tools, but such a dinosaur should be >> considered as a bad & insecure practise. Why patch it then at all? >> >> >> On Sunday, December 1, 2013 2:19:09 AM UTC+7, Brian D. Armstrong wrote: >>> >>> What about prefixing while(1) on the beginning of js responses with rack >>> middleware, and then stripping them out client side? >>> >>> http://stackoverflow.com/questions/2669690/why-does- >>> google-prepend-while1-to-their-json-responses >>> >>> This is the solution used by Facebook and Google. >>> >>> http://blag.7tonlnu.pl/blog/2012/09/27/json-hijacking-in-rails/ >>> >>> -- > 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+unsubscribe@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/groups/opt_out. >-- 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+unsubscribe@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/groups/opt_out.
That''s still OK if it''s public data. (Obviously anything with a CSRF token in it isn''t.) It''d be nice if it was more explicit though, as the vulnerable cases are not obvious. On 2/12/2013, at 13:59 , Anthony Richardson <richo990@gmail.com> wrote:> Would a solution be to prevent rails apps from serving "non static" JS from GET requests. Assets served from the asset pipeline would be allowed. JS returned via controllers/views would need explicitly defined permission to be served via a GET request. > > > On Sun, Dec 1, 2013 at 11:28 PM, Greg Molnar <molnargerg@gmail.com> wrote: > Rails should move on, to API-like servers and single page apps, not necessarily breaking old school tools, but such a dinosaur should be considered as a bad & insecure practise. Why patch it then at all? > Single page apps are not everyone''s cup of tea. Maybe I am old school but I like to keep on the server side everything I can because I have more control there. > > On Sunday, December 1, 2013 5:27:21 AM UTC+1, Egor Homakov wrote: > This might work out, but damnit, isn''t everyone agreed here that "returning JS" is 2008 style? > > Rails should move on, to API-like servers and single page apps, not necessarily breaking old school tools, but such a dinosaur should be considered as a bad & insecure practise. Why patch it then at all? > > > On Sunday, December 1, 2013 2:19:09 AM UTC+7, Brian D. Armstrong wrote: > What about prefixing while(1) on the beginning of js responses with rack middleware, and then stripping them out client side? > http://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses > > This is the solution used by Facebook and Google. > > http://blag.7tonlnu.pl/blog/2012/09/27/json-hijacking-in-rails/ > > > > > -- > 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+unsubscribe@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/groups/opt_out. > > > -- > 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+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
On one hand if you explain/reach people with security concern of JS templates they will most likely rewrite it to JSON-style. On the other hand if they blindly update their rails/don''t read news - the only way to reach them is Deprecation warning. Or maybe just WARNING? What I actually want is to make people understand and check if they have this problem. Deprecation is on of the means to do it. On Monday, December 2, 2013 8:40:52 AM UTC+7, will.bryant wrote:> > That''s still OK if it''s public data. (Obviously anything with a CSRF > token in it isn''t.) > > It''d be nice if it was more explicit though, as the vulnerable cases are > not obvious. > > > On 2/12/2013, at 13:59 , Anthony Richardson <rich...@gmail.com<javascript:>> > wrote: > > Would a solution be to prevent rails apps from serving "non static" JS > from GET requests. Assets served from the asset pipeline would be allowed. > JS returned via controllers/views would need explicitly defined permission > to be served via a GET request. > > > On Sun, Dec 1, 2013 at 11:28 PM, Greg Molnar <molna...@gmail.com<javascript:> > > wrote: > >> Rails should move on, to API-like servers and single page apps, not >>> necessarily breaking old school tools, but such a dinosaur should be >>> considered as a bad & insecure practise. Why patch it then at all? >> >> Single page apps are not everyone''s cup of tea. Maybe I am old school but >> I like to keep on the server side everything I can because I have more >> control there. >> >> On Sunday, December 1, 2013 5:27:21 AM UTC+1, Egor Homakov wrote: >>> >>> This might work out, but damnit, isn''t everyone agreed here that >>> "returning JS" is 2008 style? >>> >>> Rails should move on, to API-like servers and single page apps, not >>> necessarily breaking old school tools, but such a dinosaur should be >>> considered as a bad & insecure practise. Why patch it then at all? >>> >>> >>> On Sunday, December 1, 2013 2:19:09 AM UTC+7, Brian D. Armstrong wrote: >>>> >>>> What about prefixing while(1) on the beginning of js responses with >>>> rack middleware, and then stripping them out client side? >>>> >>>> http://stackoverflow.com/questions/2669690/why-does- >>>> google-prepend-while1-to-their-json-responses >>>> >>>> This is the solution used by Facebook and Google. >>>> >>>> http://blag.7tonlnu.pl/blog/2012/09/27/json-hijacking-in-rails/ >>>> >>>> >>>> >> -- >> 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.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > -- > 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.com<javascript:> > . > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- 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+unsubscribe@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/groups/opt_out.
On 2 Dec 2013, at 03:42, Egor Homakov <homakov@gmail.com> wrote:> What I actually want is to make people understand and check if they have this problem. Deprecation is on of the means to do it.No, it isn''t. Deprecation means we intend to remove that feature in the next major release, which we don''t want to do. Single-page apps maybe the latest hotness but that doesn''t invalidate the previous two decades of web development. We didn''t remove forms when CSRF attacks were developed, we developed protections against them. This is exactly the same scenario - we need to develop useful, easy to use protections that we can enable by default. Egor, can you clarify one point for me - you mention that JS templates allow stealing of the CRSF token if they return a form, but surely that would true even for HTML templates? Andrew -- 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+unsubscribe@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/groups/opt_out.
The mechanics of the vulnerability, which Egor''s blog does not really communicate effectively, are, as I understand them: an evil site includes a <script> tag referencing a GETable .js.erb url from a good site. If the user is logged into the good site via cookies and has 3rd party cookies enabled, the request will succeed and return js possibly containing html with data indented to be private between the user and the good site. This js will execute in the js environment under the control of the evil site (it can override any function, method), handing the evil site the intended to be private html. This attack is not possible with non js content loaded by XHR or iframes, as the browser enforces cross-domain restrictions for both, and evil site will not be able to get at good site''s content. On Monday, December 2, 2013 3:41:07 AM UTC-5, Andy White wrote:> > > On 2 Dec 2013, at 03:42, Egor Homakov <hom...@gmail.com <javascript:>> > wrote: > > > What I actually want is to make people understand and check if they have > this problem. Deprecation is on of the means to do it. > > No, it isn''t. Deprecation means we intend to remove that feature in the > next major release, which we don''t want to do. Single-page apps maybe the > latest hotness but that doesn''t invalidate the previous two decades of web > development. We didn''t remove forms when CSRF attacks were developed, we > developed protections against them. This is exactly the same scenario - we > need to develop useful, easy to use protections that we can enable by > default. > > Egor, can you clarify one point for me - you mention that JS templates > allow stealing of the CRSF token if they return a form, but surely that > would true even for HTML templates? > > > Andrew > >-- 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+unsubscribe@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/groups/opt_out.
On 2 December 2013 09:09, Alex <alxtskrnk@gmail.com> wrote:> This attack is not possible with non js content loaded by XHR or iframes, > as the browser enforces cross-domain restrictions for both, and evil site > will not be able to get at good site''s content. >If the operators of EvilSite have gone to such lengths to contrive forms and overridden JS methods to potentially steal a tiny bit of possibly private HTML and data, could they not take the next small step and use a browser that *does not* enforce cross-domain restrictions on XHR? (or frankly, write their hacks with wget or curl) -- 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+unsubscribe@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/groups/opt_out.
> On 2 Dec 2013, at 09:32, Michael Pavling <pavling@gmail.com> wrote:> >> On 2 December 2013 09:09, Alex <alxtskrnk@gmail.com> wrote: >> This attack is not possible with non js content loaded by XHR or iframes, as the browser enforces cross-domain restrictions for both, and evil site will not be able to get at good site''s content. > > If the operators of EvilSite have gone to such lengths to contrive forms and overridden JS methods to potentially steal a tiny bit of possibly private HTML and data, could they not take the next small step and use a browser that *does not* enforce cross-domain restrictions on XHR? (or frankly, write their hacks with wget or curl)The idea is not that the evil site operators will access their own site themselves, but that they will get legitimate users of your site to visit their evil site (and thereby steal the legitimate users'' private data). So, for their ploy to be successful, it needs to work in standard browsers that ordinary users will be using. Chris -- 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+unsubscribe@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/groups/opt_out.
If the security concern is only about CSRF, what about not rendering CSRF token in templates at all? I mean, UJS may solve this problem appending the CRSF token from meta tag. If that’s not elegant since it will require javascript, even for static forms, we may do that only for .js.erb views. Basically, if a form is rendered through a js view, do not render the CSRF token. Homakov, that would fix the security concern without removing the .js.erb views? Cheers, Gabriel Sobrinho gabrielsobrinho.com On Dec 2, 2013, at 7:37 AM, Chris Mear <chrismear@gmail.com> wrote:>> On 2 Dec 2013, at 09:32, Michael Pavling <pavling@gmail.com> wrote: > > >> On 2 December 2013 09:09, Alex <alxtskrnk@gmail.com> wrote: >> This attack is not possible with non js content loaded by XHR or iframes, as the browser enforces cross-domain restrictions for both, and evil site will not be able to get at good site''s content. >> >> If the operators of EvilSite have gone to such lengths to contrive forms and overridden JS methods to potentially steal a tiny bit of possibly private HTML and data, could they not take the next small step and use a browser that *does not* enforce cross-domain restrictions on XHR? (or frankly, write their hacks with wget or curl) > > The idea is not that the evil site operators will access their own site themselves, but that they will get legitimate users of your site to visit their evil site (and thereby steal the legitimate users'' private data). So, for their ploy to be successful, it needs to work in standard browsers that ordinary users will be using. > > Chris > >> > > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
I''m afraid the CSRF token is not the only private data that could be sent in the template. I''m actually surprised so many applications seem to use RJS, including some applications I do use, like Redmine or GitLab. Maybe I should create the habit of using an anonymous session for regular browsing to avoid getting my private data stolen from applications using RJS in Rails... :( I really think RJS should be moved to a gem and not included by default in Rails and stop promoting its usage... Rodrigo. Em 02-12-2013 11:27, Gabriel Sobrinho escreveu:> If the security concern is only about CSRF, what about not rendering > CSRF token in templates at all? > > I mean, UJS may solve this problem appending the CRSF token from meta tag. > > > If that’s not elegant since it will require javascript, even for > static forms, we may do that only for .js.erb views. > > Basically, if a form is rendered through a js view, do not render the > CSRF token. > > > Homakov, that would fix the security concern without removing the > .js.erb views? > > Cheers, > > Gabriel Sobrinho > gabrielsobrinho.com <http://gabrielsobrinho.com> > > On Dec 2, 2013, at 7:37 AM, Chris Mear <chrismear@gmail.com > <mailto:chrismear@gmail.com>> wrote: > >>> On 2 Dec 2013, at 09:32, Michael Pavling <pavling@gmail.com >>> <mailto:pavling@gmail.com>> wrote: >> >>> On 2 December 2013 09:09, Alex <alxtskrnk@gmail.com >>> <mailto:alxtskrnk@gmail.com>> wrote: >>> >>> This attack is not possible with non js content loaded by XHR or >>> iframes, as the browser enforces cross-domain restrictions for >>> both, and evil site will not be able to get at good site''s content. >>> >>> >>> If the operators of EvilSite have gone to such lengths to contrive >>> forms and overridden JS methods to potentially steal a tiny bit of >>> possibly private HTML and data, could they not take the next small >>> step and use a browser that *does not* enforce cross-domain >>> restrictions on XHR? (or frankly, write their hacks with wget or curl) >> >> The idea is not that the evil site operators will access their own >> site themselves, but that they will get legitimate users of your site >> to visit their evil site (and thereby steal the legitimate users'' >> private data). So, for their ploy to be successful, it needs to work >> in standard browsers that ordinary users will be using. >> >> Chris >> >>> >> >> -- >> 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/rwzM8MKJbKU/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> rubyonrails-core+unsubscribe@googlegroups.com >> <mailto:rubyonrails-core+unsubscribe@googlegroups.com>. >> To post to this group, send email to >> rubyonrails-core@googlegroups.com >> <mailto:rubyonrails-core@googlegroups.com>. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. > > -- > 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+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
> The mechanics of the vulnerability, which Egor''s blog does not reallycommunicate effectively what''s not effective in my post? As I said attack works as JSONP hijacking. So everything is totally obvious, isn''t it. On Monday, December 2, 2013 4:09:02 PM UTC+7, Alex wrote:> > The mechanics of the vulnerability, which Egor''s blog does not really > communicate effectively, are, as I understand them: > > an evil site includes a <script> tag referencing a GETable .js.erb url > from a good site. If the user is logged into the good site via cookies and > has 3rd party cookies enabled, the request will succeed and return js > possibly containing html with data indented to be private between the user > and the good site. This js will execute in the js environment under the > control of the evil site (it can override any function, method), handing > the evil site the intended to be private html. > > This attack is not possible with non js content loaded by XHR or iframes, > as the browser enforces cross-domain restrictions for both, and evil site > will not be able to get at good site''s content. > > On Monday, December 2, 2013 3:41:07 AM UTC-5, Andy White wrote: >> >> >> On 2 Dec 2013, at 03:42, Egor Homakov <hom...@gmail.com> wrote: >> >> > What I actually want is to make people understand and check if they >> have this problem. Deprecation is on of the means to do it. >> >> No, it isn''t. Deprecation means we intend to remove that feature in the >> next major release, which we don''t want to do. Single-page apps maybe the >> latest hotness but that doesn''t invalidate the previous two decades of web >> development. We didn''t remove forms when CSRF attacks were developed, we >> developed protections against them. This is exactly the same scenario - we >> need to develop useful, easy to use protections that we can enable by >> default. >> >> Egor, can you clarify one point for me - you mention that JS templates >> allow stealing of the CRSF token if they return a form, but surely that >> would true even for HTML templates? >> >> >> Andrew >> >>-- 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+unsubscribe@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/groups/opt_out.
Apparently many readers have no clue how this attack works, and people keep asking the same questions. Thanks to people who clarified it in more details than i did. All we can do is to add is-.xhr? protection or Warning (not necessarily Deprecation). There are no other sane way to mitigate it. On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
I see, extracting it as a gem fix the problem, at least for the rails itself, which is what we want. The extracted gem must explicitly explain the security concerns on the top of README, regardless of people usually don’t read it. Rails already did that for other features, for other reasons but the same idea applies, deprecate the usage on rails itself but allow who explicitly wants/needs to use. Time to pull request? Cheers, Gabriel Sobrinho gabrielsobrinho.com On Dec 2, 2013, at 12:19 PM, Egor Homakov <homakov@gmail.com> wrote:> Apparently many readers have no clue how this attack works, and people keep asking the same questions. Thanks to people who clarified it in more details than i did. > > All we can do is to add is-.xhr? protection or Warning (not necessarily Deprecation). There are no other sane way to mitigate it. > > > > On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it attacker can steal user data and authenticity_token if templates with form were leaked too. > > > > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
I think we should rather try to find a way to make this secure. What would be a sane default? Only respond to js format is the request is xhr? To be honest I read Egor''s post but still not sure how this exploit would work. I will look at his examples when I got some free time and hopefully that will help to understand it more. On Monday, December 2, 2013 3:52:53 PM UTC+1, Gabriel Sobrinho wrote:> > I see, extracting it as a gem fix the problem, at least for the rails > itself, which is what we want. > > The extracted gem must explicitly explain the security concerns on the top > of README, regardless of people usually don’t read it. > > > Rails already did that for other features, for other reasons but the same > idea applies, deprecate the usage on rails itself but allow who explicitly > wants/needs to use. > > Time to pull request? > > Cheers, > > Gabriel Sobrinho > gabrielsobrinho.com > > On Dec 2, 2013, at 12:19 PM, Egor Homakov <hom...@gmail.com <javascript:>> > wrote: > > Apparently many readers have no clue how this attack works, and people > keep asking the same questions. Thanks to people who clarified it in more > details than i did. > > All we can do is to add is-.xhr? protection or Warning (not necessarily > Deprecation). There are no other sane way to mitigate it. > > > > On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >> >> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> >> Here in discussion I proposed to deprecate JS responder because this >> technique is insecure and not pragmatic way to transfer data. >> It can be exploited in this way >> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> >> i find this bug very often so i know what i''m talking about. With it >> attacker can steal user data and authenticity_token if templates with form >> were leaked too. >> >> >> >> > -- > 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/rwzM8MKJbKU/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/groups/opt_out. > > >-- 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+unsubscribe@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/groups/opt_out.
I believe the reason why it''s hard for us to understand how the exploit works is because it''s pretty hard to find the documentation for RJS itself and specially how it works... I''m assuming, it works like JSONP, since Egor must know what he is talking about. In this case, it won''t require a XHR request and won''t send any nonce (like the XSRF token) for GET requests, and will work with a regular inline script tag. In that case, the trick of prepending a "while(1)" would probably fix this particular issue because it wouldn''t allow the code to be evaluated, no matter whether you have changed the JS global context or not. Another way of fixing it if I understood correctly would be to require all RJS requests to happen with XHR since they are subject to same-origin browser''s policy. Yet another way to fix it would be to always require a nonce even for GET requests to XHR templates requests. Am I missing something? Best, Rodrigo. Em 02-12-2013 12:57, Greg Molnar escreveu:> I think we should rather try to find a way to make this secure. What > would be a sane default? Only respond to js format is the request is xhr? > To be honest I read Egor''s post but still not sure how this exploit > would work. I will look at his examples when I got some free time and > hopefully that will help to understand it more.-- 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+unsubscribe@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/groups/opt_out.
-1 for while(true). Let''s consider all use cases 1) JS templates are used with AJAX, thus the X-Requested_with header is sent and .xhr? is enough protection 2) JS templates are also used with inline <script> tags. Thus while(true) will both break on origin website and on attacker''s website. Not an option 3) Since we can send additional header why bother with prepending while(true); So .xhr? is most elegant way that covers most of attack vectors. I really don''t understand why JSON-hijacking wasn''t solved the same way. while(true) is uglyish On Monday, December 2, 2013 10:24:30 PM UTC+7, Rodrigo Rosenfeld Rosas wrote:> > I believe the reason why it''s hard for us to understand how the exploit > works is because it''s pretty hard to find the documentation for RJS > itself and specially how it works... > > I''m assuming, it works like JSONP, since Egor must know what he is > talking about. > > In this case, it won''t require a XHR request and won''t send any nonce > (like the XSRF token) for GET requests, and will work with a regular > inline script tag. > > In that case, the trick of prepending a "while(1)" would probably fix > this particular issue because it wouldn''t allow the code to be > evaluated, no matter whether you have changed the JS global context or > not. > > Another way of fixing it if I understood correctly would be to require > all RJS requests to happen with XHR since they are subject to > same-origin browser''s policy. > > Yet another way to fix it would be to always require a nonce even for > GET requests to XHR templates requests. > > Am I missing something? > > Best, > Rodrigo. > > Em 02-12-2013 12:57, Greg Molnar escreveu: > > I think we should rather try to find a way to make this secure. What > > would be a sane default? Only respond to js format is the request is > xhr? > > To be honest I read Egor''s post but still not sure how this exploit > > would work. I will look at his examples when I got some free time and > > hopefully that will help to understand it more. > >-- 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+unsubscribe@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/groups/opt_out.
Yes, it makes sense, because you''re forced to use XHR anyway when you include a "while(1);" otherwise you won''t be able to strip it out. Maybe the reason was to protect against old browsers that didn''t implement proper same-origin policy? Em 02-12-2013 13:30, Egor Homakov escreveu:> -1 for while(true). Let''s consider all use cases > > 1) JS templates are used with AJAX, thus the X-Requested_with header > is sent and .xhr? is enough protection > 2) JS templates are also used with inline <script> tags. Thus > while(true) will both break on origin website and on attacker''s > website. Not an option > 3) Since we can send additional header why bother with prepending > while(true); > So .xhr? is most elegant way that covers most of attack vectors. > I really don''t understand why JSON-hijacking wasn''t solved the same > way. while(true) is uglyish > > On Monday, December 2, 2013 10:24:30 PM UTC+7, Rodrigo Rosenfeld Rosas > wrote: > > I believe the reason why it''s hard for us to understand how the > exploit > works is because it''s pretty hard to find the documentation for RJS > itself and specially how it works... > > I''m assuming, it works like JSONP, since Egor must know what he is > talking about. > > In this case, it won''t require a XHR request and won''t send any nonce > (like the XSRF token) for GET requests, and will work with a regular > inline script tag. > > In that case, the trick of prepending a "while(1)" would probably fix > this particular issue because it wouldn''t allow the code to be > evaluated, no matter whether you have changed the JS global > context or not. > > Another way of fixing it if I understood correctly would be to > require > all RJS requests to happen with XHR since they are subject to > same-origin browser''s policy. > > Yet another way to fix it would be to always require a nonce even for > GET requests to XHR templates requests. > > Am I missing something? > > Best, > Rodrigo. > > Em 02-12-2013 12:57, Greg Molnar escreveu: > > I think we should rather try to find a way to make this secure. > What > > would be a sane default? Only respond to js format is the > request is xhr? > > To be honest I read Egor''s post but still not sure how this exploit > > would work. I will look at his examples when I got some free > time and > > hopefully that will help to understand it more. > > -- > 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+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
What do you mean? Hijacking issue was just same, browsers were same, and I recall XHR could add additional headers.. so while(1) sounds like weird idea On Monday, December 2, 2013 10:35:16 PM UTC+7, Rodrigo Rosenfeld Rosas wrote:> > Yes, it makes sense, because you''re forced to use XHR anyway when you > include a "while(1);" otherwise you won''t be able to strip it out. > > Maybe the reason was to protect against old browsers that didn''t implement > proper same-origin policy? > > Em 02-12-2013 13:30, Egor Homakov escreveu: > > -1 for while(true). Let''s consider all use cases > > 1) JS templates are used with AJAX, thus the X-Requested_with header is > sent and .xhr? is enough protection > 2) JS templates are also used with inline <script> tags. Thus while(true) > will both break on origin website and on attacker''s website. Not an option > 3) Since we can send additional header why bother with prepending > while(true); > So .xhr? is most elegant way that covers most of attack vectors. > I really don''t understand why JSON-hijacking wasn''t solved the same way. > while(true) is uglyish > > On Monday, December 2, 2013 10:24:30 PM UTC+7, Rodrigo Rosenfeld Rosas > wrote: >> >> I believe the reason why it''s hard for us to understand how the exploit >> works is because it''s pretty hard to find the documentation for RJS >> itself and specially how it works... >> >> I''m assuming, it works like JSONP, since Egor must know what he is >> talking about. >> >> In this case, it won''t require a XHR request and won''t send any nonce >> (like the XSRF token) for GET requests, and will work with a regular >> inline script tag. >> >> In that case, the trick of prepending a "while(1)" would probably fix >> this particular issue because it wouldn''t allow the code to be >> evaluated, no matter whether you have changed the JS global context or >> not. >> >> Another way of fixing it if I understood correctly would be to require >> all RJS requests to happen with XHR since they are subject to >> same-origin browser''s policy. >> >> Yet another way to fix it would be to always require a nonce even for >> GET requests to XHR templates requests. >> >> Am I missing something? >> >> Best, >> Rodrigo. >> >> Em 02-12-2013 12:57, Greg Molnar escreveu: >> > I think we should rather try to find a way to make this secure. What >> > would be a sane default? Only respond to js format is the request is >> xhr? >> > To be honest I read Egor''s post but still not sure how this exploit >> > would work. I will look at his examples when I got some free time and >> > hopefully that will help to understand it more. >> >> -- > 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.com<javascript:> > . > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- 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+unsubscribe@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/groups/opt_out.
So you say Egor if rails would raise an error when the request for a js format is not xhr? it would solve the security issue? On Monday, December 2, 2013 4:41:58 PM UTC+1, Egor Homakov wrote:> > What do you mean? Hijacking issue was just same, browsers were same, and I > recall XHR could add additional headers.. so while(1) sounds like weird > idea > > On Monday, December 2, 2013 10:35:16 PM UTC+7, Rodrigo Rosenfeld Rosas > wrote: >> >> Yes, it makes sense, because you''re forced to use XHR anyway when you >> include a "while(1);" otherwise you won''t be able to strip it out. >> >> Maybe the reason was to protect against old browsers that didn''t >> implement proper same-origin policy? >> >> Em 02-12-2013 13:30, Egor Homakov escreveu: >> >> -1 for while(true). Let''s consider all use cases >> >> 1) JS templates are used with AJAX, thus the X-Requested_with header is >> sent and .xhr? is enough protection >> 2) JS templates are also used with inline <script> tags. Thus while(true) >> will both break on origin website and on attacker''s website. Not an option >> 3) Since we can send additional header why bother with prepending >> while(true); >> So .xhr? is most elegant way that covers most of attack vectors. >> I really don''t understand why JSON-hijacking wasn''t solved the same way. >> while(true) is uglyish >> >> On Monday, December 2, 2013 10:24:30 PM UTC+7, Rodrigo Rosenfeld Rosas >> wrote: >>> >>> I believe the reason why it''s hard for us to understand how the exploit >>> works is because it''s pretty hard to find the documentation for RJS >>> itself and specially how it works... >>> >>> I''m assuming, it works like JSONP, since Egor must know what he is >>> talking about. >>> >>> In this case, it won''t require a XHR request and won''t send any nonce >>> (like the XSRF token) for GET requests, and will work with a regular >>> inline script tag. >>> >>> In that case, the trick of prepending a "while(1)" would probably fix >>> this particular issue because it wouldn''t allow the code to be >>> evaluated, no matter whether you have changed the JS global context or >>> not. >>> >>> Another way of fixing it if I understood correctly would be to require >>> all RJS requests to happen with XHR since they are subject to >>> same-origin browser''s policy. >>> >>> Yet another way to fix it would be to always require a nonce even for >>> GET requests to XHR templates requests. >>> >>> Am I missing something? >>> >>> Best, >>> Rodrigo. >>> >>> Em 02-12-2013 12:57, Greg Molnar escreveu: >>> > I think we should rather try to find a way to make this secure. What >>> > would be a sane default? Only respond to js format is the request is >>> xhr? >>> > To be honest I read Egor''s post but still not sure how this exploit >>> > would work. I will look at his examples when I got some free time and >>> > hopefully that will help to understand it more. >>> >>> -- >> 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/groups/opt_out. >> >> >>-- 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+unsubscribe@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/groups/opt_out.
Please stop conflating the discovery of a security issue with the philosophical waxing about architecture. It''s not helping the case. As stated previously, responding with JS is not only a wonderful architectural pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, not anywhere. We''ll fix the security issue, and Rails will continue to proudly champion the use of this great pattern. Guess what, it won''t be the last security issue Rails ever has. Just like it won''t be the last security issue any piece of software ever has. But we need to level up as a community in our handling of these issues. Frankly, I''m surprised that people are willing to hire Homakov for any work in the area given his reputation for irresponsible disclosure. Finding a legit security issues is a great services, but disregarding all security issue management protocols in their publication is doing a disservice to all who would otherwise benefit from the work. Rails has had a codified security process for many years now. It''s available for all to read on http://rubyonrails.org/security. Making a blog post on your personal site isn''t one of the channels listed as a responsible way of disclosing discoveries. Posting specific 0-day attack vectors against affected sites is not one either. Making a public report over a holiday weekend, and then, when the response to the report doesn''t immediately follow the proposed solution (remove the feature), go off the reservation with specific attacks is just plain irresponsible. No two ways about it. It also goes to undermine any other recommendations or suggestions coming from said reporter. So. Damage is already done for this issue. But lest it encourages others to act as irresponsibly as Homakov has done of this issue, I hope others take a broader approach for future issues. Report systemic or framework issues per the reporting instructions on http://rubyonrails.org/security. Report specific application issues directly to application developers responsibly per their reporting instructions (see https://37signals.com/security-response for the one we use at 37signals). Presumably we''re all in the same boat here: Make Rails better and more secure. Let''s row like we mean that. The Rails security team (Michael Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past to provide us with a good process, they''ve followed that process, and they deserve our thanks and 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-core+unsubscribe@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/groups/opt_out.
David, first I must say I admire both you and Homakov and I''d certainly hire him if I could afford it. I believe what led him to create that post was exactly your reponse to his e-mail. I agree he shouldn''t have created this discussion publicly but you shouldn''t have replied the way you did either. You should instead try to understand the problem first before saying it would go nowhere. I believe this is what caused Homakov reaction. Sincerely, Rodrigo. Em 02-12-2013 13:47, DHH escreveu:> Please stop conflating the discovery of a security issue with the > philosophical waxing about architecture. It''s not helping the case. As > stated previously, responding with JS is not only a wonderful > architectural pattern, it''s also not going anywhere. Not in a gem, not > in a deprecation, not anywhere. We''ll fix the security issue, and > Rails will continue to proudly champion the use of this great pattern. > > Guess what, it won''t be the last security issue Rails ever has. Just > like it won''t be the last security issue any piece of software ever > has. But we need to level up as a community in our handling of these > issues. > > Frankly, I''m surprised that people are willing to hire Homakov for any > work in the area given his reputation for irresponsible disclosure. > Finding a legit security issues is a great services, but disregarding > all security issue management protocols in their publication is doing > a disservice to all who would otherwise benefit from the work. > > Rails has had a codified security process for many years now. It''s > available for all to read on http://rubyonrails.org/security. Making a > blog post on your personal site isn''t one of the channels listed as a > responsible way of disclosing discoveries. Posting specific 0-day > attack vectors against affected sites is not one either. > > Making a public report over a holiday weekend, and then, when the > response to the report doesn''t immediately follow the proposed > solution (remove the feature), go off the reservation with specific > attacks is just plain irresponsible. No two ways about it. It also > goes to undermine any other recommendations or suggestions coming from > said reporter. > > So. Damage is already done for this issue. But lest it encourages > others to act as irresponsibly as Homakov has done of this issue, I > hope others take a broader approach for future issues. Report systemic > or framework issues per the reporting instructions > on http://rubyonrails.org/security. Report specific application issues > directly to application developers responsibly per their reporting > instructions (see https://37signals.com/security-response for the one > we use at 37signals). > > Presumably we''re all in the same boat here: Make Rails better and more > secure. Let''s row like we mean that. The Rails security team (Michael > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the > past to provide us with a good process, they''ve followed that process, > and they deserve our thanks and 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-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
Rodrigo, many great things around the word can be dangerous if used in the wrong way but there are great people who try to make the usage of tools secure so humanity can profit from them. I am not the fun of don''t use this or that because it can be dangerous. Let''s find a way to make it secure. That''s harder but better in the long run I think. On Monday, December 2, 2013 4:52:04 PM UTC+1, Rodrigo Rosenfeld Rosas wrote:> > David, first I must say I admire both you and Homakov and I''d certainly > hire him if I could afford it. > > I believe what led him to create that post was exactly your reponse to > his e-mail. > > I agree he shouldn''t have created this discussion publicly but you > shouldn''t have replied the way you did either. You should instead try to > understand the problem first before saying it would go nowhere. > > I believe this is what caused Homakov reaction. > > Sincerely, > Rodrigo. > > Em 02-12-2013 13:47, DHH escreveu: > > Please stop conflating the discovery of a security issue with the > > philosophical waxing about architecture. It''s not helping the case. As > > stated previously, responding with JS is not only a wonderful > > architectural pattern, it''s also not going anywhere. Not in a gem, not > > in a deprecation, not anywhere. We''ll fix the security issue, and > > Rails will continue to proudly champion the use of this great pattern. > > > > Guess what, it won''t be the last security issue Rails ever has. Just > > like it won''t be the last security issue any piece of software ever > > has. But we need to level up as a community in our handling of these > > issues. > > > > Frankly, I''m surprised that people are willing to hire Homakov for any > > work in the area given his reputation for irresponsible disclosure. > > Finding a legit security issues is a great services, but disregarding > > all security issue management protocols in their publication is doing > > a disservice to all who would otherwise benefit from the work. > > > > Rails has had a codified security process for many years now. It''s > > available for all to read on http://rubyonrails.org/security. Making a > > blog post on your personal site isn''t one of the channels listed as a > > responsible way of disclosing discoveries. Posting specific 0-day > > attack vectors against affected sites is not one either. > > > > Making a public report over a holiday weekend, and then, when the > > response to the report doesn''t immediately follow the proposed > > solution (remove the feature), go off the reservation with specific > > attacks is just plain irresponsible. No two ways about it. It also > > goes to undermine any other recommendations or suggestions coming from > > said reporter. > > > > So. Damage is already done for this issue. But lest it encourages > > others to act as irresponsibly as Homakov has done of this issue, I > > hope others take a broader approach for future issues. Report systemic > > or framework issues per the reporting instructions > > on http://rubyonrails.org/security. Report specific application issues > > directly to application developers responsibly per their reporting > > instructions (see https://37signals.com/security-response for the one > > we use at 37signals). > > > > Presumably we''re all in the same boat here: Make Rails better and more > > secure. Let''s row like we mean that. The Rails security team (Michael > > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the > > past to provide us with a good process, they''ve followed that process, > > and they deserve our thanks and 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 <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/groups/opt_out. > >-- 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+unsubscribe@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/groups/opt_out.
What email is that? I replied to Homakov on Twitter thanking him for the discovery and stating a clear intent to get the issue resolved. What I rejected outright was the knee-jerk reaction to remove the possibility of generating JS responses from Rails. This rejection was confirmed when it got clear that the motivation behind that specific mitigation strategy was also motivated by architectural opinions on what''s dinosaur and what''s not. But again, even having this discussion here or on Twitter simply isn''t the proper forum to discuss 0-day exploits. It''s the reason we have a standardized security reporting and response protocol. It''s why we go to great lengths to coordinate proper fixes across multiple versions of Rails, following the CVE process, and other responsible steps in the process. To sidestep all that doesn''t help anyone but Homakov in the short-term to build a reputation as a take-no-prisoners grey hatter. I question the business strategy of that long-term (imagine having a business dispute with Homakov after giving him access to your system -- yikes!). Again, my opinion of the process is removed from the value of finding security holes. Of course finding and responsibly disclosing security holes is a good thing. I just wish that Homakov, and others who might be inspired by his tactics, would realize that there''s plenty of gain to be had personally by subscribing to these time-tested practices. On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:> David, first I must say I admire both you and Homakov and I''d certainly hire him if I could afford it. > > I believe what led him to create that post was exactly your reponse to his e-mail. > > I agree he shouldn''t have created this discussion publicly but you shouldn''t have replied the way you did either. You should instead try to understand the problem first before saying it would go nowhere. > > I believe this is what caused Homakov reaction. > > Sincerely, > Rodrigo. > > Em 02-12-2013 13:47, DHH escreveu: >> Please stop conflating the discovery of a security issue with the philosophical waxing about architecture. It''s not helping the case. As stated previously, responding with JS is not only a wonderful architectural pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, not anywhere. We''ll fix the security issue, and Rails will continue to proudly champion the use of this great pattern. >> >> Guess what, it won''t be the last security issue Rails ever has. Just like it won''t be the last security issue any piece of software ever has. But we need to level up as a community in our handling of these issues. >> >> Frankly, I''m surprised that people are willing to hire Homakov for any work in the area given his reputation for irresponsible disclosure. Finding a legit security issues is a great services, but disregarding all security issue management protocols in their publication is doing a disservice to all who would otherwise benefit from the work. >> >> Rails has had a codified security process for many years now. It''s available for all to read on http://rubyonrails.org/security. Making a blog post on your personal site isn''t one of the channels listed as a responsible way of disclosing discoveries. Posting specific 0-day attack vectors against affected sites is not one either. >> >> Making a public report over a holiday weekend, and then, when the response to the report doesn''t immediately follow the proposed solution (remove the feature), go off the reservation with specific attacks is just plain irresponsible. No two ways about it. It also goes to undermine any other recommendations or suggestions coming from said reporter. >> >> So. Damage is already done for this issue. But lest it encourages others to act as irresponsibly as Homakov has done of this issue, I hope others take a broader approach for future issues. Report systemic or framework issues per the reporting instructions on http://rubyonrails.org/security. Report specific application issues directly to application developers responsibly per their reporting instructions (see https://37signals.com/security-response for the one we use at 37signals). >> >> Presumably we''re all in the same boat here: Make Rails better and more secure. Let''s row like we mean that. The Rails security team (Michael Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past to provide us with a good process, they''ve followed that process, and they deserve our thanks and 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-core+unsubscribe@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/groups/opt_out. > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
As many have already mentioned, enforcing request.xhr? for js requests provides adequate protection. You can''t set custom headers when making a cross-domain request with a <script> tag so checking for one ensures the request is local. That''s what request.xhr? does. Here''s the solution we''re using: https://gist.github.com/javan/7725255 I could see wrapping that up into something convenient like protect_from_forgery and making it a default in Rails. -Javan 37signals On Thursday, November 28, 2013 3:41:37 AM UTC-5, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
Your first message in this thread. He even quoted the relevant part in his article: "Not only are js.erb templates not deprecated, they are a great way to develop an application with Ajax responses where you can reuse your server-side templates. It''s fine to explore ways to make this more secure by default, but the fundamental development style of returning JS as a response is both architecturally sound and an integral part of Rails. So that''s not going anywhere. So let''s instead explore ways of having better escaping tools, warnings, or defaults that''ll work with the wonders of RJS." I understand you had the best of the intentions, but I wouldn''t have started the discussion by ending it. By this time you were not yet aware on how applications were affected and if there was a sane way to fix this issue. If I were you, I''d first *ask* if there''s an alternative way instead of deprecating its usage *before* deciding it wouldn''t go anywhere. I guess that was what pissed him off... I agree with you that this is not the "correct" way of dealing with the situation, from an ethics perspective, but let''s be honest: Homakov wouldn''t probably be a known name if he hadn''t put the attack to GitHub into practice. I''m not defending this approach to self marketing, but you can''t tell us it isn''t effective ;) Best, Rodrigo. Em 02-12-2013 14:01, David Heinemeier Hansson escreveu:> What email is that? I replied to Homakov on Twitter thanking him for the discovery and stating a clear intent to get the issue resolved. What I rejected outright was the knee-jerk reaction to remove the possibility of generating JS responses from Rails. This rejection was confirmed when it got clear that the motivation behind that specific mitigation strategy was also motivated by architectural opinions on what''s dinosaur and what''s not. > > But again, even having this discussion here or on Twitter simply isn''t the proper forum to discuss 0-day exploits. It''s the reason we have a standardized security reporting and response protocol. It''s why we go to great lengths to coordinate proper fixes across multiple versions of Rails, following the CVE process, and other responsible steps in the process. > > To sidestep all that doesn''t help anyone but Homakov in the short-term to build a reputation as a take-no-prisoners grey hatter. I question the business strategy of that long-term (imagine having a business dispute with Homakov after giving him access to your system -- yikes!). > > Again, my opinion of the process is removed from the value of finding security holes. Of course finding and responsibly disclosing security holes is a good thing. I just wish that Homakov, and others who might be inspired by his tactics, would realize that there''s plenty of gain to be had personally by subscribing to these time-tested practices. > > > On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote: > >> David, first I must say I admire both you and Homakov and I''d certainly hire him if I could afford it. >> >> I believe what led him to create that post was exactly your reponse to his e-mail. >> >> I agree he shouldn''t have created this discussion publicly but you shouldn''t have replied the way you did either. You should instead try to understand the problem first before saying it would go nowhere. >> >> I believe this is what caused Homakov reaction. >> >> Sincerely, >> Rodrigo. >> >> Em 02-12-2013 13:47, DHH escreveu: >>> Please stop conflating the discovery of a security issue with the philosophical waxing about architecture. It''s not helping the case. As stated previously, responding with JS is not only a wonderful architectural pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, not anywhere. We''ll fix the security issue, and Rails will continue to proudly champion the use of this great pattern. >>> >>> Guess what, it won''t be the last security issue Rails ever has. Just like it won''t be the last security issue any piece of software ever has. But we need to level up as a community in our handling of these issues. >>> >>> Frankly, I''m surprised that people are willing to hire Homakov for any work in the area given his reputation for irresponsible disclosure. Finding a legit security issues is a great services, but disregarding all security issue management protocols in their publication is doing a disservice to all who would otherwise benefit from the work. >>> >>> Rails has had a codified security process for many years now. It''s available for all to read on http://rubyonrails.org/security. Making a blog post on your personal site isn''t one of the channels listed as a responsible way of disclosing discoveries. Posting specific 0-day attack vectors against affected sites is not one either. >>> >>> Making a public report over a holiday weekend, and then, when the response to the report doesn''t immediately follow the proposed solution (remove the feature), go off the reservation with specific attacks is just plain irresponsible. No two ways about it. It also goes to undermine any other recommendations or suggestions coming from said reporter. >>> >>> So. Damage is already done for this issue. But lest it encourages others to act as irresponsibly as Homakov has done of this issue, I hope others take a broader approach for future issues. Report systemic or framework issues per the reporting instructions on http://rubyonrails.org/security. Report specific application issues directly to application developers responsibly per their reporting instructions (see https://37signals.com/security-response for the one we use at 37signals). >>> >>> Presumably we''re all in the same boat here: Make Rails better and more secure. Let''s row like we mean that. The Rails security team (Michael Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past to provide us with a good process, they''ve followed that process, and they deserve our thanks and 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-core+unsubscribe@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/groups/opt_out. >> -- >> 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/rwzM8MKJbKU/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
This fix seems great. Homakov, what do you think? May fix the problem? Cheers, Gabriel Sobrinho gabrielsobrinho.com On Dec 2, 2013, at 2:09 PM, Javan Makhmali <javanm@gmail.com> wrote:> As many have already mentioned, enforcing request.xhr? for js requests provides adequate protection. You can''t set custom headers when making a cross-domain request with a <script> tag so checking for one ensures the request is local. That''s what request.xhr? does. > > Here''s the solution we''re using: https://gist.github.com/javan/7725255 > > I could see wrapping that up into something convenient like protect_from_forgery and making it a default in Rails. > > -Javan > 37signals > > On Thursday, November 28, 2013 3:41:37 AM UTC-5, Egor Homakov wrote: > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it attacker can steal user data and authenticity_token if templates with form were leaked too. > > > > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
There''s a precise reason why I did so called "full disclosure" I started writing an email to security@37singals, then i checked out the previous conversation we had, where i was asked about my link for Hall of Fame. I gave the link and after a month it wasn''t added. No, i don''t really care, but given some other details (it was the second RJS bug in basecamp, "RJS bug" overall wasn''t 0 day at all, your ultimate rejection of RJS removal) i somehow ended up writing a post with full disclosure. I *mostly* follow responsible disclosure policies. But this is not my duty. Especially when i have couple of reasons to follow other policy. On Monday, December 2, 2013 11:01:21 PM UTC+7, DHH wrote:> > What email is that? I replied to Homakov on Twitter thanking him for the > discovery and stating a clear intent to get the issue resolved. What I > rejected outright was the knee-jerk reaction to remove the possibility of > generating JS responses from Rails. This rejection was confirmed when it > got clear that the motivation behind that specific mitigation strategy was > also motivated by architectural opinions on what''s dinosaur and what''s not. > > But again, even having this discussion here or on Twitter simply isn''t the > proper forum to discuss 0-day exploits. It''s the reason we have a > standardized security reporting and response protocol. It''s why we go to > great lengths to coordinate proper fixes across multiple versions of Rails, > following the CVE process, and other responsible steps in the process. > > To sidestep all that doesn''t help anyone but Homakov in the short-term to > build a reputation as a take-no-prisoners grey hatter. I question the > business strategy of that long-term (imagine having a business dispute with > Homakov after giving him access to your system -- yikes!). > > Again, my opinion of the process is removed from the value of finding > security holes. Of course finding and responsibly disclosing security holes > is a good thing. I just wish that Homakov, and others who might be inspired > by his tactics, would realize that there''s plenty of gain to be had > personally by subscribing to these time-tested practices. > > > On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com<javascript:>> > wrote: > > > David, first I must say I admire both you and Homakov and I''d certainly > hire him if I could afford it. > > > > I believe what led him to create that post was exactly your reponse to > his e-mail. > > > > I agree he shouldn''t have created this discussion publicly but you > shouldn''t have replied the way you did either. You should instead try to > understand the problem first before saying it would go nowhere. > > > > I believe this is what caused Homakov reaction. > > > > Sincerely, > > Rodrigo. > > > > Em 02-12-2013 13:47, DHH escreveu: > >> Please stop conflating the discovery of a security issue with the > philosophical waxing about architecture. It''s not helping the case. As > stated previously, responding with JS is not only a wonderful architectural > pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, > not anywhere. We''ll fix the security issue, and Rails will continue to > proudly champion the use of this great pattern. > >> > >> Guess what, it won''t be the last security issue Rails ever has. Just > like it won''t be the last security issue any piece of software ever has. > But we need to level up as a community in our handling of these issues. > >> > >> Frankly, I''m surprised that people are willing to hire Homakov for any > work in the area given his reputation for irresponsible disclosure. Finding > a legit security issues is a great services, but disregarding all security > issue management protocols in their publication is doing a disservice to > all who would otherwise benefit from the work. > >> > >> Rails has had a codified security process for many years now. It''s > available for all to read on http://rubyonrails.org/security. Making a > blog post on your personal site isn''t one of the channels listed as a > responsible way of disclosing discoveries. Posting specific 0-day attack > vectors against affected sites is not one either. > >> > >> Making a public report over a holiday weekend, and then, when the > response to the report doesn''t immediately follow the proposed solution > (remove the feature), go off the reservation with specific attacks is just > plain irresponsible. No two ways about it. It also goes to undermine any > other recommendations or suggestions coming from said reporter. > >> > >> So. Damage is already done for this issue. But lest it encourages > others to act as irresponsibly as Homakov has done of this issue, I hope > others take a broader approach for future issues. Report systemic or > framework issues per the reporting instructions on > http://rubyonrails.org/security. Report specific application issues > directly to application developers responsibly per their reporting > instructions (see https://37signals.com/security-response for the one we > use at 37signals). > >> > >> Presumably we''re all in the same boat here: Make Rails better and more > secure. Let''s row like we mean that. The Rails security team (Michael > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past > to provide us with a good process, they''ve followed that process, and they > deserve our thanks and 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 <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/groups/opt_out. > > > > -- > > 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/rwzM8MKJbKU/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/groups/opt_out. > >-- 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+unsubscribe@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/groups/opt_out.
I feel entirely comfortable with shooting down REMOVE THE FEATURE as the first response to any security reporting. Our response should be, as it was here -- as it always is, let''s fix the issue. This is doubly so when security reportings are conflated with other architectural agendas, like "dinosaur feature removal quests". As it turns out, there is a very reasonable proposal for fixing this as well: Check js requests for xhr? and add the xhr header to all js requests through the framework, so it''ll work for GET as well. We''ll get this proposal vetted, of course, but if that pans out, it would be an entirely invisible fix that requires zero adjustment of the architectural style. Just like I mentioned it would, and as Homakov rejected outright initially as a possibility. Yes, there are many ways to make a buck, if you don''t care about how you do it. I don''t find that worthy of celebration. On Dec 2, 2013, at 8:13 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:> Your first message in this thread. He even quoted the relevant part in his article: > > "Not only are js.erb templates not deprecated, they are a great way to develop an application with Ajax responses where you can reuse your server-side templates. It''s fine to explore ways to make this more secure by default, but the fundamental development style of returning JS as a response is both architecturally sound and an integral part of Rails. So that''s not going anywhere. > > So let''s instead explore ways of having better escaping tools, warnings, or defaults that''ll work with the wonders of RJS." > > I understand you had the best of the intentions, but I wouldn''t have started the discussion by ending it. By this time you were not yet aware on how applications were affected and if there was a sane way to fix this issue. If I were you, I''d first *ask* if there''s an alternative way instead of deprecating its usage *before* deciding it wouldn''t go anywhere. > > I guess that was what pissed him off... > > I agree with you that this is not the "correct" way of dealing with the situation, from an ethics perspective, but let''s be honest: Homakov wouldn''t probably be a known name if he hadn''t put the attack to GitHub into practice. I''m not defending this approach to self marketing, but you can''t tell us it isn''t effective ;) > > Best, > Rodrigo. > > > Em 02-12-2013 14:01, David Heinemeier Hansson escreveu: >> What email is that? I replied to Homakov on Twitter thanking him for the discovery and stating a clear intent to get the issue resolved. What I rejected outright was the knee-jerk reaction to remove the possibility of generating JS responses from Rails. This rejection was confirmed when it got clear that the motivation behind that specific mitigation strategy was also motivated by architectural opinions on what''s dinosaur and what''s not. >> >> But again, even having this discussion here or on Twitter simply isn''t the proper forum to discuss 0-day exploits. It''s the reason we have a standardized security reporting and response protocol. It''s why we go to great lengths to coordinate proper fixes across multiple versions of Rails, following the CVE process, and other responsible steps in the process. >> >> To sidestep all that doesn''t help anyone but Homakov in the short-term to build a reputation as a take-no-prisoners grey hatter. I question the business strategy of that long-term (imagine having a business dispute with Homakov after giving him access to your system -- yikes!). >> >> Again, my opinion of the process is removed from the value of finding security holes. Of course finding and responsibly disclosing security holes is a good thing. I just wish that Homakov, and others who might be inspired by his tactics, would realize that there''s plenty of gain to be had personally by subscribing to these time-tested practices. >> >> >> On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote: >> >>> David, first I must say I admire both you and Homakov and I''d certainly hire him if I could afford it. >>> >>> I believe what led him to create that post was exactly your reponse to his e-mail. >>> >>> I agree he shouldn''t have created this discussion publicly but you shouldn''t have replied the way you did either. You should instead try to understand the problem first before saying it would go nowhere. >>> >>> I believe this is what caused Homakov reaction. >>> >>> Sincerely, >>> Rodrigo. >>> >>> Em 02-12-2013 13:47, DHH escreveu: >>>> Please stop conflating the discovery of a security issue with the philosophical waxing about architecture. It''s not helping the case. As stated previously, responding with JS is not only a wonderful architectural pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, not anywhere. We''ll fix the security issue, and Rails will continue to proudly champion the use of this great pattern. >>>> >>>> Guess what, it won''t be the last security issue Rails ever has. Just like it won''t be the last security issue any piece of software ever has. But we need to level up as a community in our handling of these issues. >>>> >>>> Frankly, I''m surprised that people are willing to hire Homakov for any work in the area given his reputation for irresponsible disclosure. Finding a legit security issues is a great services, but disregarding all security issue management protocols in their publication is doing a disservice to all who would otherwise benefit from the work. >>>> >>>> Rails has had a codified security process for many years now. It''s available for all to read on http://rubyonrails.org/security. Making a blog post on your personal site isn''t one of the channels listed as a responsible way of disclosing discoveries. Posting specific 0-day attack vectors against affected sites is not one either. >>>> >>>> Making a public report over a holiday weekend, and then, when the response to the report doesn''t immediately follow the proposed solution (remove the feature), go off the reservation with specific attacks is just plain irresponsible. No two ways about it. It also goes to undermine any other recommendations or suggestions coming from said reporter. >>>> >>>> So. Damage is already done for this issue. But lest it encourages others to act as irresponsibly as Homakov has done of this issue, I hope others take a broader approach for future issues. Report systemic or framework issues per the reporting instructions on http://rubyonrails.org/security. Report specific application issues directly to application developers responsibly per their reporting instructions (see https://37signals.com/security-response for the one we use at 37signals). >>>> >>>> Presumably we''re all in the same boat here: Make Rails better and more secure. Let''s row like we mean that. The Rails security team (Michael Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past to provide us with a good process, they''ve followed that process, and they deserve our thanks and 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-core+unsubscribe@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/groups/opt_out. >>> -- >>> 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/rwzM8MKJbKU/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out. > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
I''m sorry that you weren''t added to the hall of fame in a timely manner, and I''ll check into what happened, but that hardly justifies this shotgun approach to disclosure. Had you also contacted the other application makers for which you provided 0-day attacks? Did they also slight you in some way that justified this treatment? I''m just trying to figure out what the thought process is here, so we can calibrate our response for next time. If you get a response that a certain architectural style isn''t going to be changed as you first suggest, should the community expect that you''ll blast random applications with specific attack vectors on a 0-day basis? And if the reasons you describe are enough to, in your mind, warrant the 0-day option, should potential clients expect that similar minor disputes or grievances might result in 0-day public releases from the code bases you have examined? You''re obviously skilled at finding security issues. That''s a great skill to have, and it''s valuable to the community when wielded with care. But you''re not wielding it with care. On Dec 2, 2013, at 8:18 AM, Egor Homakov <homakov@gmail.com> wrote:> There''s a precise reason why I did so called "full disclosure" > > I started writing an email to security@37singals, then i checked out the previous conversation we had, where i was asked about my link for Hall of Fame. I gave the link and after a month it wasn''t added. No, i don''t really care, but given some other details (it was the second RJS bug in basecamp, "RJS bug" overall wasn''t 0 day at all, your ultimate rejection of RJS removal) i somehow ended up writing a post with full disclosure. > > I *mostly* follow responsible disclosure policies. But this is not my duty. Especially when i have couple of reasons to follow other policy. > > > > On Monday, December 2, 2013 11:01:21 PM UTC+7, DHH wrote: > What email is that? I replied to Homakov on Twitter thanking him for the discovery and stating a clear intent to get the issue resolved. What I rejected outright was the knee-jerk reaction to remove the possibility of generating JS responses from Rails. This rejection was confirmed when it got clear that the motivation behind that specific mitigation strategy was also motivated by architectural opinions on what''s dinosaur and what''s not. > > But again, even having this discussion here or on Twitter simply isn''t the proper forum to discuss 0-day exploits. It''s the reason we have a standardized security reporting and response protocol. It''s why we go to great lengths to coordinate proper fixes across multiple versions of Rails, following the CVE process, and other responsible steps in the process. > > To sidestep all that doesn''t help anyone but Homakov in the short-term to build a reputation as a take-no-prisoners grey hatter. I question the business strategy of that long-term (imagine having a business dispute with Homakov after giving him access to your system -- yikes!). > > Again, my opinion of the process is removed from the value of finding security holes. Of course finding and responsibly disclosing security holes is a good thing. I just wish that Homakov, and others who might be inspired by his tactics, would realize that there''s plenty of gain to be had personally by subscribing to these time-tested practices. > > > On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote: > > > David, first I must say I admire both you and Homakov and I''d certainly hire him if I could afford it. > > > > I believe what led him to create that post was exactly your reponse to his e-mail. > > > > I agree he shouldn''t have created this discussion publicly but you shouldn''t have replied the way you did either. You should instead try to understand the problem first before saying it would go nowhere. > > > > I believe this is what caused Homakov reaction. > > > > Sincerely, > > Rodrigo. > > > > Em 02-12-2013 13:47, DHH escreveu: > >> Please stop conflating the discovery of a security issue with the philosophical waxing about architecture. It''s not helping the case. As stated previously, responding with JS is not only a wonderful architectural pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, not anywhere. We''ll fix the security issue, and Rails will continue to proudly champion the use of this great pattern. > >> > >> Guess what, it won''t be the last security issue Rails ever has. Just like it won''t be the last security issue any piece of software ever has. But we need to level up as a community in our handling of these issues. > >> > >> Frankly, I''m surprised that people are willing to hire Homakov for any work in the area given his reputation for irresponsible disclosure. Finding a legit security issues is a great services, but disregarding all security issue management protocols in their publication is doing a disservice to all who would otherwise benefit from the work. > >> > >> Rails has had a codified security process for many years now. It''s available for all to read on http://rubyonrails.org/security. Making a blog post on your personal site isn''t one of the channels listed as a responsible way of disclosing discoveries. Posting specific 0-day attack vectors against affected sites is not one either. > >> > >> Making a public report over a holiday weekend, and then, when the response to the report doesn''t immediately follow the proposed solution (remove the feature), go off the reservation with specific attacks is just plain irresponsible. No two ways about it. It also goes to undermine any other recommendations or suggestions coming from said reporter. > >> > >> So. Damage is already done for this issue. But lest it encourages others to act as irresponsibly as Homakov has done of this issue, I hope others take a broader approach for future issues. Report systemic or framework issues per the reporting instructions on http://rubyonrails.org/security. Report specific application issues directly to application developers responsibly per their reporting instructions (see https://37signals.com/security-response for the one we use at 37signals). > >> > >> Presumably we''re all in the same boat here: Make Rails better and more secure. Let''s row like we mean that. The Rails security team (Michael Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past to provide us with a good process, they''ve followed that process, and they deserve our thanks and 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/groups/opt_out. > > > > -- > > 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/rwzM8MKJbKU/unsubscribe. > > To unsubscribe from this group and all its topics, 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/groups/opt_out. > > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
> Homakov rejected outright initially as a possibilityhttps://twitter.com/homakov/status/406466616897986560 Sorry for using "REMOVE THE FEATURE" wordings, now I see how it sounded. All i wanted is to fix security bug itself, throwing the feature away wasn''t my goal. On Monday, December 2, 2013 11:18:59 PM UTC+7, DHH wrote:> > I feel entirely comfortable with shooting down REMOVE THE FEATURE as the > first response to any security reporting. Our response should be, as it was > here -- as it always is, let''s fix the issue. This is doubly so when > security reportings are conflated with other architectural agendas, like > "dinosaur feature removal quests". > > As it turns out, there is a very reasonable proposal for fixing this as > well: Check js requests for xhr? and add the xhr header to all js requests > through the framework, so it''ll work for GET as well. We''ll get this > proposal vetted, of course, but if that pans out, it would be an entirely > invisible fix that requires zero adjustment of the architectural style. > Just like I mentioned it would, and as Homakov rejected outright initially > as a possibility. > > Yes, there are many ways to make a buck, if you don''t care about how you > do it. I don''t find that worthy of celebration. > > On Dec 2, 2013, at 8:13 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com<javascript:>> > wrote: > > > Your first message in this thread. He even quoted the relevant part in > his article: > > > > "Not only are js.erb templates not deprecated, they are a great way to > develop an application with Ajax responses where you can reuse your > server-side templates. It''s fine to explore ways to make this more secure > by default, but the fundamental development style of returning JS as a > response is both architecturally sound and an integral part of Rails. So > that''s not going anywhere. > > > > So let''s instead explore ways of having better escaping tools, warnings, > or defaults that''ll work with the wonders of RJS." > > > > I understand you had the best of the intentions, but I wouldn''t have > started the discussion by ending it. By this time you were not yet aware on > how applications were affected and if there was a sane way to fix this > issue. If I were you, I''d first *ask* if there''s an alternative way instead > of deprecating its usage *before* deciding it wouldn''t go anywhere. > > > > I guess that was what pissed him off... > > > > I agree with you that this is not the "correct" way of dealing with the > situation, from an ethics perspective, but let''s be honest: Homakov > wouldn''t probably be a known name if he hadn''t put the attack to GitHub > into practice. I''m not defending this approach to self marketing, but you > can''t tell us it isn''t effective ;) > > > > Best, > > Rodrigo. > > > > > > Em 02-12-2013 14:01, David Heinemeier Hansson escreveu: > >> What email is that? I replied to Homakov on Twitter thanking him for > the discovery and stating a clear intent to get the issue resolved. What I > rejected outright was the knee-jerk reaction to remove the possibility of > generating JS responses from Rails. This rejection was confirmed when it > got clear that the motivation behind that specific mitigation strategy was > also motivated by architectural opinions on what''s dinosaur and what''s not. > >> > >> But again, even having this discussion here or on Twitter simply isn''t > the proper forum to discuss 0-day exploits. It''s the reason we have a > standardized security reporting and response protocol. It''s why we go to > great lengths to coordinate proper fixes across multiple versions of Rails, > following the CVE process, and other responsible steps in the process. > >> > >> To sidestep all that doesn''t help anyone but Homakov in the short-term > to build a reputation as a take-no-prisoners grey hatter. I question the > business strategy of that long-term (imagine having a business dispute with > Homakov after giving him access to your system -- yikes!). > >> > >> Again, my opinion of the process is removed from the value of finding > security holes. Of course finding and responsibly disclosing security holes > is a good thing. I just wish that Homakov, and others who might be inspired > by his tactics, would realize that there''s plenty of gain to be had > personally by subscribing to these time-tested practices. > >> > >> > >> On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com<javascript:>> > wrote: > >> > >>> David, first I must say I admire both you and Homakov and I''d > certainly hire him if I could afford it. > >>> > >>> I believe what led him to create that post was exactly your reponse to > his e-mail. > >>> > >>> I agree he shouldn''t have created this discussion publicly but you > shouldn''t have replied the way you did either. You should instead try to > understand the problem first before saying it would go nowhere. > >>> > >>> I believe this is what caused Homakov reaction. > >>> > >>> Sincerely, > >>> Rodrigo. > >>> > >>> Em 02-12-2013 13:47, DHH escreveu: > >>>> Please stop conflating the discovery of a security issue with the > philosophical waxing about architecture. It''s not helping the case. As > stated previously, responding with JS is not only a wonderful architectural > pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, > not anywhere. We''ll fix the security issue, and Rails will continue to > proudly champion the use of this great pattern. > >>>> > >>>> Guess what, it won''t be the last security issue Rails ever has. Just > like it won''t be the last security issue any piece of software ever has. > But we need to level up as a community in our handling of these issues. > >>>> > >>>> Frankly, I''m surprised that people are willing to hire Homakov for > any work in the area given his reputation for irresponsible disclosure. > Finding a legit security issues is a great services, but disregarding all > security issue management protocols in their publication is doing a > disservice to all who would otherwise benefit from the work. > >>>> > >>>> Rails has had a codified security process for many years now. It''s > available for all to read on http://rubyonrails.org/security. Making a > blog post on your personal site isn''t one of the channels listed as a > responsible way of disclosing discoveries. Posting specific 0-day attack > vectors against affected sites is not one either. > >>>> > >>>> Making a public report over a holiday weekend, and then, when the > response to the report doesn''t immediately follow the proposed solution > (remove the feature), go off the reservation with specific attacks is just > plain irresponsible. No two ways about it. It also goes to undermine any > other recommendations or suggestions coming from said reporter. > >>>> > >>>> So. Damage is already done for this issue. But lest it encourages > others to act as irresponsibly as Homakov has done of this issue, I hope > others take a broader approach for future issues. Report systemic or > framework issues per the reporting instructions on > http://rubyonrails.org/security. Report specific application issues > directly to application developers responsibly per their reporting > instructions (see https://37signals.com/security-response for the one we > use at 37signals). > >>>> > >>>> Presumably we''re all in the same boat here: Make Rails better and > more secure. Let''s row like we mean that. The Rails security team (Michael > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past > to provide us with a good process, they''ve followed that process, and they > deserve our thanks and 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 <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/groups/opt_out. > >>> -- > >>> 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/rwzM8MKJbKU/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/groups/opt_out. > > > > -- > > 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/rwzM8MKJbKU/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/groups/opt_out. > >-- 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+unsubscribe@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/groups/opt_out.
Homakov, what we all want is to fix security bugs. There isn''t any justification for thinking that we aren''t all in the same boat on that. Things get muddy when you hinge the reporting of a security issue to your personal assessment of what a good architectural pattern is, though. So please. I implore you to change your ways. You can be a great part of this community and you can build a reputable security consulting business without resorting to these irresponsible tactics. We will get this specific issue fixed shortly (as soon as the GET .js solution by adding xhr headers has been vetted), I''m not in the least concerned about that. I''m concerned that we''ll be right back at square one next time you find an issue and you arm the internets with 0-day exploits against a random selection of applications before giving the makers a reasonable timeframe to defend themselves (one holiday weekend isn''t it). On Dec 2, 2013, at 8:30 AM, Egor Homakov <homakov@gmail.com> wrote:> > Homakov rejected outright initially as a possibility > https://twitter.com/homakov/status/406466616897986560 > Sorry for using "REMOVE THE FEATURE" wordings, now I see how it sounded. All i wanted is to fix security bug itself, throwing the feature away wasn''t my goal. > > > On Monday, December 2, 2013 11:18:59 PM UTC+7, DHH wrote: > I feel entirely comfortable with shooting down REMOVE THE FEATURE as the first response to any security reporting. Our response should be, as it was here -- as it always is, let''s fix the issue. This is doubly so when security reportings are conflated with other architectural agendas, like "dinosaur feature removal quests". > > As it turns out, there is a very reasonable proposal for fixing this as well: Check js requests for xhr? and add the xhr header to all js requests through the framework, so it''ll work for GET as well. We''ll get this proposal vetted, of course, but if that pans out, it would be an entirely invisible fix that requires zero adjustment of the architectural style. Just like I mentioned it would, and as Homakov rejected outright initially as a possibility. > > Yes, there are many ways to make a buck, if you don''t care about how you do it. I don''t find that worthy of celebration. > > On Dec 2, 2013, at 8:13 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote: > > > Your first message in this thread. He even quoted the relevant part in his article: > > > > "Not only are js.erb templates not deprecated, they are a great way to develop an application with Ajax responses where you can reuse your server-side templates. It''s fine to explore ways to make this more secure by default, but the fundamental development style of returning JS as a response is both architecturally sound and an integral part of Rails. So that''s not going anywhere. > > > > So let''s instead explore ways of having better escaping tools, warnings, or defaults that''ll work with the wonders of RJS." > > > > I understand you had the best of the intentions, but I wouldn''t have started the discussion by ending it. By this time you were not yet aware on how applications were affected and if there was a sane way to fix this issue. If I were you, I''d first *ask* if there''s an alternative way instead of deprecating its usage *before* deciding it wouldn''t go anywhere. > > > > I guess that was what pissed him off... > > > > I agree with you that this is not the "correct" way of dealing with the situation, from an ethics perspective, but let''s be honest: Homakov wouldn''t probably be a known name if he hadn''t put the attack to GitHub into practice. I''m not defending this approach to self marketing, but you can''t tell us it isn''t effective ;) > > > > Best, > > Rodrigo. > > > > > > Em 02-12-2013 14:01, David Heinemeier Hansson escreveu: > >> What email is that? I replied to Homakov on Twitter thanking him for the discovery and stating a clear intent to get the issue resolved. What I rejected outright was the knee-jerk reaction to remove the possibility of generating JS responses from Rails. This rejection was confirmed when it got clear that the motivation behind that specific mitigation strategy was also motivated by architectural opinions on what''s dinosaur and what''s not. > >> > >> But again, even having this discussion here or on Twitter simply isn''t the proper forum to discuss 0-day exploits. It''s the reason we have a standardized security reporting and response protocol. It''s why we go to great lengths to coordinate proper fixes across multiple versions of Rails, following the CVE process, and other responsible steps in the process. > >> > >> To sidestep all that doesn''t help anyone but Homakov in the short-term to build a reputation as a take-no-prisoners grey hatter. I question the business strategy of that long-term (imagine having a business dispute with Homakov after giving him access to your system -- yikes!). > >> > >> Again, my opinion of the process is removed from the value of finding security holes. Of course finding and responsibly disclosing security holes is a good thing. I just wish that Homakov, and others who might be inspired by his tactics, would realize that there''s plenty of gain to be had personally by subscribing to these time-tested practices. > >> > >> > >> On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote: > >> > >>> David, first I must say I admire both you and Homakov and I''d certainly hire him if I could afford it. > >>> > >>> I believe what led him to create that post was exactly your reponse to his e-mail. > >>> > >>> I agree he shouldn''t have created this discussion publicly but you shouldn''t have replied the way you did either. You should instead try to understand the problem first before saying it would go nowhere. > >>> > >>> I believe this is what caused Homakov reaction. > >>> > >>> Sincerely, > >>> Rodrigo. > >>> > >>> Em 02-12-2013 13:47, DHH escreveu: > >>>> Please stop conflating the discovery of a security issue with the philosophical waxing about architecture. It''s not helping the case. As stated previously, responding with JS is not only a wonderful architectural pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, not anywhere. We''ll fix the security issue, and Rails will continue to proudly champion the use of this great pattern. > >>>> > >>>> Guess what, it won''t be the last security issue Rails ever has. Just like it won''t be the last security issue any piece of software ever has. But we need to level up as a community in our handling of these issues. > >>>> > >>>> Frankly, I''m surprised that people are willing to hire Homakov for any work in the area given his reputation for irresponsible disclosure. Finding a legit security issues is a great services, but disregarding all security issue management protocols in their publication is doing a disservice to all who would otherwise benefit from the work. > >>>> > >>>> Rails has had a codified security process for many years now. It''s available for all to read on http://rubyonrails.org/security. Making a blog post on your personal site isn''t one of the channels listed as a responsible way of disclosing discoveries. Posting specific 0-day attack vectors against affected sites is not one either. > >>>> > >>>> Making a public report over a holiday weekend, and then, when the response to the report doesn''t immediately follow the proposed solution (remove the feature), go off the reservation with specific attacks is just plain irresponsible. No two ways about it. It also goes to undermine any other recommendations or suggestions coming from said reporter. > >>>> > >>>> So. Damage is already done for this issue. But lest it encourages others to act as irresponsibly as Homakov has done of this issue, I hope others take a broader approach for future issues. Report systemic or framework issues per the reporting instructions on http://rubyonrails.org/security. Report specific application issues directly to application developers responsibly per their reporting instructions (see https://37signals.com/security-response for the one we use at 37signals). > >>>> > >>>> Presumably we''re all in the same boat here: Make Rails better and more secure. Let''s row like we mean that. The Rails security team (Michael Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past to provide us with a good process, they''ve followed that process, and they deserve our thanks and 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/groups/opt_out. > >>> -- > >>> 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/rwzM8MKJbKU/unsubscribe. > >>> To unsubscribe from this group and all its topics, 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/groups/opt_out. > > > > -- > > 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/rwzM8MKJbKU/unsubscribe. > > To unsubscribe from this group and all its topics, 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/groups/opt_out. > > > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
I think i may have a solution, if i am wrong please don''t shoot me ;) https://github.com/artellectual/transponder/blob/develop/RAILS_UJS_VULNERABILITY_FIX.md On Monday, December 2, 2013 11:37:04 PM UTC+7, DHH wrote:> > Homakov, what we all want is to fix security bugs. There isn''t any > justification for thinking that we aren''t all in the same boat on that. > Things get muddy when you hinge the reporting of a security issue to your > personal assessment of what a good architectural pattern is, though. > > So please. I implore you to change your ways. You can be a great part of > this community and you can build a reputable security consulting business > without resorting to these irresponsible tactics. > > We will get this specific issue fixed shortly (as soon as the GET .js > solution by adding xhr headers has been vetted), I''m not in the least > concerned about that. I''m concerned that we''ll be right back at square one > next time you find an issue and you arm the internets with 0-day exploits > against a random selection of applications before giving the makers a > reasonable timeframe to defend themselves (one holiday weekend isn''t it). > > On Dec 2, 2013, at 8:30 AM, Egor Homakov <hom...@gmail.com <javascript:>> > wrote: > > > > Homakov rejected outright initially as a possibility > > https://twitter.com/homakov/status/406466616897986560 > > Sorry for using "REMOVE THE FEATURE" wordings, now I see how it sounded. > All i wanted is to fix security bug itself, throwing the feature away > wasn''t my goal. > > > > > > On Monday, December 2, 2013 11:18:59 PM UTC+7, DHH wrote: > > I feel entirely comfortable with shooting down REMOVE THE FEATURE as the > first response to any security reporting. Our response should be, as it was > here -- as it always is, let''s fix the issue. This is doubly so when > security reportings are conflated with other architectural agendas, like > "dinosaur feature removal quests". > > > > As it turns out, there is a very reasonable proposal for fixing this as > well: Check js requests for xhr? and add the xhr header to all js requests > through the framework, so it''ll work for GET as well. We''ll get this > proposal vetted, of course, but if that pans out, it would be an entirely > invisible fix that requires zero adjustment of the architectural style. > Just like I mentioned it would, and as Homakov rejected outright initially > as a possibility. > > > > Yes, there are many ways to make a buck, if you don''t care about how you > do it. I don''t find that worthy of celebration. > > > > On Dec 2, 2013, at 8:13 AM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> > wrote: > > > > > Your first message in this thread. He even quoted the relevant part in > his article: > > > > > > "Not only are js.erb templates not deprecated, they are a great way to > develop an application with Ajax responses where you can reuse your > server-side templates. It''s fine to explore ways to make this more secure > by default, but the fundamental development style of returning JS as a > response is both architecturally sound and an integral part of Rails. So > that''s not going anywhere. > > > > > > So let''s instead explore ways of having better escaping tools, > warnings, or defaults that''ll work with the wonders of RJS." > > > > > > I understand you had the best of the intentions, but I wouldn''t have > started the discussion by ending it. By this time you were not yet aware on > how applications were affected and if there was a sane way to fix this > issue. If I were you, I''d first *ask* if there''s an alternative way instead > of deprecating its usage *before* deciding it wouldn''t go anywhere. > > > > > > I guess that was what pissed him off... > > > > > > I agree with you that this is not the "correct" way of dealing with > the situation, from an ethics perspective, but let''s be honest: Homakov > wouldn''t probably be a known name if he hadn''t put the attack to GitHub > into practice. I''m not defending this approach to self marketing, but you > can''t tell us it isn''t effective ;) > > > > > > Best, > > > Rodrigo. > > > > > > > > > Em 02-12-2013 14:01, David Heinemeier Hansson escreveu: > > >> What email is that? I replied to Homakov on Twitter thanking him for > the discovery and stating a clear intent to get the issue resolved. What I > rejected outright was the knee-jerk reaction to remove the possibility of > generating JS responses from Rails. This rejection was confirmed when it > got clear that the motivation behind that specific mitigation strategy was > also motivated by architectural opinions on what''s dinosaur and what''s not. > > >> > > >> But again, even having this discussion here or on Twitter simply > isn''t the proper forum to discuss 0-day exploits. It''s the reason we have a > standardized security reporting and response protocol. It''s why we go to > great lengths to coordinate proper fixes across multiple versions of Rails, > following the CVE process, and other responsible steps in the process. > > >> > > >> To sidestep all that doesn''t help anyone but Homakov in the > short-term to build a reputation as a take-no-prisoners grey hatter. I > question the business strategy of that long-term (imagine having a business > dispute with Homakov after giving him access to your system -- yikes!). > > >> > > >> Again, my opinion of the process is removed from the value of finding > security holes. Of course finding and responsibly disclosing security holes > is a good thing. I just wish that Homakov, and others who might be inspired > by his tactics, would realize that there''s plenty of gain to be had > personally by subscribing to these time-tested practices. > > >> > > >> > > >> On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas < > rr.r...@gmail.com> wrote: > > >> > > >>> David, first I must say I admire both you and Homakov and I''d > certainly hire him if I could afford it. > > >>> > > >>> I believe what led him to create that post was exactly your reponse > to his e-mail. > > >>> > > >>> I agree he shouldn''t have created this discussion publicly but you > shouldn''t have replied the way you did either. You should instead try to > understand the problem first before saying it would go nowhere. > > >>> > > >>> I believe this is what caused Homakov reaction. > > >>> > > >>> Sincerely, > > >>> Rodrigo. > > >>> > > >>> Em 02-12-2013 13:47, DHH escreveu: > > >>>> Please stop conflating the discovery of a security issue with the > philosophical waxing about architecture. It''s not helping the case. As > stated previously, responding with JS is not only a wonderful architectural > pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, > not anywhere. We''ll fix the security issue, and Rails will continue to > proudly champion the use of this great pattern. > > >>>> > > >>>> Guess what, it won''t be the last security issue Rails ever has. > Just like it won''t be the last security issue any piece of software ever > has. But we need to level up as a community in our handling of these > issues. > > >>>> > > >>>> Frankly, I''m surprised that people are willing to hire Homakov for > any work in the area given his reputation for irresponsible disclosure. > Finding a legit security issues is a great services, but disregarding all > security issue management protocols in their publication is doing a > disservice to all who would otherwise benefit from the work. > > >>>> > > >>>> Rails has had a codified security process for many years now. It''s > available for all to read on http://rubyonrails.org/security. Making a > blog post on your personal site isn''t one of the channels listed as a > responsible way of disclosing discoveries. Posting specific 0-day attack > vectors against affected sites is not one either. > > >>>> > > >>>> Making a public report over a holiday weekend, and then, when the > response to the report doesn''t immediately follow the proposed solution > (remove the feature), go off the reservation with specific attacks is just > plain irresponsible. No two ways about it. It also goes to undermine any > other recommendations or suggestions coming from said reporter. > > >>>> > > >>>> So. Damage is already done for this issue. But lest it encourages > others to act as irresponsibly as Homakov has done of this issue, I hope > others take a broader approach for future issues. Report systemic or > framework issues per the reporting instructions on > http://rubyonrails.org/security. Report specific application issues > directly to application developers responsibly per their reporting > instructions (see https://37signals.com/security-response for the one we > use at 37signals). > > >>>> > > >>>> Presumably we''re all in the same boat here: Make Rails better and > more secure. Let''s row like we mean that. The Rails security team (Michael > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past > to provide us with a good process, they''ve followed that process, and they > deserve our thanks and 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/groups/opt_out. > > >>> -- > > >>> 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/rwzM8MKJbKU/unsubscribe. > > > >>> To unsubscribe from this group and all its topics, 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/groups/opt_out. > > > > > > -- > > > 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/rwzM8MKJbKU/unsubscribe. > > > > To unsubscribe from this group and all its topics, 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/groups/opt_out. > > > > > > > > -- > > 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/rwzM8MKJbKU/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/groups/opt_out. > >-- 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+unsubscribe@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/groups/opt_out.
I may have a possible solution, check it out (sorry if i double posted not sure if my previous post went through, as I have shitty internet) Kontax on Heroku <http://kontax.herokuapp.com> Kontax on Github <http://github.com/xpdr/kontax> https://github.com/artellectual/transponder/blob/develop/RAILS_UJS_VULNERABILITY_FIX.md On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
In this thread it has been repeated several times that .js endpoints via GET are a security breach. And that people should stick to JSON. Let me make clear for the archives that is not generally the case. There are valid use cases for dynamically generated public JavaScript, for example when your application exposes a widget 3rd party clients request to have their DOM modified with content. Think Disqus. I have implemented centralized rating systems for hotel providers that work that way. The potential problem happens when your JavaScript GET endpoint exposes sensitive/private data. Now, since the former is a rare use-case compared to the latter, the XHR protection should probably be enabled by default, but you need still to be able to opt-out. -- 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+unsubscribe@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/groups/opt_out.
Xavier, absolutely. Javan has suggested we have something like protect_from_forgery, which can be opt-out of on a per action/controller basis. On Dec 2, 2013, at 10:12 AM, Xavier Noria <fxn@hashref.com> wrote:> In this thread it has been repeated several times that .js endpoints via GET are a security breach. And that people should stick to JSON. > > Let me make clear for the archives that is not generally the case. There are valid use cases for dynamically generated public JavaScript, for example when your application exposes a widget 3rd party clients request to have their DOM modified with content. Think Disqus. I have implemented centralized rating systems for hotel providers that work that way. > > The potential problem happens when your JavaScript GET endpoint exposes sensitive/private data. > > Now, since the former is a rare use-case compared to the latter, the XHR protection should probably be enabled by default, but you need still to be able to opt-out. > > > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
I much appreciate RoR, its community Homakov included. I never saw RoR security team at least one time to appreciate Homakov''s findings. Perhaps you should take it closer by first recognize his security work over RoR. I''m quite sure that Homakov would have comply to your rules in the end. On Monday, December 2, 2013 5:47:07 PM UTC+2, DHH wrote:> > Please stop conflating the discovery of a security issue with the > philosophical waxing about architecture. It''s not helping the case. As > stated previously, responding with JS is not only a wonderful architectural > pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, > not anywhere. We''ll fix the security issue, and Rails will continue to > proudly champion the use of this great pattern. > > Guess what, it won''t be the last security issue Rails ever has. Just like > it won''t be the last security issue any piece of software ever has. But we > need to level up as a community in our handling of these issues. > > Frankly, I''m surprised that people are willing to hire Homakov for any > work in the area given his reputation for irresponsible disclosure. Finding > a legit security issues is a great services, but disregarding all security > issue management protocols in their publication is doing a disservice to > all who would otherwise benefit from the work. > > Rails has had a codified security process for many years now. It''s > available for all to read on http://rubyonrails.org/security. Making a > blog post on your personal site isn''t one of the channels listed as a > responsible way of disclosing discoveries. Posting specific 0-day attack > vectors against affected sites is not one either. > > Making a public report over a holiday weekend, and then, when the response > to the report doesn''t immediately follow the proposed solution (remove the > feature), go off the reservation with specific attacks is just plain > irresponsible. No two ways about it. It also goes to undermine any other > recommendations or suggestions coming from said reporter. > > So. Damage is already done for this issue. But lest it encourages others > to act as irresponsibly as Homakov has done of this issue, I hope others > take a broader approach for future issues. Report systemic or framework > issues per the reporting instructions on http://rubyonrails.org/security. > Report specific application issues directly to application developers > responsibly per their reporting instructions (see > https://37signals.com/security-response for the one we use at 37signals). > > Presumably we''re all in the same boat here: Make Rails better and more > secure. Let''s row like we mean that. The Rails security team (Michael > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past > to provide us with a good process, they''ve followed that process, and they > deserve our thanks and 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-core+unsubscribe@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/groups/opt_out.
I am trying to imagine "dynamically generated public JavaScript" but nothing comes to my mind. Any small bit of information, even the fact that user is logged in, or blocked, is somewhat sensitive IMO. Opt-out is must-have indeed. E.g. in development env it might be convenient to reach .json endpoints directly. On Tuesday, December 3, 2013 1:12:14 AM UTC+7, Xavier Noria wrote:> > In this thread it has been repeated several times that .js endpoints via > GET are a security breach. And that people should stick to JSON. > > Let me make clear for the archives that is not generally the case. There > are valid use cases for dynamically generated public JavaScript, for > example when your application exposes a widget 3rd party clients request to > have their DOM modified with content. Think Disqus. I have implemented > centralized rating systems for hotel providers that work that way. > > The potential problem happens when your JavaScript GET endpoint exposes > sensitive/private data. > > Now, since the former is a rare use-case compared to the latter, the XHR > protection should probably be enabled by default, but you need still to be > able to opt-out. > > >-- 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+unsubscribe@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/groups/opt_out.
On Mon, Dec 2, 2013 at 7:43 PM, Egor Homakov <homakov@gmail.com> wrote: I am trying to imagine "dynamically generated public JavaScript" but> nothing comes to my mind. >This is an old trick. Your service provides a small JavaScript snippet for hosting sites to embed. The snippet generates a SCRIPT tag in the hosting DOM whose creation triggers a (GET) request to fetch JavaScript from the central service, in the provider''s domain. That as you know is not subjected to the same-origin policy, hence the technique. See for example the snippet of Disqus: http://disqus.com/admin/universalcode/ The response contains JavaScript, whose evaluation injects content in the host page. The user browsing the hosting website is not a user of the service provider, users may not even realize there is a centralized service providing that section of the page. -- 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+unsubscribe@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/groups/opt_out.
Embeddable gists are another example: <script src="https://gist.github.com/javan/7725255.js"></script> On Monday, December 2, 2013 2:11:24 PM UTC-5, Xavier Noria wrote:> > On Mon, Dec 2, 2013 at 7:43 PM, Egor Homakov <hom...@gmail.com<javascript:> > > wrote: > > I am trying to imagine "dynamically generated public JavaScript" but >> nothing comes to my mind. >> > > This is an old trick. > > Your service provides a small JavaScript snippet for hosting sites to > embed. The snippet generates a SCRIPT tag in the hosting DOM whose creation > triggers a (GET) request to fetch JavaScript from the central service, in > the provider''s domain. That as you know is not subjected to the same-origin > policy, hence the technique. > > See for example the snippet of Disqus: > > http://disqus.com/admin/universalcode/ > > The response contains JavaScript, whose evaluation injects content in the > host page. > > The user browsing the hosting website is not a user of the service > provider, users may not even realize there is a centralized service > providing that section of the page. > > >-- 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+unsubscribe@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/groups/opt_out.
I''ve been using RJS for quite a while and I think it''s a wonderful way to render server-side template and form errors. I agree with everyone that this issue is important as my ticket shows (https://github.com/rails/rails/issues/11509). I''ve had a somewhat crazy idea a few months back and I''m sorry if I side track the issue at hand. I am currently thinking about using a websocket for this kind of query (I have a very rough alpha working). The gist would be to have a websocket open on DOMContentReady (there wouldn''t be any reconnection due to the nature of turbolinks). From there, every ajax request would be made through the websocket instead of the normal HTTP procedure. This, as far as I understand, would have the advantage of making XSS impossible (Websockets follows the same-origin policy). Right now, this idea would be somewhat of a hack for different reason: A Javascript client script would have to take every click event on a[data-remote=true] and take the URL and pass it to the websocket which would then use Journey as normal to dispatch the request to the right controller. The response would then be sent through the websocket (The headers could be entirely drop). I think this idea could possibly fix this issue altogether while being completely transparent to developers. Do I make sense? Is it a stupid idea? On Thursday, November 28, 2013 3:41:37 AM UTC-5, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
Marius, your solution is not much different from responding a render :json : you send only the data, and the processing code is already on client side; transponder.js seems to me that it adds an abstraction level in order to manage the data, but it is different from RJS, which sends the execution code too, that is necessary for running the examples made before, like Disqus, or single page apps. transponder.js a good solution if you don''t want / need to send the execution code, as render :json , but I think I got that RJS is necessary for other contexts. -- Maurizio De Santis 2013/12/2 Marius Corîci <marius.corci4@gmail.com>> I much appreciate RoR, its community Homakov included. I never saw RoR > security team at least one time to appreciate Homakov''s findings. Perhaps > you should take it closer by first recognize his security work over RoR. > I''m quite sure that Homakov would have comply to your rules in the end. > > > On Monday, December 2, 2013 5:47:07 PM UTC+2, DHH wrote: >> >> Please stop conflating the discovery of a security issue with the >> philosophical waxing about architecture. It''s not helping the case. As >> stated previously, responding with JS is not only a wonderful architectural >> pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, >> not anywhere. We''ll fix the security issue, and Rails will continue to >> proudly champion the use of this great pattern. >> >> Guess what, it won''t be the last security issue Rails ever has. Just like >> it won''t be the last security issue any piece of software ever has. But we >> need to level up as a community in our handling of these issues. >> >> Frankly, I''m surprised that people are willing to hire Homakov for any >> work in the area given his reputation for irresponsible disclosure. Finding >> a legit security issues is a great services, but disregarding all security >> issue management protocols in their publication is doing a disservice to >> all who would otherwise benefit from the work. >> >> Rails has had a codified security process for many years now. It''s >> available for all to read on http://rubyonrails.org/security. Making a >> blog post on your personal site isn''t one of the channels listed as a >> responsible way of disclosing discoveries. Posting specific 0-day attack >> vectors against affected sites is not one either. >> >> Making a public report over a holiday weekend, and then, when the >> response to the report doesn''t immediately follow the proposed solution >> (remove the feature), go off the reservation with specific attacks is just >> plain irresponsible. No two ways about it. It also goes to undermine any >> other recommendations or suggestions coming from said reporter. >> >> So. Damage is already done for this issue. But lest it encourages others >> to act as irresponsibly as Homakov has done of this issue, I hope others >> take a broader approach for future issues. Report systemic or framework >> issues per the reporting instructions on http://rubyonrails.org/security. >> Report specific application issues directly to application developers >> responsibly per their reporting instructions (see https://37signals.com/ >> security-response for the one we use at 37signals). >> >> Presumably we''re all in the same boat here: Make Rails better and more >> secure. Let''s row like we mean that. The Rails security team (Michael >> Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past >> to provide us with a good process, they''ve followed that process, and they >> deserve our thanks and support. >> > -- > 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/rwzM8MKJbKU/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > rubyonrails-core+unsubscribe@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/groups/opt_out. >-- 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+unsubscribe@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/groups/opt_out.
Sorry, I meant Zack. -- Maurizio De Santis 2013/12/3 Maurizio De Santis <desantis.maurizio@gmail.com>> Marius, your solution is not much different from responding a render :json > : you send only the data, and the processing code is already on client > side; transponder.js seems to me that it adds an abstraction level in order > to manage the data, but it is different from RJS, which sends the execution > code too, that is necessary for running the examples made before, like > Disqus, or single page apps. > > transponder.js a good solution if you don''t want / need to send the > execution code, as render :json , but I think I got that RJS is necessary > for other contexts. > > -- > > Maurizio De Santis > > > 2013/12/2 Marius Corîci <marius.corci4@gmail.com> > >> I much appreciate RoR, its community Homakov included. I never saw RoR >> security team at least one time to appreciate Homakov''s findings. Perhaps >> you should take it closer by first recognize his security work over RoR. >> I''m quite sure that Homakov would have comply to your rules in the end. >> >> >> On Monday, December 2, 2013 5:47:07 PM UTC+2, DHH wrote: >>> >>> Please stop conflating the discovery of a security issue with the >>> philosophical waxing about architecture. It''s not helping the case. As >>> stated previously, responding with JS is not only a wonderful architectural >>> pattern, it''s also not going anywhere. Not in a gem, not in a deprecation, >>> not anywhere. We''ll fix the security issue, and Rails will continue to >>> proudly champion the use of this great pattern. >>> >>> Guess what, it won''t be the last security issue Rails ever has. Just >>> like it won''t be the last security issue any piece of software ever has. >>> But we need to level up as a community in our handling of these issues. >>> >>> Frankly, I''m surprised that people are willing to hire Homakov for any >>> work in the area given his reputation for irresponsible disclosure. Finding >>> a legit security issues is a great services, but disregarding all security >>> issue management protocols in their publication is doing a disservice to >>> all who would otherwise benefit from the work. >>> >>> Rails has had a codified security process for many years now. It''s >>> available for all to read on http://rubyonrails.org/security. Making a >>> blog post on your personal site isn''t one of the channels listed as a >>> responsible way of disclosing discoveries. Posting specific 0-day attack >>> vectors against affected sites is not one either. >>> >>> Making a public report over a holiday weekend, and then, when the >>> response to the report doesn''t immediately follow the proposed solution >>> (remove the feature), go off the reservation with specific attacks is just >>> plain irresponsible. No two ways about it. It also goes to undermine any >>> other recommendations or suggestions coming from said reporter. >>> >>> So. Damage is already done for this issue. But lest it encourages others >>> to act as irresponsibly as Homakov has done of this issue, I hope others >>> take a broader approach for future issues. Report systemic or framework >>> issues per the reporting instructions on http://rubyonrails.org/security. >>> Report specific application issues directly to application developers >>> responsibly per their reporting instructions (see https://37signals.com/ >>> security-response for the one we use at 37signals). >>> >>> Presumably we''re all in the same boat here: Make Rails better and more >>> secure. Let''s row like we mean that. The Rails security team (Michael >>> Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past >>> to provide us with a good process, they''ve followed that process, and they >>> deserve our thanks and support. >>> >> -- >> 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/rwzM8MKJbKU/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> rubyonrails-core+unsubscribe@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/groups/opt_out. >> > >-- 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+unsubscribe@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/groups/opt_out.
so if/when this will make it to master? On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote:> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i''m talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > >-- 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+unsubscribe@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/groups/opt_out.
Jeremy Kemper is assigned to this. We will get this in shortly.> On Dec 8, 2013, at 20:19, Egor Homakov <homakov@gmail.com> wrote: > > so if/when this will make it to master? > >> On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> >> Here in discussion I proposed to deprecate JS responder because this technique is insecure and not pragmatic way to transfer data. >> It can be exploited in this way http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> >> i find this bug very often so i know what i''m talking about. With it attacker can steal user data and authenticity_token if templates with form were leaked too. > > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.
Just add a small flash about this issue. JSON has a similar issue where it prepend ''for (;;);'' before the JSON payload. Wouldn''t it be an idea to prepend any js.erb template with ''for (;;);'' and use String.substr(9) to remove that infinite loop before injecting the payload in the <script>. This way, JS would be safe without need to do extra verification on the server side. On Monday, December 9, 2013 12:51:41 AM UTC-5, DHH wrote:> > Jeremy Kemper is assigned to this. We will get this in shortly. > > On Dec 8, 2013, at 20:19, Egor Homakov <hom...@gmail.com <javascript:>> > wrote: > > so if/when this will make it to master? > > On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >> >> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> >> Here in discussion I proposed to deprecate JS responder because this >> technique is insecure and not pragmatic way to transfer data. >> It can be exploited in this way >> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> >> i find this bug very often so i know what i''m talking about. With it >> attacker can steal user data and authenticity_token if templates with form >> were leaked too. >> >> >> >> -- > 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/rwzM8MKJbKU/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/groups/opt_out. > >-- 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+unsubscribe@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/groups/opt_out.
Just had a flash about this issue. JSON has a similar issue and it solved it by prepending ''for (;;);'' before the JSON payload. Wouldn''t it be an idea to prepend any js.erb template with ''for (;;);'' and use String.substr(9) (9 being the size of the for loop) to remove that loop before injecting the payload in the <script>. This way, JS would be safe without need to do extra verification on the server side. On Monday, December 9, 2013 12:51:41 AM UTC-5, DHH wrote:> > Jeremy Kemper is assigned to this. We will get this in shortly. > > On Dec 8, 2013, at 20:19, Egor Homakov <hom...@gmail.com <javascript:>> > wrote: > > so if/when this will make it to master? > > On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >> >> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> >> Here in discussion I proposed to deprecate JS responder because this >> technique is insecure and not pragmatic way to transfer data. >> It can be exploited in this way >> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> >> i find this bug very often so i know what i''m talking about. With it >> attacker can steal user data and authenticity_token if templates with form >> were leaked too. >> >> >> >> -- > 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/rwzM8MKJbKU/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/groups/opt_out. > >-- 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+unsubscribe@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/groups/opt_out.
that solution is ugly. for(;;) means code on server side to add it and code on client side to slice. While .xhr? check is one line in ApplicationController. On Saturday, December 14, 2013 7:11:03 AM UTC+7, Pier-Olivier Thibault wrote:> > Just had a flash about this issue. > > JSON has a similar issue and it solved it by prepending ''for (;;);'' before > the JSON payload. > > Wouldn''t it be an idea to prepend any js.erb template with ''for (;;);'' and > use String.substr(9) (9 being the size of the for loop) to remove that loop > before injecting the payload in the <script>. This way, JS would be safe > without need to do extra verification on the server side. > > On Monday, December 9, 2013 12:51:41 AM UTC-5, DHH wrote: >> >> Jeremy Kemper is assigned to this. We will get this in shortly. >> >> On Dec 8, 2013, at 20:19, Egor Homakov <hom...@gmail.com> wrote: >> >> so if/when this will make it to master? >> >> On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >>> >>> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >>> >>> Here in discussion I proposed to deprecate JS responder because this >>> technique is insecure and not pragmatic way to transfer data. >>> It can be exploited in this way >>> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >>> >>> i find this bug very often so i know what i''m talking about. With it >>> attacker can steal user data and authenticity_token if templates with form >>> were leaked too. >>> >>> >>> >>> -- >> 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/rwzM8MKJbKU/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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/groups/opt_out. >> >>-- 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+unsubscribe@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/groups/opt_out.
For Rails 4.1: https://github.com/rails/rails/pull/13345 Since we don''t know the response format until rendering, it''s simplest to use an after_action to verify that we aren''t serving JS to a non-XHR GET request. This piggybacks on the same `protect_from_forgery` declarations that apps already use, so they''ll transparently get protection without changing anything. Apps that intentionally expose JavaScript responses (like third-party widgets, per-customer API embeds, etc) will need to exclude those actions using existing `protect_from_forgery` API. Thanks everyone for the (long) discussion and thanks to Egor for the initial report - months ago now! - and this reminder. On Sun, Dec 8, 2013 at 10:51 PM, David Heinemeier Hansson <david@loudthinking.com> wrote:> Jeremy Kemper is assigned to this. We will get this in shortly. > > On Dec 8, 2013, at 20:19, Egor Homakov <homakov@gmail.com> wrote: > > so if/when this will make it to master? > > On Thursday, November 28, 2013 3:41:37 PM UTC+7, Egor Homakov wrote: >> >> https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> >> Here in discussion I proposed to deprecate JS responder because this >> technique is insecure and not pragmatic way to transfer data. >> It can be exploited in this way >> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> >> i find this bug very often so i know what i''m talking about. With it >> attacker can steal user data and authenticity_token if templates with form >> were leaked too. >> >> >> > -- > 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/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > rubyonrails-core+unsubscribe@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/groups/opt_out. > > -- > 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+unsubscribe@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/groups/opt_out.-- 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+unsubscribe@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/groups/opt_out.