Welcome back to another installment of Web for Pentester I. This post is going to go over the SQL Injection examples. Manually iterating over SQLi can be quite a complex subject, however, thankfully there are many tools availble to help us in this endeavor. Personally, I use SQLMap and Burp Suite pro. Here are other sections File Include Attacks , Directory Traversal
Warning! Spoilers ahead!
SQL Injections are one of the most common (web) vulnerabilities. SQL injections come from a lack of encoding/escaping user-controlled input when included in SQL queries.
This example only offers us a way to understand if we are in fact testing a parameter which is susceptible to SQLi.
To test this if we change the parameter does it change the output? What if we use a single or double quote?
If we use the below string we can see that we have a point of injection.
http://pentesterlab/sqli/example1.php?name=root' or '1'='1
In this example the use of spaces is blocked by the developer.
ERROR NO SPACE
There are many ways to bypass this control however the easiest would be to use a
\t tab character. We have to URL encode this though
From here we can modify our payload so that it works.
Using the payload from the previous example we can see that the developer is onto our sneaky tricks and has added a control for tabs in our payload. What’s another way we can still get injection?
Here we start seeing some mitigation. However in this example it is poorly implemented.
mysql_real_escape_string – Escapes special characters in a string for use in an SQL statement. This is actually deprecated after PHP 5.5.0.
mysqli_real_escape_string – Escapes special characters in a string for use in an SQL statement, taking into account the current charset of the connection.
The following payload successfully injects this example.
http://pentesterlab/sqli/example4.php?id=2 or 1=1
For this example, we also have to deal with a regex which is looking to ensure that the ID parameter is an integer. However this is poorly implemented as the regex only checks to ensure that ID STARTS with an integer.
http://pentesterlab/sqli/example5.php?ID=2 or 1=1
The above payload still works in this instance as the regex requirements are met. ID starts with an integer.
This example is the other way around. The developer made a mistake in the regular expression again. This regular expression only ensures that the parameter
ID ends with a digit (thanks to the
$ sign). It does not ensure that the beginning of the parameter is valid (missing
^). You can use the methods learnt previously. You just need to add an integer at the end of your payload. This digit can be part of the payload or placed after a SQL comment:
1 or 1=1 # 123
http://pentesterlab/sqli/example6.php?id=2 or 1=1
This is another example of bad regex. Here we can see that the beginning (
^) and end (
$) of the string are correctly checked. However, the regular expression contains the modifier PCRE_MULTILINE (
/m). The multiline modifier will only validate that one of the lines is only containing an integer, and the following values will therefore be valid (thanks to the new line in them): * 123\nPAYLOAD; * PAYLOAD\n123; * PAYLOAD\n123\nPAYLOAD;
http://pentesterlab/sqli/example7.php?id=2%0A or 1=1
In this example we are adjusting the way we view the table with the ORDER BY MySQL statement. The ORDER BY statement cannot be used with values inside single quotes
' or double quotes
". If this is used, nothing will get sorted, since MySQL considers these as constants.
To detect this type of vulnerability we can try to get the same result using different payloads:
And the following payloads should give different results:
The payload used in this case was:
http://pentesterlab/sqli/example8.php?order=name\ # or order=name`,`name`
This is the final SQLi example, which is geared more around detection of there being an SQLi vulnerability. Here we can try using the
IF statement to ascertain whether there is SQLi in this page or not.
Thanks all, I’ve really enjoyed going through these challenges. I hope you get something from them!