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 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.
