Understanding the risk SQL injection vulnerabilities pose
SQL injection vulnerabilities put a system at risk and are often unknown to users. Discover how this web vulnerability works and how to prevent it with expert Kevin Beaver.
What's your situation with regard to web application SQL injection? Are you testing for it from all the right angles?
Many people have discovered SQL injection vulnerabilities in their environments and are doing something about it, while others are unaware that they even exist. Still others have a false sense of security because their vulnerability scanners are finding some injection vulnerabilities.
Whatever your situation is, SQL injection is arguably the worst of all the web vulnerabilities. It not only exposes sensitive records in your databases, but it also exposes your business to some sizable risks if the issues aren't mitigated.
Security studies continue to show that SQL injection is not only a top web vulnerability, but it's a top cause of data breaches. I see it in a lot of my work, as well. Out of every 10 or so applications that I test, I find SQL injection vulnerabilities in two or three of them. That doesn't seem like a lot, but when it's a numbers game and time is on the side of the bad guys, the odds are certainly not in your favor.
I've also seen SQL injection vulnerabilities on everything from core, internet-facing business applications to the internal web interface of a voice over IP call management system. Essentially, if an application is complex enough to have a database component, then it's fair game for attack. Everything from IoT devices to content management systems to enterprise ERP systems can suffer from SQL injection vulnerabilities.
SQL injection vulnerabilities are usually caused by one of the following three problems:
a lack of secure development practices, such as input validation and using stored procedures;
a lack of prioritization to resolve the issues on the part of management or simply because technical staff has not communicated the business risks of SQL injection vulnerabilities.
Unlike other vulnerabilities, SQL injection is a bad sign pretty much wherever it exists. Without analyzing the context or criticality of the vulnerable systems where SQL injection vulnerabilities exist, you can almost guarantee that something bad will come from it.
This is true for even the most seemingly benign applications; not just because database records can be directly accessed or that the database could be deleted, but because SQL injection vulnerabilities can enable full remote access and control of an affected system. This could, in turn, enable an attacker to gain a foothold on that network segment and further exploit the environment.
Figure A. The Netsparker web vulnerability scanner can find and demonstrate exploits of SQL injection vulnerabilities.
The most important part of dealing with a SQL injection is acknowledging it. This requires well-planned and well-executed vulnerability and penetration testing and good tools. Figure A shows how the Netsparker web vulnerability scanner can find and demonstrate SQL injection vulnerabilities.
Figure B shows how Acunetix Web Vulnerability Scanner uncovered various pages and parameters with SQL injection vulnerabilities.
There are many other commercial web vulnerability scanners and source code analyzers that can uncover SQL injection vulnerabilities. I have found that, by and large, you get what you pay for in terms of tools that identify this type of vulnerability.
Figure B. The Acunetix Web Vulnerability Scanner can detect the details of vulnerable pages.
Furthermore, you absolutely must use multiple web vulnerability scanners and, if source code is on the table, you should use multiple analyzers in that context, as well. With near 100% certainty, no single scanner will uncover everything that you need to see, including SQL injection vulnerabilities. In addition, if you have found or even suspect a SQL injection and you're looking for a way to exploit it for testing purposes, there are some freebies, such as SQL Power Injector, sqlmap and the Firefox web browser add-on SQL Inject Me.
Regardless of your tools, you should test your systems as an untrusted outsider and as an authenticated user. SQL injection vulnerabilities can be exploited by a trusted but malicious user or by a criminal attacker who has stolen a legitimate user's login credentials.
Knowing what we now know, why is SQL injection still so prevalent in web applications? Don't we already have enough knowledge? Shouldn't the OWASP Top 10 be enough to educate developers, QA professionals and IT/security staff on what not to do and what to look out for?
The OWASP Top 10 is a great resource. In fact, I think it's one of the least utilized resources in the context of application security that can provide so much value all along the software development lifecycle. That said, looking at information security at a higher level, we also have the NIST standards, ISO/IEC 2700X frameworks and the like, but information security programs still suffer.
In addition to knowledge, users need the discipline to find flaws, such as SQL injection, and fix them before they're used against the enterprise.
Security studies continue to show that SQL injection is not only a top web vulnerability, but it's a top cause of data breaches.
What's important in the end is that all the web systems, starting with the external environment and then on to internal systems, need to be tested and vetted for SQL injection vulnerabilities. You absolutely cannot secure the things that you don't acknowledge.
If SQL injection is off your radar, how are you going to know that it's even an issue? The reality is that you won't until someone else finds it and exploits it. Only then will you have the opportunity to address the issue, but remediation under duress is never a good plan. Be proactive, and if you're not in charge of web application development or security testing, then ask the people who are to see what they are doing to minimize this risk.
If you're outsourcing your web application development and hosting, never, ever trust that the vendor is developing secure code or doing all of the necessary things to minimize the risk of a SQL injection exploit.
Case in point, I recently worked with a client that had their marketing website updated by, of all things, a marketing company. When I tested the website, I uncovered SQL injection vulnerabilities that the marketing company not only didn't know about, but that they also couldn't resolve. My client found another vendor and, if presented with this situation, you should as well.
The important thing is that you should never let your guard down. Given the number and complexity of your web applications combined with what there is to lose, you have to address this issue now, as well as periodically and consistently moving forward. Relentless incrementalism is key. You're not going to prevent all SQL injection vulnerabilities, but you can do what's reasonable and what's right to find and resolve them quickly.
