In the article entitled “What is SQL Injection (SQLi) ?“, we explained how such vulnerabilities can be introduced into applications and why they are so serious. In particular, we saw that the “root of all SQLi evil” lies in Dynamic SQL, that is, the programmatic construction of SQL statements piecemeal from static strings combined with untrusted input.
Detecting SQL Injection
It is almost always worth checking an application for SQL Injection (SQLi) vulnerabilities, not only because because such flaws can be very serious, but also because the absence of SQL Injection (SQLi) in one part of the application does not mean there won’t be findings elsewhere.
Whitebox Testing
Although it is not always a luxury that we enjoy, having access to the source code can allow you to rapidly decide whether the application is at risk for SQL Injection (SQLi). Searching for all files that use database library classes and reviewing those files for Dynamic SQL can allow to identify potential flaws or rule them out.
Blackbox Testing
Submitting malicious SQLi payloads to the application may also serve to identify potential SQL Injection (SQLi) vulnerabilities. All parameters and submitted inputs should be checked. If the application does not detect and reject such input, the exploit may be working and additional experimentation is warranted. Consider:
- If the application returns an application error (from the server), it likely demonstrates that input validation is being performed.
- If the application returns a database error, it is likely that sufficient input validation is NOT being performed and the SQL Injection (SQLi) exploit may be working. Additional experimentation is warranted to see what information can be gleaned from the database error messages, how the syntax might be tweaked to achieve exploitation, and to seek behavioral evidence that exploitation is occuring.
Of course you may not be aware of what database product you are working with, and that can be important because you will want to attempt to access vendor/product specific functions and syntax. Determining the product and version of the database underlying an application is called “database fingerprinting” and is accomplished using special “sentinel strings” that will only work in specific environments.
SQL Injection (SQLi) Test Strings
Web-application tools will come pre-loaded with SQL Injection (SQLi) payloads, but it is sometimes useful to have a few at your fingertips for manual testing. Generally, quick detection is the product of generating errors by introducing SQL meta-characters (control characters) into application inputs. Characters and sequences such as {; ‘ ” — ; # } that are not rejected by the application AND that generate database errors or unusual behavior are indicative that SQL Injection may be possible. Some effort is typically required to clearly discern “interesting responses” as false-positives or to tweak them into something exploitable (i.e. a payload that actually does something malicious).
Classic sentinel SQL Injection (SQLi) sentinel payloads include:
- ‘
- ‘ or 1=1; —
- ‘ AND 5=7; —
Rather than re-inventing the wheel, some useful cheat-sheets can be found here, here and here.
Note that application defenses can sometimes be overcome by using character encoding functions instead of the actual meta-characters, such as the char() and ascii(), functions, as well as constructing payloads on the fly using concat().
Automated tools will help explore the “interesting” cases that emerge
Tools such as Burp Suite, OWASP ZAP, and sqlmap can automate large portions of testing activities are indispensable when working with large applications. These tools facilitate the task of providing malicious SQL Injection (SQLi) payloads as inputs to the application, AND in distinguishing interesting results within the set of responses.
For strategies on preventing SQL Injection (SQLi), see the article entitled “How to Prevent SQL Injection (SQLi)“.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.