Web Application Penetration Testing

It is recommended that all web applications are tested at least once a year and after major code changes to ensure vulnerabilities are promptly identified and addressed, maintaining continuous security and reducing exposure to potential cyber threats.

Our approach 

We can assess the security posture of your web applications. We identify risks and security issues, providing recommendations on how to address these security issues to harden the applications to make them resilient to compromise.

The primary source of our web application assessment methodology is the OWASP Web Security Testing Guide (WSTG). However, reliance on a single static resource would result in vulnerabilities being missed. As a result, we use a combination of our own experience and techniques while keeping up to date with cutting-edge research, resulting in a hybrid testing methodology. 

The testing process is driven by the application and how it functions. With many sites having complex flows and multiple user roles, it is essential that both automated and manual testing are used to discover deeply hidden issues. We search for weaknesses within the application, looking to chain vulnerabilities together to maximise their impact. Due to the rich and varied nature of web applications, we take an approach that combines frameworks such as OWASP and combines it with years of web application testing experience.

When a high level of assurance is required, source code can be used to augment web application testing. With the ability to directly observe the inner workings of a web application, it is possible to uncover weaknesses that would remain hidden as part of a normal web application test.

Common vulnerabilities can include:

A lack of effective access control, where a lower privileged or unauthenticated user may horizontally or vertically escalate their privileges to access other users’ information or higher privileged functionality.

Injection vulnerabilities, in which an attacker can exploit vulnerable code to execute client- or server-side code through the web application front-end. Examples of this can range from cross-site scripting or client-side template injection to SQL injection or direct host-level command injection.

Vulnerable and outdated software components used by the web application may be exploited through the use of publicly known vulnerabilities.

Broken authentication flows, for example, where lax Single-Sign On (SSO) or OAuth scopes may expose authentication tokens through insecure redirects. 

High and critical risk vulnerabilities

 It is our policy to directly contact the designated client contact upon the discovery of a high or critical risk vulnerability, or one that poses an immediate threat to the environment or its users. Direct contact is made through email or phone with a detailed description of what the vulnerability is, how it would be exploited by an attacker, and how to remediate it as a temporary or permanent fix.

Reporting

A report is written detailing the processes carried out and the issues found. Generally, this will contain a prioritised list of vulnerabilities discovered grouped by functional area. Remediation advice will be provided, both in terms of an immediate fix and any defence-in-depth measures that could be taken to mitigate risk.   Attack chains, alongside their impact, will be documented. Any higher-level findings that can be abstracted from the testing will be provided. Any architectural or design weaknesses will be highlighted so that these can be avoided in the future. Finally, an executive summary is produced to allow the most severe issues to be communicated quickly to stakeholders.

Example vulnerabilities from previous engagements

To illustrate the type of real-world attack that a client can expect, these are some possible attacks based on previous tests carried out across a range of web applications.

From an unauthenticated perspective, the consultant was able to identify a vulnerability in the server software that exposed the partial names of all files within the web root. Using this vulnerability, they were able to enumerate a list of valid file names and directories on the application using a word list matching the partially exposed six-digit file name prefix. By visiting each of these files, a handful were found to be accessible prior to authenticating to the web application, one of which was an endpoint used to package resources into a compressed format. The consultant identified a valid parameter through fuzzing this endpoint which was found to accept a full URL scheme and filename.

The consultant then contacted the client regarding the endpoint and their findings. The client was happy for the consultant to replicate the process of what an external attacker would do and attempt to escalate the finding further. Using this parameter, the consultant attempted to query a listener service hosted on Ours infrastructure with a HTTP request to see if the endpoint was vulnerable to Server-Side Request Forgery (SSRF). Upon observing a connection being made from an IP address belonging to the client’s web server, the presence of an unauthenticated SSRF vulnerability was confirmed.

Through leveraging the SSRF to read local files using a specially crafted URI scheme, the consultant was able to retrieve encryption keys used by the application to preserve page and control values between round trips. Using these keys, the consultant was able to craft a serialised payload to demonstrate code execution by writing a static file to the web root which contained server-side code. Overall, this demonstrated the ability for an unauthenticated attacker to completely compromise the web application and its server from a black box perspective with no prior knowledge of the web application or its internal purpose. Constant communication with the client was carried out throughout the process of identifying the endpoint to creating a proof of concept for the code execution.