Overview
SQL Injection (SQLi) allows an attacker to directly interact with queries made by a web application, and thus, have some control of what the database outputs. This is typically data that a typical user should not have access to. For example, usernames and passwords (hopefully, passwords hashes). Furthermore, an attacker, depending on the severity of the vulnerability could modify this data, and may even cause persistent change to the database and its contents. This may lead to reputational damage within a company and a lack of trust from the companies' user base.
Two types of injections (of many)
Unfortunately (or fortunately for ethical hackers), there are numerous ways to exploit an SQLi vulnerability within an application. Learning web application security is a challenging, and at times, extremely painful to comprehend. Sometimes, I sit at my desk and realise more so than ever that I know nothing. However, documenting my learning within this area may hope to solidify what I am learning.
- Retrieving hidden data: This type of injection allows an attacker to craft a query in which more data is returned than allowed for within the application.
Consider the following example:
A website hosts different types of products, with different categories.
https://vulnerable.com/products?category=Shoes
The application will then select all products from the database where relevant. The query would look something such as this:
SELECT * FROM products WHERE category = 'Shoes' AND display = 1;The display tells the database to output products which have display set to 1. This is the vulnerable parameter to attack. By removing this parameter, the attacker can force the database to all products within the category of Shoes - even hidden ones. This is accomplished by crafting an SQL query like so:
SELECT * FROM products WHERE category = 'Shoes' -- AND display = 1The -- tells SQL to comment the rest of the query. It is not interpreted by the database as valid SQL. Therefore, all products are returned to the attacker.
- Subverting application logic: Comments within SQL provides a great transition into learning about this type of vulnerability.
Consider the following example:
A web application allows users to log into their account. How does this work? A database server must hold the credentials for each user, and every time a user wants to login, the database checks whether their credentials are valid via an SQL query.
SELECT * FROM users WHERE username = 'elliot' AND password = 'mrrobot2015';If the details of the user are returned, the query was successful. However, the lack of prepared statements, and how user input is not sanitised allows comments to be used here again. By using a comment, an attacker can essentially 'remove' the password element of the query and simply login, providing that the username is valid. For example:
SELECT * FROM users WHERE username = 'elliot--' AND password = '';The user elliot does exist, and so, an attacker can login without a password.
Conclusion
These are two types of many SQL Injections. These are quite simple, but are quite severe. This is why all user input is dangerous. Prepared statements should be used to ensure that user input is interpreted as valid SQL syntax. Prepared statements work in databases such as MySQL and help to protect against these type of attacks. Read more about them here.
