In this series of articles, I am going to demonstrate how you can manually exploit the vulnerability of a web application, compared to using any automation tool, in order to find vulnerabilities in the application. Almost all companies worldwide focus on manual testing of web application rather than running web application scanners, which limit your knowledge and skills and the scope of finding a vulnerability with your testing.
For the whole series I am going to use these programs:
- NOWASP Mutiliadae
- BURP Proxy
NOWASP Mutiliadae
NOWASP Mutiliadae is a purposely vulnerable web application containing more than 40 vulnerabilities. It includes all of the OWASP top 10 vulnerabilities along with vulnerabilities from other organizations’ lists. There are other small and mid-level range vulnerabilities that are scanned by different web application scanners, such as Vega, Acunetix, Nikto, w3af, etc. I am going to use the latest version of this project, which has an object-oriented design to provide better understanding of all vulnerabilities of the web application.
Burp Suite
Another tool that I am going to use is Burp Proxy. This is an interception proxy tool that interacts between the client (a browser application, e.g., Firefox or Chrome) and the website or server. It will be running on my local machine and it will intercept inbound and outbound traffic between the browser and the target host (in our case, the target host is NOWASP Mutiliadae). The major use of this tool is when you make a request to access the server, Burp Suite intercepts that request from your machine to the server/website and you can change the request according to your needs. Also it reveals the type of the request, whether it is a GET or POST request or some other. Burp also has the ability to show you the list of parameters that are used by the website in order to pass your request to from you to the server. You can manipulate the request to change the way you want to check the security of that particular web application. To intercept the request, your Burp Proxy listener must be configured on a 127.0.0.1 localhost and port 8080. Then you also set this proxy configuration in your web browser. After doing so, go to Burp Suite => proxy tab => Intercept is on (make sure this button is pressed). I will not go deep into all the tabs and their functionality. You can see the Burp manual or documentation for that.
Working Flow of Web
Before we go ahead, you should understand how the web works on the backend, which you cannot see on your web browser. When you visit any website your browser asks for a file from the web server, which can be HTML, PHP, js (JavaScript), CSS, ASPX, etc. Using Burp Suite, we can observe that request as shown below. To see the request, I configured Burp and my browser as mentioned above and then visited the HTML5 storage page shown in the picture below.
As soon as I click on the link, Burp will intercept the request, which is shown below. You can see here that it is requesting an index.php page from the server. Burp will also show you the parameter that is required to load the whole page. Here that parameter is page and the value of that parameter is html5-storage.PHP.
- GET /chintan/index.php?page=html5–storage.php HTTP/1.1
- Host: localhost
- 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/
- Cookie: showhints=0; username=chintan; uid=19; PHPSESSID=j53u16lcdkjq0eec6nfijphkd4
- Connection: keep–alive
I need to access this page, so I will forward this request and in the section below, if you see the response tab, then I will get the response “200 OK.”
- HTTP/1.1 200 OK
- Date: Sat, 28 Dec 2013 23:30:08 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: chintan
- Keep-Alive: timeout=5, max=100
- Connection: Keep-Alive
- Content-Type: text/html
- Content-Length: 46178
“200 OK” shows that my request has been successfully processed and I am giving back the response. Then if I look at my web browser, the full web page will have been loaded there.
Remember: An HTML file is dynamically created each time you make a request. The PHP file in the backend will see your request and will create an HTML file to send to your browser in order to render the page. Whatever you see on your web browser is not a web page. it is your browser’s interpretation of how the web page should look like graphically.
“Always make it a good practice to see the webpage from the source code and get yourself familiar with that but not with the one that you see graphics on your web browser. Get yourself familiar with JavaScript, XML, and all HTML tags, if possible.”
Where to Start?
The common problem of all beginners is knowing what to do first when starting to test. We all know the ethical hacking life cycle. The first phase is information gathering or reconnaissance. In this case, I will get as much information as I can about the website and the server without actually surfing each web page. If you have noticed them from the above request and response, we have already come to know about some of the things in it. That information is as follows:
| No. |
Information
|
| 1. |
Server – Apache
|
| 2. |
Apache Version – 2.4.3
|
| 3. |
Server Side Coding – PHP
|
| 4. |
PHP version – 5.4.7
|
| 6. |
HTTPs Protocol – SSL Used
|
| 7. |
SSL Version – 1.0.1c
|
| 8. |
Logged in User
|
| 9. |
Username – chintan
|
There are plenty of ways to gather information. However, people mostly follow Google, Recon-ng Framework, and other application security testing tools. I will list all the pages and folders of my target using the spider option in Burp Suite. To do that, go to history and check the first page you visited. Right click on that and select the option to add to the scope.
Now if you go to the target tab you will see your scope of testing website, which is localhost in my case, as shown below.
“It will also list all of the other websites that are being visited without you knowing. Let us consider any live website: There will be a “like” button, a “share” button or some kind of advertisement that will also get listed here. To remove an unscoped item, click on the filter bar and set your all options as shown in the figure below, then click anywhere on the blank page and changes will be applied.”
After that, as I mentioned, I need to spider this host, so I will right click on the localhost and select the Spider this hostoption. If your target application has a form submission, then you will get a popup to fill in and submit the form values.
After clicking on that, the spidering of your target host will be started. If you go to the spider tab, you will see something like the picture below.
“Note that if a request queue becomes and remains 0 for more than enough time, it means the spidering of that web application is finished.”
Then you can go ahead and again check the target option; you will see the list of all the pages that web application has. Some new pages might have been added.
Proxy Setting
There are not any particular settings or configuration. I personally set the configurations as shown in the figure.
The reason I am using these settings is because our target host might link to a ton of other websites via share buttons, advertisements, etc. I want to intercept all the communication between myself and my target host, but not any other website. That is why I tick that checkbox to intercept only a request that “Is in target scope.” I also want to intercept each response that is processed by the server against my all responses so that I can know if my request is processed properly or have I been redirected to somewhere else, etc. So I tick that option that shows “Intercept all the responses.”
Preface of the Next Part of This Article
In the next part of this article series, I will show you how to identify the application entry points and the injection points and how the server encodes your input.
References
