[Crypt]

Introduction -
Are you tired of being a skid that never finds SQLi? Are you one of those guys who puts ' after a parameter and when it doesn't return an error you think, "Welp, guess it's not vulnerable!"? Well shit, this is the guide for you. This is intended to be referred to more as a handbook/reference guide rather than a tutorial.

Basic SQLi Vulnerability Triggers -
The most commonly used technique to get a page to return an SQL error is breaking the query using "'". There's absolutely nothing wrong with doing this, however, most modern WAFs will have prevention systems in place that block this simple and overused attack. Relying on solely the apostrophe technique will get you nowhere and you will never hack any big sites using it.

The next most overused method is the basic boolean technique. This consists of putting "AND 1=0", "' AND 1=0", or "AND 0" after the parameter. Once again, there's nothing wrong with it, but modern WAFs will block it.

Notice how the above technique was referred to as "basic". This is because there are more complicated (but shouldn't be complicated) ways to make the query return false. One of these ways is simply including apostrophes in your query, like so:

Code:

AND '1='0

Alternatively, rather than including apostrophes (or you can just combine this with apostrophes), you can change the capitalization of "AND" as well as the size of the integers after it. Some (but not most) WAFs will have blacklists that only block "AND 1=0" or "and 1=0", which makes it easy for us. We could do something like this -

Code:

AnD 38459345=3804529 And it would work just like "AND 1=0".

Intermediate SQLi Vulnerability Triggers -
All this really includes is tampering with the boolean technique a little further. One of the ways to do this is changing the data type from an integer to a float (decimal), like so -

Code:

AND 203.345=245.234

The second way of doing this is adding whitespace to the query. Lopsided, missing, or extra whitespace can bypass signature-based IPSs. An example of this would be -

Code:

AND 1 = 0

I know it looks extremely retarded, but hey, it works.

The last way of "intermediate" SQLi triggering is using arithmetic operators to mess with the query. The only thing you can't do (usually) is use addition because when you use +, it is parsed as a space and your query won't be read as an equation. The three ways you can do this are shown below -

Code:

AND 1-2=0 AND 1/2=0 AND 1*2=0

These will all return false and make the page load improperly.

Advanced SQLi Vulnerability Triggers -
This is where the even more complex (but still, shouldn't be complicated) techniques come into play when none of the above work. This is what we must use when IPSs specifically look for boolean operaters before conditional statements if it is being appended to another conditional statement and immediately block it if spotted.

In this case, we can use the conditional statement "IF" instead. The easiest way to do this is -

Code:

AND IF(98234892=234234,1,0)

The 1 and 0 inside the parenthesis represent true and false where 1 is true and 0 is false. The statement above will obviously return false, triggering an error in the page. You can modify the statement like the intermediate ones above (e.g. using arithmetic operators, different data types, etc) and it will still work perfectly.

The next "advanced" way to trigger errors is using the "BETWEEN" statement. "BETWEEN" is a comparison operator and will return true or false based on whether the provided integer is between the other two integers after it. This is useful when "=" is filtered out of the parameter. The most basic way to do this is demonstrated below -

Code:

AND 1 BETWEEN 2 AND 3

Which will return false, since 1 obviously isn't between 2 and 3.
The between operator will also work on strings (good when you can't use integers) however, quotes are used -

Code:

AND 'a' BETWEEN 'b' AND 'c'

The last but certainly not least way to do this is the REGEXP operator. This one should be pretty self explanatory and it's probably the easiest to do. The simplest way to perform this is

Code:

AND 1 REGEXP 2

Which will return false. This is no different from the usual "AND 1=0", it just uses REGEXP instead of an equals sign.

Extras -
Whenever the basic " " whitespace is filtered, try using alternative whitespace characters, such as + signs or MySQL comments. MySQL comments are interpreted as whitespace so they will work just fine. An example of this would be

Code:

AND+1=0 or AND/**/1=0

Which can also be used for the mass of whitespaces, shown in the intermediate SQLi triggers.

Everything above this can be replaced with hexadecimal values, such as 0x61 which translates to "a". What I mean by everything can be replaced is this -

Code:

AND 0x31=0x30 AND IF(0x31=0x30,1,0) AND 0x31 BETWEEN 0x32 AND 0x33 AND 0x31 REGEXP 0x30

Note: you can also hex encode strings rather than integers and use them instead.

BIG NOTE: ALL OF THIS CAN BE SHOT DOWN WITH intval() and/or mysqli_real_escape_string()

Thanks for reading, hope you found this useful.

[Dyme]

Nice.

BIG NOTE: ALL OF THIS CAN BE SHOT DOWN WITH intval() and/or mysql(i)_real_escape_string()

Thanks for reading, hope you found this useful.

This is the real take away here. If you're not using mysqli_real_escape_string() by now quit making web applications forever.

[Reiko]

No one ever mentions that you can use grouping to eliminate whitespace.

(5)and(1)like(1) works fine

[Schism]

No one ever mentions that you can use grouping to eliminate whitespace.

(5)and(1)like(1) works fine

I'm using that technique too to bypass some waf

Example:

Code:

/*!50000UNION*/(SELECT/**_**/(1),(2),(concat/**_**/(0x0d0a3e3e496e6a65637465642077697468202623393832393b2062793a2053696c656e74416e67656c205c6d2f3c3c,0x3c62723e,database(),0x3c62723e,version(),0x3c62723e,user())),(4),(5),(6))--+

[Freerunning]

Using prepared statements can use to prevent this right?

[Bish0pQ]

This tutorial looks good, nice contribution.

[mothered]

I realize this Is over 3 months old, but just dropping In to say that this Is an excellent thread.

Some of It pretty basic and others not, but either way, a wonderful contribution Indeed.

[Loki123]

BIG NOTE: ALL OF THIS CAN BE SHOT DOWN WITH intval() and/or mysqli_real_escape_string()

Prepared statements using MySQLi or quite simply use PDO. In both those cases it is shot down automatically as the string is run through the MySQL C api function (mysqli_real_escape_string)
Prepared statements are really the best practice. But bad programming on your behalf is usually the cause for SQL injection vulnerability. PDO and MySQLi isn't bulletproof either btw.