Identifying Injection Points
If your web page is static, you cannot test it as far as security concern. You can test it at some sort of view but you can’t play with it much as compare to dynamic page. Nikto scanner is a good utility which works best in testing static sites. There has to be some interaction between client and server via login panel, comment section, register page, contact us form and so on.
“Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6500 potentially dangerous files/CGIs, checks for outdated versions of over 1250 servers, and version specific problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software. Scan items and plugins are frequently updated and can be automatically updated – Nikto Official Website.”
Tools like nikto might face problems or does not give efficient output while you test dynamic application.
For our test I am opening user lookup page for now. Page looks like below figure. First let us understand how this page works and as we can see here there are 2 input fields such as username and password. But as I told its browser’s interpretation that webpage should look like this. So to begin the test, let us give any input and intercept the request so that we will come to know which parameters it is passing to the server and how our input value is assigned to those parameters.
For testing purpose you can give any input as you like, I personally give the username as jonnybravo and password momma. You can choose any input as you like but I personally prefer this input because of one major reason. When any webpage encodes your input, it will never encode alphabetic. So in my case I have not used any special character or something like that. So I am assuming that I will find this input in request as well as response. It doesn’t matter if login gets successful or not. After giving inputs I clicked on login button and captured request from the burp is as follows.
GET /chintan/index.php?page=user-info.php&username=chintan&password=chintan&user-info-php-submit-button=View+Account+Details HTTP/1.1
Host: local host
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=user-info.php&username=jonnybravo&password=momma&user-info-php-submit-button=View+Account+Details
Cookie: showhints=0; PHPSESSID=d3kmtdkar70bahk12c3ost5hd6
Connection: keep-alive
There are main 3 parts where you can inject something. They are illustrated as follows.
1. URL – Check whether there is any parameter passed or not. By watching our request we can see that there are couple of parameters passed. In our request page, username, passwords etc.. are the parameters passed. Burp often calls it params instead of whole word parameters. If we look at our request it shows the method they are using to pass the parameters is GET. It can be post as well. GET usually passes parameters in URL only. In post method those parameters are passed separately(not un URL) down in the request body.
“Burp has an ability to convert your GET method into post and post method into GET.”
So here lets change this method to post by right clicking in the request area anywhere and selecting the option which shows change request method.
One you changed to request method, it will be converted into post request and then it will look like below.
POST /chintan/index.php HTTP/1.1
Host: local host
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=user-info.php
Cookie: showhints=0; PHPSESSID=d3kmtdkar70bahk12c3ost5hd6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 104
page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details
You can see here params are passed separately(not in URL) down in the request body.
1. Cookie : We can also pass data through the cookie. It might have parameters and the values sometimes you can change the value according to your need.
POST /chintan/index.php HTTP/1.1
Host: local host
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=user-info.php
Cookie: showhints=0; PHPSESSID=d3kmtdkar70bahk12c3ost5hd6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 104
page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details
2. Body : Last but not the least is a body part. As I have mentioned that in POST request, data is passed at the bottom part of the request separately but not in URL. So you can modify that value of the params there in the body part. Considering above request, body parts are as follow.
page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details
If you are confused that what are the params and which are their values then click on the params tab to see the list of the parameter names and their values. Due to having POST request we have 4 params in our request body part.
One you changed to request method, it will be converted into post request and then it will look like below.
POST /chintan/index.php HTTP/1.1
Host: local host
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=user-info.php
Cookie: showhints=0; PHPSESSID=d3kmtdkar70bahk12c3ost5hd6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 104
page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details
You can see here params are passed separately(not in URL) down in the request body.
1. Cookie : We can also pass data through the cookie. It might have parameters and the values sometimes you can change the value according to your need.
POST /chintan/index.php HTTP/1.1
Host: local host
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=user-info.php
Cookie: showhints=0; PHPSESSID=d3kmtdkar70bahk12c3ost5hd6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 104
page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details
2. Body : Last but not the least is a body part. As I have mentioned that in POST request, data is passed at the bottom part of the request separately but not in URL. So you can modify that value of the params there in the body part. Considering above request, body parts are as follow.
page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details
Let’s get back to original GET request and then we will see the param tab. At that moment we will be listed here the URL type instead of body.
So you can see here that all body parameter type is converted in to URL because it is a GET request.
Scenario 1: Let us just assume that this login panel is not allowing us to enter the username except “admin”. To support this security mechanism, developer might have put javascript validation on this page which does not allow any other username param’s value except admin. So in this case how do we bypass that mechanism to test the other desired username.
Solution 1: In that case initially we will give admin as a username so at client side, page will validate the username admin and will allow us to send the request. As soon as we click on send the requests we will see intercept it using burp. So intercepted request should look like below.
GET /chintan/index.php?page=user-info.php&username=admin&password=momma&user-info-php-submit-button=View+Account+Details HTTP/1.1
Host: local host
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/chintan/index.php?page=user-info.php&username=jonnybravo&password=momma&user-info-php-submit-button=View+Account+Details
Cookie: showhints=0; PHPSESSID=d3kmtdkar70bahk12c3ost5hd6
Connection: keep-alive
As you can see yellow highlighted parts username and param’s value is respectively admin and momma. We have already pass through javascript validation. Now we can modify the values over here and we can forward the request to submit it to the server.
GET /chintan/index.php?page=user-info.php&username=jonnybravo&password=momma&user-info-php-submit-button=View+Account+Details HTTP/1.1
So you can see that I simply changed the value of username parameter by editing and if you want to confirm that value is really changed then you can go to param tab to see the new value of username param. In my case it is as follows.
Now I will forward this request and will have a look at the browser. So my browser will look like below pic.
Here you can still see that at the time of giving username and password, I gave admin(which is still there) but we intercepted request changed param value to from admin to jonnybravo and then our request is authenticated with the server with new username and password. As there is no any username consisting jonnybravo in the database so I have got authentication fail error.
“Thus how we can bypass javascript validation on any form or authentication panel.”
So It was all about identifying injection points, intercepting request and changing the request to get to post and vice-versa. We have also seen what params is called in burp suite along with its value. I also demonstrated how to change the value of params in order to submit the request. Main aim of doing so, was to bypass the javascript validation at client side.
