A version of this article originally appeared in Help Net Security. It has been updated and syndicated here.

‍

If you’re in a hands-on cybersecurity role - one 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 knowing its rather simple remedy within a few weeks of the first discovery, continues to plague our software and provide a small window of opportunity to would-be attackers if left undetected before deployment.

December 13, 2020 marked SQL injection’s 22nd birthday, and despite this vulnerability being old enough to drink, we’re 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 a 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 with 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 it hasn’t moved out of the top spot on the OWASP Top 10 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 staggering level of sophistication: it was a highly coordinated, nation-state attack utilizing a wide array of advanced techniques that appeared to be customized for a FireEye heist.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.”

It’s nightmare fuel for any CISO, and if something like this can happen to FireEye, then it puts into perspective how vulnerable many enterprises really are.

… except, it’s even worse news for the average organization. FireEye is one of the most renowned cybersecurity companies on earth, and the successful attack on them took mastermind-level crooks throwing everything they had in a coordinated, large-scale execution. For many companies, a lucrative data breach might be possible by exploiting a simple bug, rather quickly, with absolutely no mastermind needed. And SQL injection is a common example of the latter, 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, when he was 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 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 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. However, 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. I’m very confident that we will celebrate a few more birthdays before it gets to that, however, 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 amount of legacy software, older systems, and libraries that will continue to stay in-use and 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.

How should developers approach fixing a SQL injection bug in their code?

We have put together a comprehensive guide for developers who want to learn how to identify and fix SQL injection. Complete with a gamified challenge in the programming language of their choice (even COBOL!), this provides some great foundational learning that will help every developer create safer, higher quality code.