Nearly every application relies on some type of data store, whether it’s a user database or a database of information related to the website. Without proper sanitation of inputs, these stores can be vulnerable to SQL injections, and attackers may be able to retrieve critical information with our permission. If you don’t have an understanding on the SQL language, I highly recommend reading some basic tutorials and learning the fundamentals of the language.
Attacking Login Sequences
Let’s take the following SQL query used at a login page as an example:
SELECT * FROM users WHERE username = ‘testUser’ AND password = ‘testPassword’
There are a couple things we can try here. Assuming that there is no input validation, we can try injecting the username admin’– into the username. This results in the following query:
SELECT * FROM users WHERE username = ‘admin’–’ AND password = ‘’
The comment sequence (–) results in the remainder of the query to be ignored, so the executed query is:
SELECT * FROM users WHERE username = ‘admin’
We can also try injecting the username ‘ or 1=1 –. This causes the application to execute the following query:
SELECT * FROM users WHERE username = ‘’ or 1=1 –’ AND password = ‘test’
And similar to the previous example, due to the comment symbol, this results in the following query:
SELECT * FROM users WHERE username = ‘’ or 1=1
This is just one example of how powerful SQL injections can be. SQL injections can be used on search features as well. Use the table below to determine whether or not the search feature is vulnerable to a blind SQL injection attack. The original value should be a query that only returns one result:
Value or 1=1
Value or 1=2
Value and 1=2
|Should return only one result.||Should return all results.||Should return the original result.||Should return no results.|
Once we know that the feature is vulnerable to a blind SQL injection, we can then attempt to manipulate the back end database logic using table names and column names. Discovering these names is a technique called fingerprinting the database, and we will cover that in another post.
Again, the information included in these posts is only to be used in a controlled environment with explicit permission from the owner of the application. It is highly illegal to attack any application without permission.