What are SQL Injections/Injection Flaws?
Injection Flaws allow attackers to run a malicious command or block of malicious code on the back-end (the database) of a targeted web based application. For example, an attacker may send instructions to a vulnerable back-end database via an SQL command to manipulate the functionality of an application or to steal data. These injected database instructions (hints the name SQL Injections) can be implemented by various methods.
Implementing Injection Flaw/SQL Injection Attacks
Injection Flaw attacks are implemented via input fields within web applications. In the case of a SQL Injection attack, a line of SQL code is passed to the database to produce an unintended outcome when using a query box in a website.
For example, say you’re on a retail website and have forgot the password to your account.
When you enter your email address to retrieve your password, the string is passed to the back-end database of the website as a query, possibly looking something like this:
“SELECT * FROM users WHERE email LIKE ‘Shane@Risk3Sixty.com’;”
This would return all records from the table that relate to your search terms “Shane@Risk3Sixty.com” and prompting the web-app to shoot off an email to you so that you can reset your password..
If the web-app is not properly hardened, an attacker might “inject” extra code, allowing for the possibility to pass on potentially harmful commands to the database. For example, say the attacker typed into the search box: Shane@Risk3Sixty.com OR ‘X’ = ‘X
Notice above how I left off the closing quotation mark ( ‘ ) after X, which I assume will be closed by the web-app as is parses my search. I have now passed a statement that will be TRUE no matter what in the eyes of the database because I’m searching for anything that equals my email address OR where X = X :
“SELECT * FROM users WHERE description LIKE ‘Shane@Risk3Sixty.com or ‘X’ = ‘X‘;”
If the web-app is not properly configured to “sanitize” user inputs, we might be greeted with an error message that gives us clues about whether or not the web-app is properly configured to handle the malicious search string.
This website wasn’t fooled and didn’t offer up any info.
Poorly designed web-apps may be poorly coded and allow us to actually run code to replace one email with another. This may be handy if you were trying to access another person’s account.
For example, say I wanted to hack into my co-author Christian’s account and order some swanky merchandise using the stored credit card info he has on file with an online merchant with a poorly coded web-app. Maybe I could also pass some code to update a table as well, guessing that the email field in the table is simply named ’email’:
Shane@Risk3Sixty.com OR ‘X’ = ‘X’; UPDATE table SET email = ‘Shane@Risk4Sixty.com’ where email = ‘Christian@Risk3Sixty.com
Which results in the following query being passed to the database:
“SELECT * FROM users WHERE description LIKE ‘Shane@Risk3Sixty.com OR ‘X’ = ‘X’; UPDATE table SET email = ‘Shane@Risk3Sixty.com’ WHERE email = ‘Christian@Risk3Sixty.com‘;
You’ll notice I updated the table to replace Christian’s email address with my own. Now I may simply use the web-app utility to reset my password and Voila! I can log into his account using my email address.
Testing for SQL Injection Vulnerabilities
The Open Web Application Security Project (OWASP) provides some solid guidance on testing for SQL Injection vulnerabilities in web apps. We will add a synopsis of their guide below.
1. Understand where the application interacts with the Database Server. The points of interaction include:
- Authentication forms- login pages and places where credentials are entered.
- Search Features- passes strings of text along to a database.
- E-commerce Sites- search features found on the websites of online merchants.
2. Try adding semicolons or a single quote to the end of inputs in forms. Single quotes and semicolons are used as string terminators in SQL and if not properly filtered/sanitized by the web-app, should return an error which provides valuable clues to an attacker on how to next try and exploit the database.
3. If an error is returned, the attacker will next try to determine which database they are dealing with (e.g. MS SQL Server, Oracle, MySQL). These determine the syntax and other known behaviors related to the type of database being used.
4. Next, the attacker might try a variety of exploitation including:
- Union Exploitation: uses the SQL UNION operator to join queries together and potentially learn more about the structure of the database.
- Boolean Exploitation: asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.
- Error Based Exploitation: forces the database to perform some operation that will result in an error, with the goal being to extract data about the database.
- Stored Procedure Exploitation: Passing malicious code into a Stored Procedure much in the same fashion you would a traditional SQL injection attack.
There are other types of injection attacks. Read more about them along with coding examples over at the OWASP page on the topic.
What Prevention Strategies are in Place?
According to the OWASP, the simplest way to avoid against injection attacks is to avoid using external interpreters when possible. An interpreter is a program that processes or parses blocks of code in various programming languages (e.g. Perl, Python, Ruby).
The next step is being sure that calls to back-end databases are properly validated and sanitized.
Finally, be sure that web applications run with the least amount of privileges necessary to perform its function.
This post is meant to give the IT auditor or IT manager a starting point for understanding SQL Injection/Injection Flaw attacks and assist with formulating the correct questions to ask when auditing or working with penetration testers and software/web developers and engineers. Please feel free to add more in the comments below and we will keep compiling the list!
Note: We kicked this Pen Testing series off with a discussion on Cross Site Scripting (XSS) a few weeks back. Check it out.