SQL injection: The bug that seemingly can’t be squashed

If you’re in a hands-on cybersecurity role that requires some familiarity with code, chances are good that you’ve had to think about SQL injection over and over (and over) again.

It’s a common vulnerability that – despite being easily remedied – continues to plague our software and, if left undetected before deployment, provides a small window of opportunity to would-be attackers.

December 2020 marked SQL injection’s 22nd birthday (of sorts). Despite this vulnerability being old enough to drink, we’re still letting it get the better of us instead of squashing it for good. In August this year, Freepik Company disclosed that they had fallen victim to an SQL injection blunder that compromised the accounts of 8.3 million users.

While a number of them utilized third-party logins (e.g., Google, Facebook), a few million had unencrypted passwords exposed along with their username. Sadly for them and many others along the way, the fallout from these incidents is a huge headache, and rebuilding trust with the user base is a long-term process.

While we “celebrate” this milestone of what is considered a legacy issue, let’s dissect it for a moment. Why does it keep popping up, why is it still so dangerous that it hasn’t moved out of the top spot on the OWASP Top 10 Web Application Security Risks for years, and why does its relatively simple fix not make it into the general benchmark standards for software development?

Why is SQL injection still relevant in 2021?

A quick glance at a recent high-profile breach, 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 capabilities specifically to target and attack FireEye. They are highly trained in operational security and executed with discipline and focus… they used a novel combination of techniques not witnessed by us or our partners in the past.”

But while FireEye is among the most renowned cybersecurity companies on earth and a successful attack took mastermind-level crooks throwing everything they had in a coordinated, large-scale execution, for many “average” companies a lucrative data breach might be possible by exploiting a simple bug, rather quickly, with absolutely no mastermind needed. SQL injection is such a bug, still being leveraged by script kiddies looking to make a quick buck on the dark web.

In May 2020, a man was charged with credit card trafficking and hacking offenses after having been found with digital media storing hundreds of thousands of active credit card numbers. He harvested them all using SQL injection techniques, in an operation that compromised many companies and millions of their customers.

As an industry, we are improving all the time, but SQL injection is still a significant threat and affects far more than just legacy or unpatched systems.

Why developers are keeping it alive (and why it’s not their fault)

We keep saying that SQL injection is simple to fix and that code should be written so as to not introduce it at all. Like most things, it’s only easy when you’ve been taught how to do it right.

This is where the wheel starts to wobble in the software development process. Developers are making the same mistakes, leading to recurring vulnerabilities like SQL injection infiltrating a codebase.

This shouldn’t come as a surprise: most engineers complete their degree without having learned much about secure coding (if anything at all). Most on-the-job training is inadequate, especially in an environment where security is not seen as a business priority in their role.

We’re not giving developers a reason to care about security, nor a strong platform to start becoming more security-aware. Poor coding patterns are keeping bugs like SQL injection alive, and we need to place more emphasis on developer security awareness as well as give them the time to write a higher standard of secure, quality code. Secure coding patterns can take longer to write, but the time spent there creates efficiencies that are invaluable later in the process.

Will there ever be a SQL injection funeral?

A funeral metaphor is a little morbid, but really, our sensitive data would be safer if SQL injection was laid to rest for good. Unfortunately, I’m very confident that we will celebrate a few more birthdays before it gets to that, because the culture around preventative security and emphasis on secure coding simply hasn’t evolved enough to start nailing the coffin shut.

Newer, more security-robust languages like Rust are helping to eradicate some of the bugs we’ve dealt with for a long time by utilizing safer functions, but there is an enormous number of legacy software, older systems, and libraries that will continue to stay in use and be potentially vulnerable.

The shared responsibility for security in the development process (hello DevSecOps) will be crucial if we want to see “easy” exploits shut down for good. Developers must be brought on the journey from the beginning, and supported to take responsibility for their part in creating safer, better code.