Who'd have thought it? Hugely dynamic language turns out to be difficult to audit or analyse for security issues.
It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you don't need to test it because that's Someone Else's Problem. Auditing it is nearly impossible not least because it's a moving target, so you either get stuck in a backwater of obsolete versions that once got audited and approved or you live on the bleeding edge constantly (and DevOps hate you forever).
FWIW we (large satnav company) prototyped the last major service in Rails (actually a one-man hack proof of concept) then implemented it in production in Scala (and that was a bridge too far for a lot of people) because no-one wanted to run Rails in production.
I'm happy you work in the kind of place that audits all of its software, though. I'm sure you've all read through all of Hibernate, Spring and not to mention all the .NET framework code.
That is a straw man. Nobody claims there are not issues in other software.
The claim here is that people in dynamic languages tend to misuse that and write all sorts of magic that are pure gold for 10-line snippets but open up a vast attack surface, like building completely arbitrary objects from string input.
> Could you show me how I could possibly create such a hole in a language like ocaml or haskell?
First you'd have to write the equivalent of Rails in Haskell (I'm not talking about an MVC framework, but something as large, complex, and featureful.)
No, I am asking how you could actually create this vulnerability in haskell at all. No framework required, just actively, intentionally trying to create this hole.
> The value of a parameter id was reflected to the HTTP response
The link you posted illustrates that it is unfortunate that Java supports reflection, and even more unfortunate that various "enterprise" software stacks abuse reflection in ever more creative ways. Stay away of Java reflection and/or use C/C++, and you'll avoid this kind of vulnerabilities.
This isn't about languages; what the language gives the language can take away. This is about diligence, responsiveness, and transparency.
Rails will always have zero-day security issues; I'd hazard that all web apps of any notable size will. What matters most to me is how the core team and community respond on those three criteria above.
Lately the Rails team has been performing exceptionally.
All software has bugs, and the subset of bugs which turn out to be security vulnerabilities is borderline asymptotic.
That's not to say all frameworks are created equally secure, but the differences have more to do with the culture around the project than any technical decisions (minus some very specific language-related issues).
Rails is a big, public project; with many years now of being used by a sizable number of people. There will be more security vulnerabilities discovered, hopefully they'll be addressed quickly and communicated well (which this one seems to be).
That's a long-winded way of saying to be cautious with picking some other framework because it has less security vulnerabilities reported, that almost certainly has no bearing on it being more secure.
Security is a process; what matters is how people respond to new vulnerabilities. I'm naturally biased pro-Rails, but so far I don't feel uncomfortable with how it has been handled.
I can't comment on how on-the-ball the Rails security team is, but I can say it's really easy to update your apps.
It's also relative to your alternatives. It's way safer than not using a framework. Is it safer than Django? That's kind of unknowable; maybe, maybe not.
I've worked with other vendors. The rails security team is the best I've worked with. The major positives:
* Quick turn around. I have another vendor where it takes up to 3 months to get stuff fixed. :(
* They give you a patch to review before releasing publicly. This is very important and gives researchers a chance to fix any problems with the patch. With another vendor their fix missed a really obvious attack vector and anyone who diffed the code would have been given a free zero day vulnerability. :(
As an average joe web dev I also found the security team very easy to work with when I discovered a vulnerability. In that case I worked directly with them to create the patch that was released as Rails 2.3.5. It was something like 48 hours from the time I discovered it to the release.
Please know that Rails is definitely very secure, and it has gone through many years of testing and review. However, no framework is immune. We should be grateful that the bug was found, patched, and notified, instead of being silently exploited by some black-hat who discovered it first.
The following is speculation, but keep in mind that this bug may have been found because the Rails team has been looking for security holes similar to the exploit that was found a few days ago.
I agree completely, it's just that this error seems so obvious and dangerous that it's odd it hasn't been caught for over 7 years.
ps: I love Tekpub! Are there any plans for some new Rails videos? I purchased the Rails 3 series but it's a bit outdated, given how fast Rails moves. Would purchase a series on Rails 4 day-one. :)
I'm in a similar boat. I've just began with Rails in the last six months, and I've really been enjoying it. These vulnerabilities are unnerving but I am comforted by the visibility of the announcements. The community seems to get the message out very quickly when an exploit is found/patched.
My entire Twitter feed is filled with Rails developers telling others to upgrade immediately, and HN has multiple new posts about it.
If you read the insinuator.net article posted elsewhere on this thread, you'll see that Java (Struts), PHP, and Python have all had their own remote-code-execution vulnerabilities over the years.
It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you don't need to test it because that's Someone Else's Problem. Auditing it is nearly impossible not least because it's a moving target, so you either get stuck in a backwater of obsolete versions that once got audited and approved or you live on the bleeding edge constantly (and DevOps hate you forever).
FWIW we (large satnav company) prototyped the last major service in Rails (actually a one-man hack proof of concept) then implemented it in production in Scala (and that was a bridge too far for a lot of people) because no-one wanted to run Rails in production.