Happy birthday SQL injection, the bug that can’t be squashed
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.
It's 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.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
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.
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.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
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.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Resources to get you started
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
OWASP Top 10 For LLM Applications: What’s New, Changed, and How to Stay Secure
Stay ahead in securing LLM applications with the latest OWASP Top 10 updates. Discover what's new, what’s changed, and how Secure Code Warrior equips you with up-to-date learning resources to mitigate risks in Generative AI.
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
