If you’ve been around application security for any length of time, then you have no doubt heard of the OWASP Top 10. The OWASP Top 10 was started in 2010 and it was updated in 2013 and 2017. Today, it is widely considered the de-facto standard listing of the most common vulnerability types that application developers and web application security professionals need to be aware of. In fact, it has become such a standard that there are now specialized OWASP Top 10 lists that specifically address APIs and IOT, as well.
In this periodic blog series, we will take a look at the most pervasive vulnerabilities in the OWASP Top 10. In this particular article, we will examine SQL Injection, the most prevalent type of OWASP Top 10 vulnerability. We will also review how an effective application security program can address this threat.
SQL Injection Defined
According to OWASP, “Injection flaws, such as SQL, NoSQL, OS and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.” Injection is really about taking advantage of a data flow and using it to do things that were unintended. One common example that we have all heard of is doing things like using single quotes in a field on a web page to try and exploit a SQL query.
SQL Injection’s Impact
Our recent Ponemon Institute “Application Security in the DevOps Environment” study found that 67% of responding organizations’ business-critical applications were not continuously tested for vulnerabilities. So, the potential impact of vulnerabilities such as SQL Injection is immense. As such, a recent SecurityBoulevard.com article by author Pallavi Dutta noted that major SQL Injection attacks have impacted organizations in wide-ranging industries such as a British telecommunications company, numerous universities and government agencies and even e-commerce companies.
But Why IS SQL Injection Still A Thing??
The truth is that SQL injection has literally been discussed publicly for decades, so why is this still a problem for so many organizations? The reality is that while preventing SQL injection is not tremendously difficult, the sheer number of places where software is communicating with databases, and using user-supplied input to do it, is massive.
We were reminded of the importance of this in Season 1, Episode 10 of our “Application Paranoia” podcast series, when we asked application security expert and influencer Tanya Janca about one vulnerability that no one should ever write again. Tanya said:
“OK, so my favorite vulnerability that I’m going to fix. I’m going to turn this question on its head. I would have people only write inputs to programs that were fully validated and properly validated… Because if every single programmer put input validation where it was supposed to be and did a good job of the input validation… it would fix such a huge, huge, huge amount of vulnerabilities, it would be out of this world.”
Addressing Injection Attacks
Considering their potential impact, how does HCL AppScan find injections and address them? Well, when scanning applications, we try all kinds of possible configurations and examine the output looking for things that indicate an injection attack is possible. For instance, we look to see what kinds of error messages are given and if these messages inadvertently provide insight into how the applications might work. We try benign injections to see if they “work” and then report on the success of those attempts so that development teams are aware of their existence. And we provide information on the kind of vulnerability found and why it is a problem to aid understanding.
Figure 1: AppScan Scan Configuration Panel
Figure 1 above shows the HCL AppScan Scan Configuration Panel. Here, users are able to customize exactly the kinds of issues they want to test for. In this example, we started by choosing the “Developer Essentials” profile, which consists of many common tests that have a high probability of success, so that developers can get rapid feedback on potential problems. We then searched for the word “Injection” so that we can locate other related tests that may not have been selected and include them. This kind of flexibility allows us to hone our testing.
Once an injection problem is found, how do we address this? In Season 1, Episode 9 of our “Application Paranoia” podcast series, during our “Ask Kris” section, Kris Duer offered some great insight. Here’s the powerful advice that he gave:
“Best practice number 1: use prepared statements. Stop using execute query… Every time I see execute query or execute statement a little part of my soul dies. I don’t even care if there’s no… parameters, make it have it, never use statements. Always use prepared statements. Always use prepared queries.… it’s literally just stop writing queries that concatenate strings. That’s 99.9% of your SQL injection problems.… Stop using dynamic SQL and if it has to be dynamic, use prepared statements”
So to summarize, once vulnerabilities have been identified. then addressing them typically falls into one of two categories:
- Eliminate writing dynamic queries that leverage user–supplied input
- If user–supplied input is utilized, then prevent “bad” SQL from affecting the rest of the query
Addressing these two categories involves using things like parameterized queries, stored procedures, defining lists of acceptable inputs and escaping user–supplied input. As illustrated by Figure 2, HCL AppScan supplies specific information on vulnerabilities that are found, along with using these strategies in potential remediation suggestions. In addition, OWASP supplies a great resource with examples that illustrates how to use these these various methods.
Figure 2: Vulnerability and remediation information
To Learn More
The best way to combat potential SQL Injection attacks is with an effective Application Security Testing program. If you’d like to test-drive Application Security technology for yourself, then register for our 30-day free trial of HCL AppScan.