It is disturbing to know how many web applications simply forgo any sort of strong type enforcement on arguments and variables supplied directly to SQL as raw strings, simply because developers "don't like" or rather can be bothered with the wrestling matches needed, when explaining to non-technical people, the reason why it will take so long to add new features to an already expensive investment of development effort.
Many people out there just simply don't feel like writing prepared statements, entity classes for domain specific problems, or pushing past SQL query strings, and treating a data access layer as more than a scriptable text-based input vector to a glorified command line tool.
For as long as there are SQL databases, so too, there shall be successful SQL injection attacks.
>simply because developers "don't like" or rather can be bothered with the wrestling matches needed
In all fairness, I'd say it's more like web application security is a huge field (larger than just SQLi) and a developer typically has their hands full wrestling the technologies they use on a daily basis.
I am the most senior developer here in a team of 6 and we all know just the most basic facts about SQLi (use stored procedures), XSS (use sanitizing libraries) and it ends right at CRSF. Of the OWASP top 10, we have an eye on the top 4 and I wouldn't wager a high bet we have them nailed down.
It feels bad, but considering the resources we'd need to pour into getting one of our better devs trained in all the facets of web app security, it's unlikely to change any time soon.
>It feels bad, but considering the resources we'd need to pour into getting one of our better devs trained in all the facets of web app security, it's unlikely to change any time soon.
Consider the resources you'll have to expend in the event of compromise and compare. While this analysis doesn't always prove the slower but more secure approach to be cheaper, it usually does. Unfortunately, you usually can't get the people holding the purse strings to accept the trade until they've been bitten.
The last time I wrote a longish mail why we should at least pour _some_ resources into this, my superior (who straddles technical and managerial role and is responsible for budget oversight) answered:
"Thanks for bringing this topic up, Mr. iSnow.
Looking at it pragmatically, we have no real use-case for that right now, so I don't think it's the right time to dive into it. I will, however, keep it in mind and would ask the team to collect information on this and keep an eye on the subject".
And of course, without dedicated time and budget for such a large area, developers can either cheat and hide learning it between feature requests or don't do anything about it. So, I am totally not surprised things like the VTech break-in happen all the time, I just don't think it's fair to blame developer's inertia for it.
Many people out there just simply don't feel like writing prepared statements, entity classes for domain specific problems, or pushing past SQL query strings, and treating a data access layer as more than a scriptable text-based input vector to a glorified command line tool.
For as long as there are SQL databases, so too, there shall be successful SQL injection attacks.