Penetration testing

Manually Web Application Penetration Testing: Fuzzing

Introduction

When we test a web application, we do not test a single page, but a lot of pages of a single web application. Each page may have more than one variable, so technically you will be engaging with a ton of variables during your web application test. So when you inject anything into the input, it is good to know what kind of effect your injection has on the server. In this part of this series of articles, we will look at the importance of simple alphabetic injection along with the web page encoding technology and how it affects our testing and result.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Simple Alphabetic Injection

When you engage with many web pages and a ton of variables, it is good to find your input after you inject. When you give something to the web page as an input, your input will not be used in only one place, but it will be used for many variables and tons of places. One of the common ways to check which areas use a given input is to give a simple alphabetic injection. This simple alphabetic injection can be anything. As I said in an earlier article, I personally use Jonnybravo as a username and momma as a password. If I use any special characters within my input, it might get encoded/eliminated to prevent the injection attacks on that page. What encoding is and how it takes place I will cover later on. The reason for using simple alphabetic injection is because it will never be encoded or eliminated by the server and you can easily find your input within the response as well as the request.

"Webpage never encodes alphanumeric in its output compared to special characters and fancy input."

Let us suppose, if you used "$" or "#" within your input, then the webpage might encode your input as anything such as %3D, %3E or something like that. It depends on the encoding mechanism used by the web page. The webpage/server uses encoding libraries by which a user's malicious input is altered. However, alphanumeric is not altered in all the encoding libraries of the world.

"It is a common sense that if encoding libraries start using alphabets, even, than what kind of input they are asking for user!!!!"

So let's make a request by using jonnybravo in the username and momma in the password parameter in our user look-up page in NOWASP Mutilidae and then we will try to see in the response where our input is passed. The intercepted request is as follows:

[plain]

GET /chintan/index.php?page=user-info.php&username=jonnybravo&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

Cookie: showhints=0; PHPSESSID=dkm54bjhm7cnqp4umdefpa6e10

Connection: keep-alive

[/plain]

Now we will forward this request and we will get a "200 OK" message in the RAW tab of Burp Suite. This time it will also intercept the response, because I have enabled that option in Burp Proxy. I want to analyze the response, so I need to intercept the response before it goes to my browser. In response there will be HTML coding that will look like this:

"It is not always necessary that you have sent an input parameter in your request, it has to be appear in the response. Some developers do not allow those parameters to be appear in the response, ma be for security concern or for other purpose."

Now I want to find the value of my input parameters, jonnybravo and momma. So I will use the Burp's search bar on the bottom of the response window. I will give any of these keywords and try to find that input in response. It will look like this:

It's showing that we have found only one match for our search and it is listed in the response body of html code. It is used in a <span> tag. We have not created this username and password in our database so, if we create them and then we try to login and intercept the response, we may find the values of both fields in our response. I am registering this user in the database now. Then I will try to log in with those credentials and will intercept the request.

[plain]

HTTP/1.1 200 OK

Date: Tue, 31 Dec 2013 17:40:24 GMT

Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7

X-Powered-By: PHP/5.4.7

Logged-In-User: jonnybravo

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Content-Type: text/html

Content-Length: 42444

[/plain]

You can see that there is a new field, "Logged-In-User." It means that our credentials have been successfully authenticated. Here is the response; I am searching for momma input in the response.

You can see that I have found code containing the response. Now I will give a different username and password whose values are not in the database and will try to find that response.

Here is the request status:

[plain]

POST /chintan/index.php?page=login.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=login.php

Cookie: showhints=0; PHPSESSID=mq79soql2ua71rae63vjdc2qt6

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 68

username=spiderman&password=spidergirl&login-php-submit-button=Login
[/plain]

My credentials are highlighted in yellow color and the picture below shows the response I got. As these credentials are not in the database, they won't be authenticated and we can expect an "Authentication error."

As you can see, we got an error, but it didn't respond with the credentials, as the username "spiderman" and password "spidergirl" are not correct.

"It is not the case all the time, it depends on how the developer has created that web application. So sometime you may get it, sometimes you may not."

Scenario of Fuzzing

When we fuzz a web application, we are giving each of those characters and special characters to each and every parameter that we can think of. Not only special characters, but we may input sequences of special characters in those parameters. We give this input in order to find out if it makes any impact on the backend database or not. Sometimes an attacker does use special characters that are used in JavaScript in order to see if those characters are being encoded or not. However, you can choose your own technique for this; your main aim should be to create some kind of reaction with the backend server. So, before fuzzing, you need to understand which kind of special characters are being used in SQL commands. To check that, I am typing here random SQL commands and then we will try to identify different special characters from that.

[sql]

SELECT COUNT(column_name) FROM table_name; - Identified Specials Characters are _ ( ; )

SELECT COUNT(*) FROM table_name; - Identified Specials Characters are *

SELECT ProductName, Price FROM Products WHERE Price>(SELECT AVG(Price) FROM Products); - Identified Specials Characters are > ,

[/sql]

If we sum up all these results, we are having a bunch of special characters that are being used in SQL queries. These special characters are '_', '>', '*', '"', ';' etc. Let us go to the authentication page and input these special characters in order to see the result. I am inputting these special characters: --/-'*'.

Once I give all these characters in the log-in username, it reacts with the backend database and it gives me error messages:

If you see messages related to configuration, coding, syntax, or something else that is supposed to be from the developer's side, then it can be called a vulnerability. People do give different names to it. I usually call it "improper error handling vulnerability." If you have marked closely then there is a "path disclosure vulnerability." It also discloses partial application, so we have found a vulnerability named "application disclosure."

This is the system path of the internal web server of this application. In our case, we hosted this application on xampp server's htdocs folder. That is why it is showing this path. Now, as I said, we have found an application disclosure vulnerability, which is as follows:

A message box shows the application disclosure. We have also got an SQL message disclosure in our "Trace" box, which shows SQL errors. We can find the he injection that we have given in multiple places, as shown in the figure below:

Now look at the picture below:

By looking at this error message, we can also identify where our injection is lying in the query. You can see that it is at the end of the query, which is not always the case. We are on the authentication page, so the page will only find the username from the database; that is why our injection is at the end. To illustrate this, let us see a normal query to find users from database.

[sql]

SELECT username FROM accounts WHERE username-‘chintan’;

[/sql]

So we injected our content (--/-'*') instead of "chintan." Now let's find the database error that shows this kind of SQL error message in which we content lies inside the query. I am going to look up the user page and the ideal query running in the back-end database should be like this:

[sql]

SELECT * FROM accounts WHERE username='jonnybravo' AND password='momma'

[/sql]

So let us inject the username with our content and see what error messages we get from the database. As usual, we are not able to do successful authentication and we have got an error page, which is follows:

As you can see here, the whole query lies in the username variable and there is a query before and after our injection.

Conclusion

This was all about the introduction to fuzzing, how fuzzing works with the backend database, and what kind of reactions we see at the client side on our browser. In my next article in this series, I will talk about the various types of fuzzing, including what is a suffix and what is a prefix in these contexts or SQL statements and much more. Stay tuned. Thank you.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

References

1. http://www.w3schools.com/sql/
   
2. https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)