Comment by bdcravens | Hacker News Reader

Comment by bdcravens | Hacker News Reader

Parent Full thread

I don't think "Rails generation" means only Rails. I think the idea is that we're so dependent on frameworks these days, there are massive pieces of our application that we have no clue how they work, and worse, we trust the framework authors implicitly. More and more we're seeing the downfalls of this. As Rails is essentially the best known and most deployed, hence the name.

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.

> If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow.

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'd encourage you to read those vulnerabilities, not just Google to disprove me. I'm speaking specifically on the ability for someone to remotely execute code on a ASP.NET WebForms application, and that was just a random example. What you linked to was comparable to saying Groovy is insecure because of the most recent vulnerability found in Java browser plugins. (http://www.itpro.co.uk/645031/new-java-7-bug-prompts-calls-f...)

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)

> What you linked to was comparable to saying Groovy is insecure because of the most recent vulnerability found in Java browser plugins.

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?

That's probably 10s of thousands of eyes who don't know their arse from their elbow, including the guys who wrote it.

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.

I think you seriously underestimate the sheer quantity of people looking through it, my friend.

And if we're using that metric, it's extremely unlikely your average team member knows his or her ass from their elbow, either.

Quite possibly.

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.

Read the damn vulnerability description. I've actually just finishing the QA cycle on our app for this and its a very niche issue.

Reply on news.ycombinator.com