INTRODUCTION

There are a good numbers of SQL injections. One of the most difficult to detect and to exploit are Second Order SQLi. We can definy First Order SQLi as the “classical” and more frequent vulnerability in which we edit a legit query with our own code in the same SQL statement in order to retrieve some data from the database.
A second order SQLi in the other hand is a vulnerability exploitable in two different passages:

  • in the first one, we STORE a particular value in the db and
  • in the second one, we use the stored value to exploit a vulnerability in a unfiltered and bugged function in the code of the web application.

EXPLOITATION - an example

Let’s imagine that i want to take over a user account on our already always exploited in a whitepaper *http://target.com* :D
Maybe there is a register functionality in the website, with a lot of other dinamic things such as an user panel (to edit your profile, avatar, signature ..), a forum, a blog and so on..

It could be possible to exploit some functions that doesn’t need a user input and uses data already saved in the db, that retrieves when needed. An example? The password reset functionality!

Our friend “jack_the_leet_h4x0r” could be registered on the website with a very strong and secure password but we still really want to get his account. In a second order SQLi we should be able to do something like:

Register a new account. We want to name this new user as “jack_the_leet_h4x0r‘ –” and password “123456Seven”

Then we can reset our password and set a new one in the appropriate form.
The legit query will be:

$pwdreset = mysql_query("UPDATE users SET password='getrekt'  WHERE username='jack_the_leet_h4x0r' --' and password='123456Seven'");

BUT since – is the character used to comment in SQL, the query will result being this:

$pwdreset = mysql_query("UPDATE users SET password='getrekt'  WHERE username='jack_the_leet_h4x0r'");

And this will set a new password choosen by us for our friend’s account! :D \o/

CONCLUSIONS

This kind of vulnerability happens because a good programmer maybe will patch his code to prevent SQL injections in forms where the user can input something BUT he will not do the same thing where a user doesn’t have any sort of interaction with the web site / database.