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
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
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.
.png)
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
