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 <[email protected] <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 <[email protected]> > 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 < > [email protected]> 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 [email protected]. > > >>>> To post to this group, send email to [email protected]. > > >>>> 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 > [email protected]. > > >>> To post to this group, send email to [email protected]. > > >>> 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 > [email protected]. > > > To post to this group, send email to [email protected]. > > > 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 > [email protected] <javascript:>. > > To post to this group, send email to > > [email protected]<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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
