Pentest SQL Injections
Pentest 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:
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).
`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 ':
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.
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.
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.
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: