SQL injections

In this section, some common SQL injection examples are provided, the first examples are
authentication bypasses where the other ones are more traditional SQL injections.

Example 1
The first example is the most common SQL injection example that you can find. The goal here is
to bypass the authentication page.

This example is the best known way to bypass an authentication page. It's even used in a lot of
comics related to SQL injections. Let's see what happens... The initial query looks like:

SELECT * FROM users WHERE username='[USERNAME]' AND password='[PASSWORD]'

The [USERNAME] and [PASSWORD] are under your control. The application will check that
the [USERNAME] and [PASSWORD] are correct by ensuring that at least one record is returned
by the SQL query. Therefore, the SQL injection needs to ensure that at least one record is
returned even if the [USERNAME] and [PASSWORD] are incorrect.

There are many ways to perform this task. Your best bet is to inject in the [USERNAME] since
the [PASSWORD] may be hashed or encrypted (even if it's not in this example).

First you need to keep in mind the OR operator:

`OR` 0 1
0 0 1
1 1 1
We will use this to make sure the condition is always-true (1). Our goal is to use
the [USERNAME] to inject our always-true condition but first we need to break out of the SQL
syntax using a single quote ':

SELECT * FROM users WHERE username=''' AND password='[PASSWORD]'

The query's syntax is now invalid (since there is an odd number of quotes), but we will come
back to this later. So far our payload is just a single quote', we now need to inject our always-
true condition. The easiest way is to use or 1=1 since 1=1 is true the condition will always
be true. Our query now looks like:

SELECT * FROM users WHERE username='' or 1=1 ' AND password='[PASSWORD]'

The query's syntax is still incorrect. It's the last problem to solve in our injection; we need to get
rid of the end of the query. We can use comments (-- or #) to get rid of it:

SELECT * FROM users WHERE username='' or 1=1 -- ' AND password='[PASSWORD]'

This way MySQL will only see:

SELECT * FROM users WHERE username='' or 1=1 --

Our final payload is ' or 1=1 --. This payload can be optimized to 'or 1# to bypass some
filtering, since MySQL will accept this syntax.
Commenting using `--` can often create problem if `--` is not followed by a space. That's why
it's always a good idea to add a space at the end.
Once the payload is ready, you can just put it in the form and submit. If you directly inject the
payload in the URL, you will need to encode some characters (=, # and spaces). You can
check man ascii or the first "Web For Pentester" for more details on URL-encoding.

Example 2
This example is the same vulnerability with a twist. In the first example, the code only checked
that something was returned. In this version, the developer decided to ensure that only one user
exists.

To bypass this restriction, you can get all the rows with the trick seen above and then limits this
number using the SQL keywords LIMIT.

Example 3
In this example, aware of the risk of SQL injection, the developer decided to block single
quotes ' by removing any single quote ' in the query. However, there is still a way to break out
of the SQL syntax and inject arbitrary SQL.

To do so, you need to think of the query:

SELECT * FROM users WHERE username='[username]' and password='[password]'

The problem here is that you cannot, in theory, break out of the single quotes ', since you
cannot inject any quote. However, if you inject a back-slash \, the second ' in the query (the
one that is supposed to finish the string [username] will be escaped and will be closed by the
third one (the one that is supposed to start the string [password]).

Using that, you can then use the parameter password to complete the query and return an
always true statement. Don't forget to comment out the end of the query to avoid the remaining
SQL code.

Example 4
In this example, the developer puts part of the query directly in a parameter. It's really rare in
traditional web applications but can sometimes be found in web services, especially for mobile
applications. You are injecting directly in the WHERE statement and can manipulate the request
to retrieve anything you want.

Example 5
In this example, you are injecting after the keyword LIMIT. On MySQL, this type of injection can
only be exploited using UNION SELECT... if there is no ORDER BY keywords used in the
query. Furthermore, the ORDER BY keywords need to be located before the LIMIT keyword in
order for the query to be valid. So you cannot get rid of it using comments.
Some methods exist to exploit injections in LIMIT with ORDER BY using the INTO
OUTFILE or PROCEDURE ANALYSE() but they are a bit too complex to be covered here.

If there is an `ORDER BY` keyword, you can try to remove the corresponding parameter from
the HTTP request to see if it allows you to get rid of the statement in the query.
You can simply use union-based exploitation to retrieve arbitrary information in this example. A
full example of this type of exploitation is available in the PentesterLab's exercise: "From SQL
injection to Shell".

Example 6
This is another example of SQL injection, but this time after the GROUP BY keywords, union-
based exploitation can also be used to exploit this type of issue. The good thing is that ORDER
BY will be located after GROUP BY. So even if ORDER BY is used, you can get rid of it using SQL
comments.

Example 7
In this example, two queries are performed. The first query retrieves the user details based on
the parameter id; the second one uses the username from the previously retrieved record to
retrieve the user.

To exploit this issue you will need to use blind SQL injections. However, since the error
messages are displayed, we can use error-based exploitation to get information.

The idea behind error-based exploitation is to use error messages to gather information. By
injecting error-prone statements, we can get information directly from the error messages
instead of using a blind SQL injection.

For example, you can use the following statement:

extractvalue('%3Cxml%3E',concat(%22/%22,(select%20version())))
by
accessing http://vulnerable/sqlinjection/example7/?id=extractvalue('%3Cxml%3E',concat(%22/
%22,(select%20version()))) to get the following error message:

It's a really good way to demonstrate that a page is vulnerable to SQL injections and that you
can gather information from the database.
Example 8
This example is vulnerable to "second order SQL injection", instead of directly injecting your
payload into the request, you will first insert it in the database using a first request and then
trigger the payload in a second request. The first request is not vulnerable to SQL injection, only
the second is. However, you do not directly control the value used; you need to inject it using
the first request. This issue comes from the fact that the developer trusted the values coming
from the database.

Each attempt will need two steps:

• Create a user with your payload.

• Access this user information to trigger your payload.

If you want to be efficient, you need to automate this process using a simple script. The payload
can be as simple as a union-based exploitation.

Example 9
This example was first published in 2006 on Chris Shiflett's Blog as a way to bypass mysql-
real-escape-string. 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.