In this detailed series of articles, we are going to discuss how to test a web application step by step. This is would be a long article but we divided it into parts, so this will be a mega-series for web penetration testers and bug bounty hunters.

This article will cover all the categories of vulnerability and attacks an ethical hacker does while testing a website or web application. We are not giving guarantees that these methods will lead to unearthing vulnerabilities on a website, but it will give us a very good level of knowledge of how web penetration testing works.

This is the second part of the series, here we are going to discuss analyzing the web application. In the previous article, we had discussed mapping contents.

2. Analyze the Website

Scan the Functionality

1. We need to identify the main functionality of the website. Also need to indicate the actions that each function is created to perform when it is used.
2. Find out the core security mechanics in the website and how it works. For example, we need to check how it works for authentication, season management, and access control and the functions that support them. Like user registration and account recovery.
3. Know more about the peripheral functions like redirections, external links, error messages, admin and login functions.
4. We should look for any functionality that is separate from the standard GUI activity, parameter naming, or navigation mechanism used in all the places on the website. We should check these ones by one for in-depth testing.

Look Inside the Data Entry

1. We need to see all the different entry points that accept user data inputs into the webserver. Also check the URLs, query string parameters, POST data, cookies, and other HTTP headers processed by the website.
2. We inspect customized data transmission or encoding mechanics used by the website. Like a nonstandard query string. We need to understand where the data being submitted encapsulates parameter names and values.
3. We need to identify any out-of-band channels through that user-controllable data or any other 3rd party data that is being introduced inside of the web server's processing. Like a webmail function will process and render messages received through SMTP.

Know the Technologies Used

1. We should identify each of the different technologies used in the website or web application. We will look for all the client-side technologies like forms, scripts, Java applets, cookies, ActiveX controls, and flash objects.
2. If possible we should check the server-side technologies used on the server-side, like scripting language used, application platforms, and interaction with back-end components, like databases and e-mail systems.
3. We also check the HTTP Server header returned in the website response. Also, we check the other functions identifiers contained within custom HTTP headers or HTML source code comments. Here different areas of the website might be used with different back-end components so different banners may be used.
4. We need to fingerprint the website using the WhatWeb tool.
5. We should check for interesting script names and query string parameters that may be from third-party code used. We can find them on Google using the inurl: qualifier to find any website using the same scripts and parameters.

Mapping The Attack Surface

1. We need to determine something about the internal structure & functionality of the server-side and need to know what kind of mechanism is running in the back-end. The idea should be taken from the visible side or client-side perspective. For example, if a function stores items in a shopping cart then it is most likely to be interacting with a database.
2. For every function, we should identify and list the common vulnerabilities associated with each function. For example, file upload functions may be vulnerable to path traversal. User chat and forums may be vulnerable with XSS. Contact us functions may be vulnerable with SMTP injection.
3. We should calculate an attack strategy, by keeping in mind the most serious vulnerable-looking functionality. We should use our plan to guide the amount of time and effort for each of our targeting sectors.

End Notes

The above methods will help us to analyze our target web application. Must read our previous part of this series “A Guide To Web Security Testing: Part 1” - Mapping Contents. In the next part, we will test the client-side controls.