If you have a hands-on cybersecurity role that requires some familiarity with code, chances are you’ve had to think about SQL injection over and over (and over).
It is a common vulnerability that, while easy to fix, continues to plague our software and, if undetected before deployment, gives potential attackers a small window of opportunity.
December 2020 marked the 22nd birthday of SQL Injection (of art). Even though this vulnerability is old enough to drink, we’re still letting it get the upper hand instead of crushing it forever. In August of that year, the Freepik Company announced that they Fell victim a SQL injection bug that compromised the accounts of 8.3 million users.
While some of them used logins from third-party providers (e.g. Google, Facebook), for a few millions unencrypted passwords were disclosed together with their user names. Unfortunately, the aftermath of these incidents is a major headache for them and many others, and rebuilding trust in the user base is a long-term process.
As we “celebrate” this milestone on what is considered a legacy, let’s analyze it for a moment. Why does it keep popping up, why is it still so dangerous that it is not off the top OWASP Top 10 Web Application Security Risks for Years, and Why Does Its Relatively Simple Solution Not Make It Into the general benchmark standards for software development?
Why is SQL injection still relevant in 2021?
A quick look at a recent high profile attack, the devastating cyberattack on FireEye, reveals a high level of sophistication.
In a statement, FireEye CEO Kevin Mandia said:
“The attackers tailored their world-class skills specifically to attack and attack FireEye. They are highly qualified in operational safety and are carried out in a disciplined and focused manner … they have used a novel combination of techniques that we or our partners have not experienced in the past. “
But while FireEye is among the most reputable cybersecurity companies in the world, and a successful attack required the most powerful crooks to plunge everything they had into a coordinated, large-scale execution, a lucrative data breach could be possible for many “average” businesses by engaging in a simple mistake, pretty quick, with no need for a mastermind. SQL injection is one such flaw that is still used by script kiddies looking to make quick money on the dark web.
In May 2020 there was a man calculated with credit card trading and hacking crimes after being found using digital media storing hundreds of thousands of active credit card numbers. He put them all together using SQL injection techniques in an operation that put many companies and millions of their customers at risk.
We’re constantly improving as an industry, but SQL injection is still a major threat and affects more than just legacy or unpatched systems.
Why developers keep it alive (and why it’s not their fault)
We keep saying that SQL injection is easy to fix and that code should be written so that it is not introduced at all. Like most things, it’s only easy once you’ve learned to do it right.
This is where the wheel begins to wobble in the software development process. Developers make the same mistakes that lead to recurring vulnerabilities, such as SQL injection that infiltrates a code base.
This should come as no surprise: most engineers graduate without having learned much (if at all) about safe programming. Most on-the-job training is inadequate, especially in an environment where safety, in its role, is not a business priority.
We don’t give developers a reason to care about security, nor a strong platform to become more security conscious. Bad coding patterns keep bugs like SQL injection alive, and we need to put more emphasis on developers’ security awareness and the time to write a higher standard of safe, quality code. Writing secure coding patterns can take longer, but the time spent there creates efficiency that is invaluable later in the process.
Will there ever be a SQL injection funeral?
A burial metaphor is a little morbid, but really, our sensitive data would be more secure if the SQL injection were finally buried. Unfortunately, I’m very confident that we’ll have a few more birthdays before that happens because the culture of preventive security and the emphasis on secure coding just hasn’t evolved enough to nail the coffin shut.
Newer, more secure languages like Rust help fix some of the bugs we’ve been dealing with for a long time by using more secure features, but there is a tremendous amount of legacy software, older systems, and libraries that still persist will remain in use and be potentially vulnerable.
The shared responsibility for security in the development process (hello DevSecOps) will be crucial if we want to switch off “simple” exploits for good. Developers need to be taken on the journey from the start and supported in taking responsibility for their part in creating safer and better code.