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
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
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
Accept-Encoding: gzip, deflate
Cookie: showhints=0; username=chintan; uid=19; PHPSESSID=j53u16lcdkjq0eec6nfijphkd4
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."
Date: Sat, 28 Dec 2013 23:30:08 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
Keep-Alive: timeout=5, max=100
"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:
