Web Application pentesting: a guide

If you have a situation with a web application and you don’t know where to start, this thread can be very useful. Let’s talk about the different phases of a web application pentesting and explore a specific methodology to use as a reference. From the recognition part to a focus on every aspect of the application and its architecture.

Recognition: At this stage, we are going to focus on recognizing what the application offers to us, its entry points, and if there are other applications on the webserver and even their metadata.

Our goal is to identify any relevant information about the application:

– Google Hacking to identify potential passwords or old files.

– Identify the version and other important information of the webserver.

– Identify where the user can send data.

– Obtain information about the framework implemented.

– Obtain a vision of the external architecture (at the infrastructure level)

– Know if a Rest API, SOAP, GraphQL, etc. is being used.

– Know if it is a local deployment or in the cloud.

Authentication Mechanisms: This approach is going to be key since many of the applications offer much more functionality once the user authenticates. Therefore, we need to understand how this process works and what types of mechanisms it offers (magic links, SSO, email, second authentication factor implementation). Last but not least , it’s key to  understand what the registration process is like as well as the account recovery process.

Another important aspect to take into account at this stage is to understand the roles that the application offers in order to perform lateral and horizontal movements. Other interesting tasks to analyze at this stage are:

– Password policies.

– Ability to do brute force attacks.

– Existence of self-generated or default accounts/passwords.

– Analysis of the operation of Remember Me.

– Possibility to bypass the 2FA by resetting passwords.

– Analyze cookies or session tokens.

– Identify application tokens, such as CSRF.

– Identify IDORs (can user A access user B’s data?)

Data Validation: The most important aspect of a website is where a user must enter data into the application. This will make it respond differently and will offer new features to continue interacting. Therefore, the entry points are worth our attention. If the application does not sanitize incoming data , it is very likely that a user can send malicious information and exploit typical vulnerabilities, such as Cross-Site-Scriptings or SQL Injections.

There are many vulnerabilities nested in data entry by users. These are the most well-known:

– SQL injections (identify connections to databases to search for information or, for example, in authentication mechanisms)

– Cross-Site-Scriptings (check  where the information sent by the user is reflected).

– LDAP/XML/SSTI injections (understand what type of data is sent to the application and according to the results, exploit this technology).

– Code Injection (identify features that potentially make calls to the operating system)

– HTTP/Request Smuggling

Business Logic: The previous phases can be easily prevented by using ORMs and following the best development practices, or even using a Web Application Firewall (WAF). Therefore, understanding the business logic and the application flows is  key when doing a pentest. In our experience, the most severe vulnerabilities are identified at this stage, since they are tied to the core of the business.

This stage will depend a lot on what is being audited. This will make the tests change dramatically. Below, there are a series of general recommendations to keep in mind when testing:

– Use non-existent funds or funds greater than those you have.

– In an e-commerce, test payment methods (sometimes they are reflected as an ID) that are not implemented.

– Test purchases at price 0.

– Try to skip steps.

– Many applications have time limits for operations, try to make saturation tests.

– Attempting to upload files that the app is not expecting.

Client-Side: In our experience, sometimes  most of the controls are at the client level and not the server. This is extremely easy to test using for example a proxy. Also, many applications within the JavaScript code or technology they use at the clientside expose credentials, internal paths, or business logic that is sometimes not visible unless you inspect the code.