SQL injection remains a successful way of attacking web applications for a pretty simple reason: “If it ain’t broke, don’t fix it.”
Many organisations sit on top of dozens or hundreds or even thousands of applications and the majority are in a maintenance mode or minimal changes. Most have not been hacked, yet. But every single website of any significance probably has some code that is years old, whether it be first-generation code, a third-party library, an open-source framework and so on.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Chasing unknown bugs in the code costs money and, if there is no urgency because of a known problem, the application stays as it is. Every change carries risk, which is the ultimate caution of “if it ain’t broke, don’t fix it.” Unfortunately, much of the code is broken. They just do not know how and they don’t know where.
Although organisations may not spend money and time checking all their applications, hackers will pursue injection vulnerabilities aggressively because the impact is so significant (modifying data, unauthorised login, exfiltrating data, etc.). The attributes of great programmers – including hackers – are laziness, impatience and hubris. Thus, great programmers have created many automated tools in recent years to find and exploit these vulnerabilities.
This attention gap between attackers and defenders is another reason why SQL injection will continue to succeed until the applications are fixed.
As an organisation maintaining a portfolio of applications, or even as the developer of a single site, there is a temptation to use testing to find the problems that need fixing. Even worse, there is a tendency to look at a clean bill of health from a series of tests and use that to assert that there are no problems.
To paraphrase E.W. Dijkstra: “Testing can prove the presence of bugs, but never their absence.” The application must use techniques that are resistant to SQL injection. The right answer is a combination of source code analysis, modern frameworks that use databases safely and operational controls.
The short answer on SQL injection is that we have not systematically rooted out all the bad code yet. The fact that nothing bad has happened yet is often used as a justification to avoid potentially risky modifications and as a foil for security doomsayers.
The problem will go away slowly – through panicked responses to hacking, gradual retirement of legacy systems or actually fixing our applications’ source code.
Paco Hope is a member of (ISC)² Application Security Advisory Board and principal consultant at Cigital.
Read more from the Security Think Tank about SQL injection attacks
- Security Think Tank: Development and testing key to reducing SQLi attacks
- Security Think Tank: Quick time to market to blame for many SQLi attacks