Every time I find or see an SQL injection issue I get angry. It's 2014, why are web developers still making the same basic mistakes? SQL injection is a fixed issue. There is no excuse.
Same with XSS, although not as serious it's staggeringly common.
I believe it is essentially a function of the skill distribution and price of developers.
There will always be a spectrum of skill level; there will always be very inexperienced, low-skilled developers just about able to knock together something that works, but is susceptible to SQL injection. These inexperienced developers will charge less, and will get work, so there will always be an endless supply of new developers making new sites that are susceptible.
I can think of three ways (and various combinations/subsets of them) it would ever stop:
1) The tools themselves to somehow fall out of favour and be replaced with tools that make it harder to make this kind of mistake
2) Developers become compelled to undergo regulation and trade guilds or related, such that their skill level just to do business exceeds the aforementioned minimum
3) Websites (or a subset thereof) become regulated such that they are inspected/audited for this kind of thing, which would compel businesses to pay more to hire competent developers.
I don't see any of this happening any time soon, so there will be a perpetual supply of new websites containing well-known vulnerabilities. Forever. This will never, ever stop.
4) Security testing becomes a norm and there will be easy to use tools/services. Regulation doesn't help here. Everyone makes mistakes, the better developers just make less.
There is no reason not to have these tools if you have so many easy to use ones available for intrusion.
I happen to have known a local startup that was working on such a service: intrusion/security testing SaaS. Their model was something like giving a simple dashboard/report that the management could easily understand and act on if needed. They also thought about having a badge that the verified sites could display, as a proof towards their users that they are secure. Unfortunately they, and their VC, screwed it up big time.
I have my doubts. Think about lock design - it's been known for a long time how to design decent locks, and yet in the US we still use these crappy cylinder locks.
Read up on Medeco. An expert lock smith might be able to pick it in his career, once. That's an $80 lock. Now look at Kwikset from HomeDepot for $11. An amateur can pick that lock in 2 seconds flat.
In short, the Medeco lock basically has every deterrent you can put into a lock that the industry knows about. Medeco to Kwikset is like a major payment processor's portal to a Wordpress site with a shopping cart plugin for seeing specialty cat themed oven mitts. You get what you pay for if you high someone that knows what they're doing.
You sound like a true believer in DRM. Just like with DRM, a lock doesn't provide all that much security because all of the information necessary to break it is encoded in the lock.
> As of 2008, several new methods of cracking Medeco locks has been developed by Mark Tobais and Tobias Bluzmanis and were presented at the DEF CON 2008 and HOPE 2008. A simultaneous public release of a book detailing many of the exploits, called "Open in Thirty Seconds" detailed many of the attacks discovered.
> They further detailed the ability to bump current generation Medeco M3 locks.
> Many Medeco dealers continue to make claims about the Bump and Pick proof nature of their locks, however Medeco has retracted virtually all of its own press indicating such claims.
Furthermore, this particular piece of rhetoric:
> An expert lock smith might be able to pick it in his career, once.
makes no sense. Picking a style of lock once makes the next time easier, not harder.
>Furthermore, this particular piece of rhetoric:
>> An expert lock smith might be able to pick it in his career, once.
Easy getting down off your high horse. It might blow your socks off, but I've read that Wikipedia article before. I've actually gone through the whole DEFCON presentation and paper too, where you'll see which locks have the bump mod since 2008. ;) Yet, given that I'm not concerned about the CIA or NSA sneaking in to spike my cookie jar with LSD, I'll stick with my Medeco lock, including the bump mod, to make it a little more difficult to waltz into my warehouse. If you want in, you'll have to take the door or wall down, which is the point of a quality lock.
Web developers are making these errors because of the high demand for cheap web devs churned out of "learn to code!" bootcamps coupled with the fact that the people writing the checks don't understand security.
Also, while basic SQL injection issues are "fixed" if you are an experienced dev, CVEs about SQI in libraries meant to protect you from SQI are common. No doubt there are lots of zero day SQI exploits for every SQL library out there.
>Web developers are making these errors because of the high demand for cheap web devs churned out of "learn to code!" bootcamps coupled with the fact that the people writing the checks don't understand security.
Cheap developers with no senior oversight and code review? No [automated] security testing to catch the basics?
You're getting what you deserve if this is the only level of talent and organization you want to put on task.
Honestly, I find it's bad tools. Every database lib I've worked with tried to bully you into using prepared/compiled queries or full ORM queries, but occasionally you still have to break out and smash strings together to build queries.
And when that happens? You can't help but notice that nobody provides you with a simple "EscapeSql" function you can use, so I always have to roll my own (or do horrible things with dynamically constructing the parametrized query and the parameter array in parralel).
I wouldn't be surprised if many developers just throw up their hands and skip sanitizing.
Same with XSS, although not as serious it's staggeringly common.