> 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]<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 > >> <[email protected]<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 [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 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 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.
