Wednesday, 27 March 2013

[EN] IdeAbout SQL Injections

Why I understood it is more important to test 'for sqli bugs' by reading the code.

Once you find it 'at the code' you will know exactly 'where' and 'what payload' you need to
'put' by injection attack to this vulnerable place/parameter/cookie/whatever.

For example. 'Error-based' attacks. Ok, great attack, etc, but what if somewhere (in the
code) you have a 'filter' which will block all error-generating actions (or of course 'block it'
by generating some 'error page' or whatever else like this could be done here too, to protect this webapp
or setting of php.ini file, you name it).

What is good to remember:
- if you're using egrep with "something|else", in case of 'searching for sql injections' it could be useful
to search like this: egrep -n -r -e "select |insert " <- check it twice if you can not see a ' ' (space) between
'sql-word'(select) and |.

Ok, now it could be used with:
$ egrep -n -r -e "SELECT | INSERT | (other sql command you want here)" ./ | grep "DESC" (for example of course*) | grep -e "\\$"
what will give you:
- paremeters ($...),
- queries with 'DESC' (but be carefull here, once uppon a time I found that searching for this command (DESC) echo'ed 'other' output (strings) than 'ASC' (for ASC there was no output). So think about what you're looking for because you can get exactly what you've asked. ;))
- and of course 'sql-command' that you wanted.

(Remember that in this 'example' we are looking for vulnerabilities in PHP based-webapp. So add here another bash command to 'extract' only interesting us data (without checking for sql-commands in files like TXT for example).)

So maybe now we should 'switch places' with 'programmer/coder/developer'.
Where (as a 'programmer') you will 'have to' use SQL language?

Few examples (in):
- registering users
- mail to them (via form/contact - if there's any at your site)
- forum/blog/board/guest book
- search (if page is generated by content from db)
- forgotten-password mechanism
- and so on...

Stop here, and think about it in (an)other way. Where else can be sqli found?
If 'this webapp is so big', (as a programmer) you will (? ;)) have to use some
let's say 'catalog' to store (and include or use in the future) there your filtering
functions, db-functions, other, and other functions... Like a 'lib' directory.

So 'ls -la', and where is the (typically) include or lib or library, and so on.
(That's why attacker who want to hack your page will do a file/dir-searching-attack
to find out, if at your websrv is any 'interesting' directory (or file, like 'admin.php.back', etc).

Ok. Let's back to our searching 'via e/grep'.

What file is using for what, can be guessed by simple reading their names. ;)
Usually of course. For example (at typical ls -la ./webapp/) we'll have something like:

Now you have an idea what and how can you start for searching sql injection bugs.

---------------------------------------------------------------Example from course of 'how to make your page with mysql'
---------------------------------------------------------------

We wil stop at this moment to get to know how webapplication is builded
with sql commands. How can it be done, how sql-queries are created.

We will use now a simple example: page where 'id' parameter is related to
user (a student let's say). If page-visitor will send (via HTTP GET) a value
for 'id' param, he (visitor) will 'go directly do DB' to try if there is a
table or column (or...?) with value '1' for something like 'id parameter'.

(Tip here: if you're testing sql injection vulnerabilities at your server, you can use
one interesting command to do a little debug and to find more precisely where exacly we can try to
exploit a possibility of vulnerable piece of code. Try this:
root@box:~# tail -n 1 -f /var/log/mysql.log
This command will print out a result of SQL query.)

For example:
(At linux console, we have tail -n 1... and in the browser we have a (full address) to our page.php)