SQL Injection

SQL injections

SQL injections are one of the most common (web) vulnerabilities. All SQL injections exercises, found here, use MySQL for back-end. SQL injections come from a lack of encoding/escaping of user-controlled input when included in SQL queries.

Depending on how the information gets added in the query, you will need different things to break the syntax. There are three different ways to echo information in a SQL statement:

• Using quotes: single quote or double quote.

• Using back-ticks.

• Directly.

The way information is echoed back, and even what separator is used, will decide the detection technique to use. However, you don't have this information, and you will need to try to guess it. You will need to formulate hypotheses and try to verify them. That's why spending time poking around with these examples is so important.

In this challenge, you will need to bypass the login page using SQL injection. The SQL query looks something like:

SELECT * FROM user WHERE login='[USER]' and password='[PASSWORD]';

Where: [USER] and [PASSWORD] are the values you submitted.

The logic behind the authentication is:

• if the query returns at least one result, you're in

• if the query returns no result, you have not provided a valid username and password.

Our goal is to make the query return at least one result. To do so we are going to inject a condition that is always true: 1=1. To do that, we are going to:

• Break outside of the single quote to be able to inject SQL using a single quote.

• Add a OR keyword to make sure the comparison is always true.

• Add our always true comparison: 1=1

• Comment out the remaining query using -- (the space at the end matters) or #.

If we put everything together, we get our payload.

We saw that SQL string can use single quote or double quote. Let's adapt our payload from the previous challenge to work with this one.

The developer checked that only one result is return by the database. You should be able to bypass this check by using the keyword LIMIT.

' or 1 = 1 LIMIT 1 -- -

In this example, the error message gives away the protection created by the developer: NO SPACE. This error message appears as soon as a space is injected inside the request. It prevents us from using the ' or '1'='1 method, or any fingerprinting that uses the space character. However, this filtering is easily bypassed, using tabulation (HT or \t). You will need to use encoding, to use it inside the HTTP request. Using this simple bypass, you should be able to see how to detect this vulnerability.

username=admin'||1%3d1%23&password=admin'||1%3d1%23 #use if tab is also blocked

This example was first published in 2006 on Chris Shiflett's Blog as a way to bypass addslashes. It relies on the way MySQL will perform escaping. It will depend on the charset used by the connection. If the database driver is not aware of the charset used it will not perform the right escaping and create an exploitable situation. This exploit relies on the usage of GBK. GBK is a character set for simplified Chinese. Using the fact that the database driver and the database don't "talk" the same charset, it's possible to generate a single quote and break out of the SQL syntax to inject a payload.

Using the string \xBF' (URL-encoded as %bf%27), it's possible to get a single quote that will not get escaped properly. It's therefore possible to inject an always-true condition using

%bf%27 or 1=1 --

and bypass the authentication.

As a side note, this issue can be remediated by setting up the connection encoding to 'GBK' instead of using an SQL query (which is the source of this issue). Here the problem comes from the execution of the following query:

 SET CHARACTER SET 'GBK';

It is a pretty unlikely issue for a web application but it's always good to know that it exists, especially if you play CTFs.