One of the main aspects of this vulnerability that you must understand is that it leverages an SQL interpreter. An interpreter takes input and acts on it imme- diately without having to go through traditional programming processes such as linking, compiling, debugging, and running. For example, an SQL interpreter plays a key part when you search a new pair of shoes at an online store. This is the code waiting as part of the web application for your search term that you type into a search box:
String query = “SELECT * FROM shoes WHERE shoeName=’” + request.getParam(“term”) + “’”;
When you search for a new pair of Zoomers shoes, the following steps are completed.
1. User enters Zoomers into the search box of the online store and clicks the Search button.
2. The application stores the user’s input into a variable named term (as in “search term” on the web application).
3. The application builds an SQL statement that is made up of some prewrit- ten code and the term variable that is used in the HTTP request.
4. The application sends this well-formed SQL query to the database where it is executed by the SQL interpreter.
The SQL query’s simplified syntax that is executed when searching for Zoomers shoes:
String query = “SELECT * FROM shoes WHERE shoeName=’Zoomers’”;
Pretty basic SQL here. We are simply selecting all (*) the columns (ID number, shoeName, shoePrice) from the shoes table for any record that has Zoomers in the shoeName column. The results would return a dataset similar to what is introduced in Table 4.1.
■ The entire query is treated as one string variable (named query) that is passed
to the interpreter; this is why a double quote is present before the SELECT and at the very end of the query before the terminating semicolon.
■ The user-supplied search term is gathered by the request.getParam function
and stored inside the single quotes as a string variable. This makes sense, as shoeName is surely a text-based value. The first single quote is right after shoeName= and the second single quote is right before the last double quote. This is the actual SQL query that is executed by the interpreter.
SELECT * FROM shoes WHERE shoeName=’Zoomers’
SQL for Hackers
As an attacker, it is critical to gain an understanding on how this query is con- structed and what exact parts of the query you are in control of. The query is broken out into three distinct parts.
1. SELECT * FROM shoes WHERE shoeName=’ This chunk of code is prewritten by a human programmer and waiting in the application for the user’s input.
2. The term variable (Zoomers) is appended onto the first chunk of code. The user is in complete control of this variable.
3. ‘ This single quote is then appended by the program directly after the user’s input to complete the SQL statement so that it is valid syntax to be executed by the SQL interpreter.
A hacker can craft malicious input instead of a shoe name in the search box to exploit this SQL injection vulnerability while still balancing the quotes so the statement doesn’t throw an error. The classic example of this exploit is to enter the following input into the search box.
Zoomers’ OR 1=1 #
Sample SQL Results for Shoe Search ID Number shoeName shoePrice
1001 Grands 89.99
1002 Squatchs 74.99
1003 Possums 69.99
1004 Zoomers 133.37
This would build the following SQL statement sent to the interpreter for execution.
SELECT * FROM shoes WHERE shoeName=’Zoomers’ OR 1=1 #’
The # (pound sign) after the 1=1 clause is an inline comment and the interpreter will ignore everything that follows it. Inline comments may also use /*comment here*/ or -- (double dash) instead of a pound sign depending on the database that you’re working with. For DVWA using MySQL, the pound sign is the correct inline comment indicator. The resulting SQL statement of this code injection is:
SELECT * FROM shoes WHERE shoeName=’Zoomers’ OR 1=1
Take a look at the quotes; they are balanced beautifully! The injected single quote after Zoomers balances the first single quote that was prebuilt by the appli- cation. The single quote that is appended to the end of the user’s input by the application has been ignored because of the inline comment. Not only will the Zoomers shoes be retrieved, but also every other shoe because 1=1 is always true. You can also inject a string input and use the hanging quote against itself by searching for this:
Zoomers’ OR ‘a’=’a
We know exactly where the single quotes will be added, so the resulting SQL statement for this injection will also always be true:
SELECT * FROM shoes WHERE shoeName=’Zoomers’ OR ‘a’=’a’
SQL INJECTION ATTACKS
Now that we have the basics of SQL injection down, let’s use our DVWA environ- ment to try it out on a vulnerable page. We have a couple of goals for this section:
1. Crash the application to prove that our input dictates the application’s behavior.
2. Retrieve usernames from the database for a targeted attack to bypass authentication.
3. Extract out useful information from the database (we will be gathering pass- word hashes).
4. Crack the password hashes so we know the username and password of each of the application users.
The DVWA exercise that we’ll be working through for this vulnerability is SQL Injection, which can be accessed by clicking on the link in the menu on the left side of DVWA once you’ve logged in with the admin | password credentials as shown in Figure 4.1.