Now in this post I will discuss how to find SQL injection vulnerabilities. Imagine you’ve been given an application and asked to test it. How would you go about testing the application to see if it’s vulnerable to any SQL injection vulnerabilities?
Before we cover that, it’s worth mentioning that the methodology used for finding SQL injection vulnerabilities different from one person to another person, and it’s usually developed by experienced. So just because I give you my methodology doesn’t mean that you have to follow it to the letter, instead I would recommend that you take what is useful for you from it and then build an add-on to your own methodology as you gain more and more experience in pentesting web applications. That statement applies for finding all the vulnerabilities, not just SQL injection vulnerabilities.
Finding SQL injection vulnerabilities
I have decided to split this into 2 categories, depending on the perspective of testing. The two categories are Black Box testing and White Box testing.
Black Box web application pentesting is when the tester is given little to no information about the system. Usually the only information that the tester has access to is the URL out the application and the scope of the engagement. This is similar to mimicking and external attacker that is trying to attack your system. The attacker usually doesn’t know anything about the application other than the main URL of the application.
White Box web application pentesting it’s the complete opposite. The tester would be given complete access to the system, including access to the source code of the application.
How to test applications from a Black Box perspective
The first thing that I do when testing an application is not the application. What that means is:
- I literally visit the URL of the application,
- I walk through all the pages that are accessible to me within the user contacts that I’m running as,
- I make note of all the input vectors that potentially talk to the back-end and understand how the application functions,
- I tried to figure out the illogic of the application,
- I tried to find subdomains in the application
- I enumerate directories and pages that might not be directly visible to me through the application, and so on…
While I do all of that, I have my proxy listening silently and intercepting all the requests that I’m making to the application. Mapping the application is such an underrated step when it comes to pentesting applications, although I would argue it’s probably the most important step. The reason I say that is because I usually see beginners in this field get way too excited about the fact that they’re testing an application, and then the first thing that they do is start throwing potentially malicious input vectors into the application to see if the application response in an unusual way. Although this is a valid way of testing an application, it doesn’t make you any different from an automated tool, so this is exactly what web application vulnerability scanner is doing. They call the application they locate all the input vectors, and then they throw a ton of malicious payloads at the input vectors and depending on how the application response the scanner locks the behavior as a potential vulnerability. This way of testing usually only discovered the low-hanging vulnerabilities, so if you’re doing exactly what a scanner can already do, then your testing is really not adding any value. Instead of doing that, what I would recommend is you leave that up to the scanners and is that spend quite a bit of time understanding how the application works. Because most of the critical vulnerabilities found in an application are logic flaws that a scanner is not capable of finding on its own, or vulnerabilities are embedded in pages that the scanner can’t crawl.
Once you’ve mapped out the application, and you’ve listed all the input vectors that are potentially included in queries that are interacting with the SQL database, then it’s a matter of fuzzing the application. That’s because we’re looking for SQL injection vulnerabilities, it be fuzzing the application with SQL specific characters. So what that means is, you add special characters in the input vectors and see if the application response in an unusual way.
- Submit SQL-specific characters such as ‘ or ”, and look for errors or other anomalies
Depending on how the application response, you start refining your queries until you achieve your goal. That’s what makes you different from a scanner. Because the scanner just simply throws a bunch of input at the application, and you, as a human being, you’re capable of understanding the output of the SQL injection and so you’re able to refine your SQL injection using multiple requests until you actually achieve your goal.
Errors are really important and really useful because they give you information about how the back-end operates. Sometimes they give you the database that you’re using, they give you the version of the database, sometimes they actually give you the exact query. If they gave you the query then you hit gold because that’s why you don’t have to develop your payload across multiple request, instead you already know what the back-end query is and so you just develop your payload based on that query.
Once I have an error I tried to build my query using multiple request, so I refine my query to see if there are some errors I can get, and I build my query. In certain scenarios, you don’t actually get an error. For example a blind SLQ injection, so you also have to submit boolean conditions such as OR 1 = 1 and OR 1 = 2 and look for differences in the application’s responses. If you can get the application to respond differently when you force a true use versus when you force a false use case, that means it’s vulnerable to boolean injection.
After that I do the same thing as boolean injection instead it would be to trigger time delays in the application and then see if there’s a difference in the time it takes to respond. So if you input a function that causes a time delay, that means that the application is vulnerable to time-based SQL injection.
Last but not least, I also submit OAST payloads that I designed to trigger a network interaction with a server that I control. If I get that network contraction whether it’s a DNS lookup or it’s done through HTTP that means that the application is vulnerable to out-of-band SQL injection and if I don’t get them that means it’s not vulnerable to out-of-band SQL injection.
