Well that's not really a surprise.
Perhaps the "Rails generation" will gain some engineering, product selection and QA skills now.
There's a big reason banks operate the way they do with the kit they do.
Perhaps the "Rails generation" will gain some engineering, product selection and QA skills now.
There's a big reason banks operate the way they do with the kit they do.
[1] Auto-Unmarshalling yaml in xml, seriously? Who wants yaml in xml?
[2] I'm sorry to single out spring here, but this is a nice example since it's the same kind of attack: Instatiation of an arbitrary class, in this case by modifying the class loader and loading the class from a remote server: http://support.springsource.com/security/cve-2010-1622
[1] Sinatra didn't, but that's < 1000 LOC.
I would gladly take the other side of that bet.
A decade ago I was working on a site using Perl/Mason/Apache. When we were bought by eBay, we were put through a thorough pen test. The ONLY security hole they identified as needing fixing was a redirect that could redirect to any URL anywhere. (The people testing us were shocked - they had never before seen that few problems.)
To the best of my knowledge, no holes have been discovered in that architecture in the following decade either. (Looking through Apache vulnerabilities, there have been a couple of remote code exploits. But not on all platforms, and we turned off every feature we didn't need.)
If you take the attitude up front that you won't have magic, this kind of bug doesn't tend to slip in. If you take the attitude that there will be a lot of magic, then this kind of bug does slip in.
You admit that the framework you used had a couple of exploits and you were not affected because you turned of all features that you didn't need. The current rails vulnerability does not affect you if you turned off all features you didn't need. Same argument. So we have a hole in Mason, I already cited one in Spring, someone else cited one in .NET http://news.ycombinator.com/item?id=5043839.
Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype.
However, my original generalizes the problem as a human issue which is where the real problem is:
Did they do a risk analysis on rails - no
Did they verify their architecture - no
Did they perform input/type checking - no (sorry but statically typed languages win here)
Did they act responsibly - no
Would you trust them with your cash? Probably not then.
This is the opposite of banks who have multiple layers of security to prevent all the associated risks of the business.
Would a bank run their OLTP on rails? Hell no, because they did the risk analysis above, which is my point.
Actually, this bug was discovered precisely because people began to perform a more in depth analysis.
>Did they perform input/type checking - no (sorry but statically typed languages win here)
LOL. It's 2013. Can we stop having this preposterous argument?
The argument is definitely not preposterous. Are you saying guarding against bad inputs and enforcing type is bad? A language which uses no type inference has less assumptions therefore is likely to be less error prone. I've proven this hundreds of times over the last 30 years of writing code in things from communications electronics to financial quotation platforms.
And you know what, I have a feeling they did have multiple people looking over the code, and it's been vigorously refactored over the years. Rails 3 is a somewhat different beast from Rails 2.
Careful auditing reduces bugs but does not eliminate them. Crowing about "proper engineering" is very nice but is somewhat farcical given the state of the art in the industry.
>Are you saying guarding against bad inputs and enforcing type is bad?
No. Of course you guard against bad inputs.
But that's wholly separate from enforcing the type of the objects. And it's not like people are eval()ing stuff willy-nilly.
For example float vs decimal types in finance. You really want your bank running on floats when doing interest calculations?
From Wikipedia: Ruby on Rails - Initial release July 2004
Eight-and-a-half years later, in depth analysis has come about to find this? (The exploit is present through 3.2, meaning it's been around all that time).
Would a bank run their OLTP on rails? I don't know. I'd rather say that rails is a bad fit for that kind of problem, but that's not the goal. Rails is built for web-applications of a pretty specific type, quick build and release cycles while still keeping a solid focus on code quality [1]. So your problem is that folks see an opportunity to make money, take the first tool that seems to fit and build stuff that doesn't hold water. But that's language agnostic. You certainly realize that 10 years ago java was the "poorly specified rickety language in a community of hype".
[1] I never dreamed I'd be defending rails. gosh.
Think about it: for most apps, probably 95% of your code is a framework that you didn't write. When this is criticized, the response is typically "open source unicorns! speak no more!" Moreover, there seems to be a different level of forgiveness just because it's open source. If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow.
I love frameworks, and I think an average team would on the whole write less secure code than an open source framework would. If we want maximum transparency into our code, we'd go back to CGI written in C, but our productivity would tank, and looking back, the boom of recent years never would have happened.
However, we need a different attitude. Let's be honest: the arguments about open source are mostly a lie. Yeah, I went there. No, I'm not advocating closed source. Too many hang their hat on the ideals of open source. We're not talking ideals. We're talking rubber meets the road, cash leaves the bank reality. "Anyone can view the source - many eyeballs makes it more secure." The truth is, there aren't that many eyeballs. How many download, or (for the real technology ninjas) git clone, and trust what they're working with (whether app or framework) by a faith that rivals any religious organization?
As an industry, we need to read more code. We need to push back against the Barnes and Noble developer, the one who paid $29 for a book and now calls themselves a developer because they finished it front to back. Not everyone needs to be a senior engineer, but we have too many with that title after 3 years of building framework apps who couldn't code their way out of a CS101 class if they had Donald Knuth and Dennis Ritchie as their personal tutors.
This is pure supposition, but I think if at least 10% of those who used Rails read Rails, it'd be far more secure.
That's a joke, right?
https://www.google.ca/search?q=asp.net+remote+code&oq=as...
>we trust the framework authors implicitly
You want to export your common web app code to a framework for all the same reasons you don't want to write your own crypto libraries - the more people look at it the safer it is.
Far more damage has been done to the web from people not using a good ORM or a toolkit that escapes your view layer against XSS, or forgot to add request forgery protection.
I never claimed we shouldn't leverage well-written projects. I do challenge the idea that there's many eyeballs: most download and have faith. There's a bunch of eyeballs, yes, but not nearly as many as we tell ourselves.
You're totally right about frameworks resulting in better, more secure apps. However, much of that is relative: when most apps are hand-crafting SQL, JavaScript, and form handling, a framework is heads above other apps, especially when most attackers go for low-hanging fruit. However, when we get to a point where most apps are in frameworks, where would attackers turn their attention? Is an app inherently secure, or secure because it's less of a target? (Think the Mac vs. PC security arguments)
Not really, because in .NET separating the "language" from the "framework" is a little thornier.
And the difference is all the more moot from a practical point of view: you still have to rush out and patch everything.
> However, when we get to a point where most apps are in frameworks, where would attackers turn their attention? Is an app inherently secure, or secure because it's less of a target?
You're not wrong in that widespread deployments of the same code base are what make these kinds of attacks possible in the first place; that's one downside of this kind of monoculture.
I can tell you however that these frameworks make it easier to write secure code in the first place. My business partner in my consultancy is a security researcher, and his job is to break apps. Frameworks like Rails make his life "harder" (in so far that one looks good by finding vulnerabilities); there is a ton of automated tooling that can probe and exploit a myriad of common-developer-mistakes-or-misconceptions.
Code you wrote within your team is audited by 10 people, tops. Code like Rails has been seen thousands of eyeballs. Even with several orders of magnitude of more attention, stuff like this still slips by. What are the odds you are better off?
Possibly 2-3 people have read it who know their shit. The rest are just consumers.
Frameworks only centralise the security concerns - they don't necessarily make it better. That is in the hands of the implementor and their ability to build bullet proof abstractions. One fuck up and your system is globally compromised. It is the right solution, but you need the right people. Rails hasn't had the right people.
And if we're using that metric, it's extremely unlikely your average team member knows his or her ass from their elbow, either.
I agree with your second point, which is why I am a senior member of an architecture team in a company with 80 developers. It's our job to make sure ass and elbow confusion doesn't compromise the product.