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