SQL injections for the little ones
We move on to the technical part of articles about penetration testing. And let’s start, as always, with the external path – with the exploitation of web vulnerabilities. And we will start with SQL injection.
SQL Injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the requests an application makes to its database. Typically, this allows you to view data that it normally cannot get. This can be other users, or any other data that the application itself has access to. In many cases, an attacker can modify or delete this data, causing permanent changes to the content or behavior of the application.
In some situations, an attacker can leverage a SQL injection attack to compromise the underlying server or other back-end infrastructure, or to perform a denial of service attack.
What are the implications of a successful SQL injection attack?
A successful SQL injection attack can lead to unauthorized access to sensitive data such as passwords, credit card information, or users’ personal information. Many high-profile data breaches in recent years have been the result of SQL injection attacks, resulting in reputational damage and regulatory fines. In some cases, an attacker can gain a permanent back door into an organization’s systems, resulting in a long-term threat that can go undetected for an extended period of time.
SQL Injection Examples
There is a wide range of vulnerabilities, attacks, and SQL injection techniques that come up in a variety of situations. Some common examples of SQL injections include:
· Getting hidden data when you can modify the SQL query to return additional results.
· Undermining the application’s logic, where you can change the query to interfere with the application’s logic.
· UNION attacks, when you can get data from different database tables.
· Examine the database when you can get information about the version and structure of the database.
· Blind SQL injection, where the results of a query you control are not returned in application responses.
Extracting hidden data
Consider a shopping application that displays products in various categories. When a user clicks on the Gifts category, their browser requests a URL:
https://uhahatbltv.com/?category=Gifts
This forces the application to execute an SQL query to get information about the relevant products from the database:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
This SQL query asks the database to return:
all data
from the products table where the category is “Gifts” released = 1. Limitation released = 1 used to hide products that are not released. For unreleased products, presumablyreleased = 0
.
https://uhahatbltv.com/products?category=Gifts'--.
The application does not implement protection against SQL injection attacks, so an attacker can build an attack like:
SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1
The result is an SQL query:
The key here is that the sequence of double dashes — is a comment indicator in SQL and means that the rest of the query is interpreted as a comment. This effectively removes the remainder of the query so that it no longer includes AND released = 1. This means that all products are displayed, including those not yet released.
https://uhahatbltv.com/products?category=Gifts'+OR+1=1--.
Going further, an attacker could force an application to display all products in any category, including categories it doesn’t know about:
SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1
The result is a SQL query:
The modified query will return all products where
either the category is Gifts or 1 is equal to 1. Since 1=1 is always true, the query
will return all items.
Undermining the application logic Consider an application that allows users to log in with a username and password. If the user enters a username wiener and passwordbluecheese
the application validates the credentials by executing the following SQL query:
SELECT * FROM users WHERE username="wiener" AND password = 'bluecheese'
If the request returns user data, then the login will succeed. Otherwise, it will be rejected. Here, an attacker can log in as any user without a password by simply using the SQL comment sequence — to remove the password check from the WHERE clause of the query. For example, if you enter the username administrator’–
and an empty password, you get the following request:
SELECT * FROM users WHERE username="administrator"--' AND password = ''
This query returns the user whose username isadministrator
and successfully registers the attacker as this user.
Getting data from other database tables
In cases where the results of a SQL query are returned in application responses, an attacker could exploit a SQL injection vulnerability to retrieve data from other database tables. To do this, the UNION keyword is used, which allows you to execute an additional SELECT query and add its results to the original query.
SELECT name, description FROM products WHERE category = 'Gifts'
For example, if the application executes the following request containing the user input “Gifts”:
' UNION SELECT username, password FROM users--.
then the attacker can send input:
This will force the application to return all usernames and passwords along with product names and descriptions.
Studying the database, well, or determining the version, etc.
After initially identifying a SQL injection vulnerability, it is usually helpful to get some information about the database itself. This information can often pave the way for further exploitation.
SELECT * FROM v$version
You can query the database version information. The way this is done depends on the type of database, so you can determine the type of database by which technique works. For example, in Oracle you can do:
SELECT * FROM information_schema.tables
You can also determine which database tables exist and which columns they contain. For example, for most databases, you can run the following query to get a list of tables:
Blind SQL injection vulnerabilities
Many cases of SQL injection are blind vulnerabilities. This means that the application does not return SQL query results or database error information in its responses. Blind vulnerabilities can still be used to compromise data, but the techniques involved are usually more complex and difficult to implement.
Depending on the nature of the vulnerability and the database being used, the following techniques can be used to exploit blind SQL injection vulnerabilities:
· You can change the query logic to cause a noticeable difference in how your application reacts depending on the truth of one condition. This may include introducing a new condition into some boolean logic, or conditionally firing an error such as a divide by zero.
· You can conditionally cause a time delay in the processing of a request, allowing you to infer the truth of a condition based on the time it takes for your application to respond.
· You can trigger out-of-band networking using the OAST technique. This technique is extremely powerful and works in situations where other techniques fail. Often you can transfer data directly over an out-of-band channel, for example by putting the data in a DNS lookup for a domain you control.
In the following articles, we will analyze each type of SQL injection in detail.
