Web Application Penetration Testing

Web Application Penetration Testing is the practice of simulating cyber attacks against a web application where security experts attempt to find and exploit vulnerabilities. It is a proactive approach to identify, analyse, and address cyber-security vulnerabilities within a web application. This process is crucial for safeguarding applications from attackers who could exploit vulnerabilities to gain unauthorised access, manipulate data, or disrupt services

Scope and Objectives of Web Application Penetration Testing

The scope of Web Application penetration testing is broadly defined by the nature of the Web Application environment and the specific requirements of the organisation.

Typical objectives include:

  • Identifying security vulnerabilities: Detecting existing flaws in the web application that could potentially be exploited.
  • Assessing the effectiveness of security measures and mechanisms in place: Evaluating the robustness of current security protocols and configurations.
  • Testing incident response capabilities: Analysing how well the environment hosting the web application and its operators can detect, respond to, and recover from security breaches.

Why Choose ProCheckUp for Your Penetration Testing?

Choosing ProCheckUp means partnering with a proven leader with over 25 years experience. Our CREST approval and NCSC endorsements reflect our commitment to delivering top-tier cyber services across various sectors. We offer flexible, cost-effective solutions tailored to meet the diverse needs and budgets of our clients, ensuring continuous improvement..

Before initiating any web application penetration testing activities , it is crucial to ensure all legal and preparatory steps are thoroughly addressed. This not only guarantees compliance with laws and the hosting environment policies if applicable but also sets the stage for a successful and ethical penetration testing process. We outline below, the essential legal and preparatory requirements..

Legal Compliance and Permissions

  • Client Authorisation: We obtain written consent from the the client, detailing the scope of the penetration test. This consent should specify which parts of the application are to be tested and the testing methodologies to be used.
  • Service Agreements: We ensure that there is a formal agreement, such as a Statement of Work (SOW) in a Job Schedule Form or a more formal Professional Services Agreement (PSA) for larger clients, that details the engagement's goals, scope, limitations, and responsibilities of each party involved in the testing process.
  • Confidentiality Agreement: Often part of the initial agreement to safeguard any sensitive information discovered during the testing process.
  • Regulatory Compliance: Both the client and ProCheckUp should be aware of and comply with all applicable local, national, and international laws regarding cyber-security and data protection. This may require consultations with legal experts to ensure that the testing activities do not violate any regulations.

Pre-Test Preparation

In preparation for a web application penetration test, access requirements are identified and appropriate tools are configured to ensure they address recent vulnerabilities and can log activities effectively. A communication plan is established with stakeholders to align on objectives and procedures, while stakeholders implement safety measures like backups and impact analyses safeguard against disruptions.

Technical Preparation

  • Access Requirements: We determine the types of access required for the test, such as specific user roles, user accounts with administrative privileges or accounts using MFA.
  • Tool Configuration: Select and configure the appropriate tools and methods for the test. Ensure they are updated to address recent vulnerabilities and are capable of logging activities without causing disruptions.

Stakeholder Engagement

  • Communication Plan: We establish a communication plan with all stakeholders, including security teams, IT management, and any operational personnel to align on the test objectives and procedures.
  • Incident Response Coordination: We coordinate with the stakeholders incident response team to prepare for any potential discoveries of active security incidents during the test.

Customer Safety Processes

  • Backup Systems: When testing production systems customer stakeholders should ensure that backups are available for all critical data and configurations in case the test inadvertently affects system stability or data integrity.
  • Impact Analysis: Customer stakeholders should conduct a risk assessment to identify potential impacts of the test on the system and operations, preparing mitigation strategies for identified risks.

Documentation and Record-Keeping

  • Test Plan Documentation: We maintain detailed documentation of the test plan, methodologies, tools, and any customer procedures used during the penetration test. This should include the rationale for choosing specific testing methods and the expected test outcomes.

Define The Test Objectives And Scope

  • Objective Setting
  • Working with customer stakeholders we clearly define what the penetration test aims to achieve. Common objectives include identifying exploitable vulnerabilities, evaluating the effectiveness of existing security measures, and testing the response capabilities of the security team.
  • Scope
    In-scope Resources: Working with the customer stakeholders we then determine which  of the web application environments resources, services and data are included in the test. This includes specifying environments (production or non-production), types of data, and services like VMs, databases, and storage accounts. Clearly defining the scope helps prevent unauthorised access to sensitive areas and ensures compliance with both organisational policies and external regulations.
    Limitations: Clear boundaries are set to avoid any impact on production systems or data. This includes time frames for testing to minimise disruption to normal business operations.
  • Compliance and Regulations
  • We ensure that the testing activities align with relevant legal and regulatory  guidelines.

Pre-Flight Checks

  • Stakeholder Briefing (optional dependent on the customer): We hold a meeting with all relevant stakeholders to review the test plan, confirm scope, and discuss any potential concerns or limitations.
  • Logistical Arrangements: We ensure all necessary tools, access credentials, and resources are in place before the testing begins. This includes setting up secure channels for data collection and reporting.
  • Legal and Ethical Compliance: As part of the pre-flight checks we re-confirm that all testing activities are authorised and documented, with special attention to ethical considerations and data protection laws.

Stages of Web Application Penetration Testing

The ProCheckUp Web Application Penetration Testing Methodology is an enhanced Methodology that augments the OWASP web application testing methodology with the Crest, Check and PCI requirements.

Information Gathering

The "Information Gathering" phase is crucial as it sets the foundation for identifying potential vulnerabilities and planning subsequent testing strategies. This phase involves collecting as much information as possible about the web application and its environment, which helps us to understand the attack surface..

Conduct Search Engine Discovery and Reconnaissance for Information Leakage

  • We use Open-Source Intelligence (OSINT) techniques: to collect data about the target organisation. Utilising search engines like Google, Bing, and others to discover publicly available information that could reveal insights into the application’s architecture, technologies used, and potential entry points.We use advanced search operators to find specific file types, sensitive directories, accidentally exposed documents, and employee details.
  • DNS and Service Enumeration: We employ tools to scan for DNS records and visible services that can be accessed. Tools like third-party scanners can provide insights into the services exposed to the internet.
  • Identifying Entry Points: We determine potential entry points for attacks, using public records of SSL certificates issued to identify publicly exposed APIs, web applications, and management interfaces that could provide initial access to the environment.
  • Security Policy Review (optional): We analyse the security policies applied across underlying web application environment to understand the controls in place. This review can help identify potential misconfigurations or overly permissive settings that could be exploited.

Fingerprinting The Web Server

  • We then determine the web server type, version, and configuration settings. Knowing the server details can help identify known vulnerabilities specific to the versions identified in use. Using tools like Nmap and Shodan to gather comprehensive server information.

Review Webserver Metafiles for Information Leakage

  • We examine files like robots.txt and .htaccess that might inadvertently reveal directory structures or the file locations.

Enumerate Applications on The Web Server

  • We identify all applications hosted on the server, noting versions and configurations, to map the full attack surface. By checking directories, virtual hosts, and existing applications for version information and entry points.

Review Webpage Comments and Metadata for Information Leakage

  • We scrutinise HTML, CSS, and JavaScript files for developer comments that might contain sensitive information such as internal IP addresses, deprecated features, or upcoming changes. Using tools like BurpSuite Pro to automate the extraction and analysis of comments.

Identify the Web Application Entry Points

  • We catalog all user input fields, API endpoints, and interaction points. These are potential vectors for injection attacks and other exploits.We use automated tools like Burp Suite to interact with the application and identify how and where it accepts user input.

Map Execution Paths Through the Web Application

  • We then understand the flow of data through the application, identifying critical processing points such as form submissions or login processes. We use both static and dynamic analysis tools to trace how data moves through the application.

Fingerprint The Web Application Frameworks Used

  • We then Identify the frameworks and libraries used by the web application, such as Angular, React, or Django. This helps us to understand the specific framework vulnerabilities.We examine HTTP headers, file structures, or specific files like manifest.json or bundle.js.

Map Application Architecture (White box and Grey Box Testing)

  • If within the scope of the engagement, we then document the architecture of the web application including all interconnected systems like databases, third-party services, and internal APIs. We diagram the relationships and data flows between components to identify potential areas where data might be exposed or intercepted.

Configuration and Deployment Management Testing

The "Configuration and Deployment Management Testing" phase of our Web Application Penetration Testing methodology, is a critical phase where the security configurations of both the application and its supporting infrastructure are thoroughly evaluated. This testing helps identify misconfigurations, outdated components, and improper security controls that could expose the web application to potential attacks.

This testing  phase is vital for several reasons:

  • Security Posture: Proper configuration of network and application platforms is foundational to a secure web application.
  • Prevent Data Breaches: Correct file permissions and handling, along with secure admin interfaces, are crucial to preventing unauthorised data access.
  • Compliance: Many regulatory frameworks require secure configurations as part of their compliance standards.

Test Network/Infrastructure Configuration

  • We examine the network setup and infrastructure configurations to ensure they are secure and conform to best practices. This includes checking firewall rules, router configurations, and other network appliances.We utilise network scanning tools like Nmap, Nessus, or network configuration management software to detect unprotected services, open ports, and other vulnerabilities that may be present due to misconfiguration.

IP/URL identification  and Asset Discovery

  • IP and URL Identification: We use the collected public data  to determine the applicable IP addresses and URL's for the penetration test. This includes SSL certificate information that has been made public.
  • Asset Inventory: We utilise third-party tools to list all assets within the scope, categorising them by type (e.g., VMs, containers, and other networked devices.).

Port and Service Enumeration

  • Network Scanning: We use network scanning tools to identify open ports and services. Tools like Nmap, Masscan  to scan IP addresses and URL's associated with the Web Application to find entry points and detect open ports that could indicate running services.
  • Service Detection: For each open port, we determine the service type including web servers, database services, and cloud-specific services.
  • Configuration Review: We examine the configuration of these services to identify weak security practices such as default settings, unnecessary services, or deprecated protocols to ensure that data transmitted over the Internet is securely encrypted.

Vulnerability Scanning

  • Automated Scanning: Once the open ports are identified, we further enumerate the types of services running on those ports using tools like Nessus Professional or Qualys that can detect common misconfigurations and known security flaws.
  • Custom Scripts and Tools:  We deploy scripts designed to uncover the web application environmental-specific misconfigurations or inadequacies, especially those not typically identified by generic scanning tools.
  • Simulate Network Attacks: We use tools like Metasploit to test the effectiveness of network controls against simulated attacks.
  • Web Application Scanning: We then use web application scanners like Burp Suite professional and Qualys Web Application scanning to discover and catalog web applications, APIs, and their endpoints that are hosted within the web application environment. And to identify vulnerabilities, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
  • API Testing: We test exposed APIs for security issues related to authentication, authorisation, and data validation, which are critical in cloud environments

Test File Extension Handling for Sensitive Information

  • We ensure that the web application handles file extensions securely, particularly those that can execute code or contain sensitive information. We perform manual and automated testing to attempt to upload and execute various file types. Check if the server properly handles these files to prevent execution and leakage of sensitive data. This includes checks if the server is running antivirus.

Review Old, Backup and Unreferenced Files for Sensitive Information

  • We identify outdated, backup, and unreferenced files that may still reside on the system and contain sensitive information or introduce vulnerabilities. We use tools like dirbuster to scan directories for old and backup files. Manually reviewing the content of these files to check for sensitive data or information about the application’s architecture.

Enumerate Infrastructure and Application Admin Interfaces

  • We discover and then evaluate any administrative interfaces for the infrastructure or application to ensure they are secure and properly restricted. We check for common admin paths, and try default login credentials. We review the port scanning results to discover hidden services and interfaces.

Test HTTP Methods

  • We assess the HTTP methods enabled on the server (e.g., GET, POST, DELETE, PUT) and ensure that only necessary methods are available to prevent misuse. We use tools like Curl or Burp Suite to test various HTTP methods and identify improper server responses or unauthorised access.

 Test HTTP Strict Transport Security

  • We confirm that HTTP Strict Transport Security (HSTS) is properly implemented to force HTTPS on all communications and avoid SSL stripping attacks. We check the headers returned from web requests for the presence of the Strict-Transport-Security header with an appropriate max-age directive.

Test RIA Cross Domain Policy

  • We review the cross-domain policies (such as crossdomain.xml in Flash or clientaccesspolicy.xml in Silverlight) to ensure they do not permit data leakage or cross-site scripting. We review the policy files for overly permissive settings and test for cross-domain data access vulnerabilities.

Test File Permissions

  • We verify that files and directories have appropriate permissions set to prevent unauthorized access or modification. We use tools and scripts to analyse file and directory permissions, ensuring sensitive files are not accessible or writable by unauthorized users

Risk Identification

  • Threat Modeling (optional CSTAR approach) : If within the scope of the engagement, based on gathered data, we develop threat models that describe potential attack vectors specific to the organisation's  web applications environment environment. Considering both external and insider threats.(Learn More)

Build Review - Test Application Platform Configuration (Optional)

  • If within the scope of the engagement, we evaluate the configurations of the web server, application server, and database server. This includes checking for default settings, unnecessary services, and ensuring secure communication protocols are used. We use automated configuration scanning/build review tools and manual review to identify potential configuration weaknesses like unnecessary database permissions, or insecure file permissions.

Directory and Access Enumeration (Optional)

  • Environmental Active Directory (AD) Scanning (optional configuration review) :
  • If within the scope of the engagement, we enumerate the environments AD to gather information on user accounts, roles, and permissions. Tools like BloodHound or custom PowerShell scripts are employed to visualise privilege relationships and identify misconfigurations for vulnerabilities like overly permissive access, which could be exploited during later phases.(Learn More)
  • Storage Access Evaluation: We check storage accounts and databases for improper permissions or exposed sensitive data.

Security Group and Network ACL Analysis

  • Virtual Network Analysis (optional segmentation testing):
  • If within the scope of the engagement, we assess the segmentation and isolation practices within the web application's environment  to identify potential lateral movement pathways. for vulnerabilities like overly permissive access, which could be exploited during later phases.(Learn More)
  • Review The Web Application's environment Firewall and Network Controls (optional firewall review): If within the scope of the engagement, we analyse firewall rules that control inbound and outbound traffic to the environment resources to identify overly permissive settings or configuration errors.(Learn More)

Gaining Access

The "Gaining Access" phase of our Web Application Penetration Testing methodology focuses on leveraging the identified vulnerabilities to achieve unauthorised and later authorised access to systems, services, or data within the Web Applications environment to gain access to restricted areas or information. This stage is critical as it demonstrates the practical impact of vulnerabilities and helps assess the real-world threats that an organisation may face.


  • Exploitation of Known Vulnerabilities: We utilise known exploits or develop custom exploits based on the vulnerabilities identified earlier in software, configurations, of the Web Application. Tools such as Metasploit can be instrumental in this stage for deploying payloads that exploit these weaknesses.
  • Use of Exploit Kits: Depending on the complexity and nature of the web application, specialised exploit kits may be used to streamline the exploitation process.

Lateral Movement

  • Session Hijacking: We utilise the initial foothold to explore further into the web applications environment, accessing additional resources and escalating privileges where possible.
  • Cross-Service Exploitation/Chained exploits: Utilising access obtained from one service, we aim to compromise other interconnected services or applications, such as moving from the Web Applications API Services to its SQL databases.

Data Encryption Verification

  • Encryption at Rest: We confirm that sensitive data stored in file-systems and back-end SQL databases is encrypted at rest, providing essential data protection against unauthorised access.
  • Encryption in Transit: Ensure that data transmitted between services  (for example, from  web/application servers to back-end databases) is adequately encrypted, preventing data interception during transmission.

Social Engineering and Phishing (optional)

If within the scope of the engagement, we use techniques like phishing to gain credentials or other sensitive information from legitimate users.

  • Phishing Attacks: We conduct targeted phishing campaigns to deceive users into providing their credentials or executing malicious software that provides backdoor access.
  • Spear Phishing: We use more personalized approaches in phishing to target specific individuals who have elevated privileges within the Web applications environment.

Identity Management Testing

The "Identity Management Testing" phase of our Web Application Penetration Testing methodology, focuses on the processes and controls related to managing user identities within a web application. This phase aims to ensure that user identity management is robust, secure, and capable of preventing unauthorized access.

This testing  phase is vital for several reasons:

  • Prevention of Unauthorised Access: Robust identity management ensures that only authorized users can access sensitive functionalities and data.
  • Data Integrity and Confidentiality: Proper user roles and permissions help maintain data integrity and confidentiality by restricting data access to authorized personnel only.
  • Regulatory Compliance: Many compliance standards require strong identity and access management controls to protect user data and privacy.

Test Role Definitions

  • We ensure that the role definitions within the application enforce the principle of least privilege effectively. Roles should be clearly defined and limited to only the necessary permissions for the tasks users are meant to perform. We review the role configurations and permissions settings. Test by switching roles and verifying within Burp Professional that access limits are enforced according to the role definitions.

Test User Registration Process

  • We evaluate the security of the user registration process to ensure that it prevents automated sign-ups and enforces strong authentication practices. We attempt to register with weak passwords, use automation scripts or Burp Professional scripts to simulate bulk registrations, and check for CAPTCHA or other anti-bot measures.

Test Account Provisioning Process (optional process review)

  • If within the scope of the engagement, we assess the procedures involved in account provisioning to ensure they do not introduce security vulnerabilities, such as granting excessive permissions or failing to verify new accounts properly.We  trace the account creation process from start to finish, examining how new accounts are verified, activated, and assigned roles.

Testing for Account Enumeration and Guessable User Account (optional)

  • We determine if the web application allows attackers to enumerate user accounts or guess user account details through error messages or predictable user ID patterns. We conduct tests like submitting numerous failed login attempts or registration processes using Burp Repeater to see if the application reveals whether email addresses or usernames are valid.

 Testing for Weak or Unenforced Username Policy

  • We check if the application’s username policies are robust enough to prevent easily guessable usernames.We attempt to create accounts with simple or commonly used usernames to test the effectiveness of username policies.

Authentication Testing

The "Authentication Testing " phase of our Web Application Penetration Testing methodology, focuses on examining the mechanisms that verify the user's identity to ensure that they are both secure and effective. This stage of penetration testing is crucial because vulnerabilities in authentication can allow unauthorized access, leading to potential breaches and data theft.

This testing  phase is vital for several reasons:

  • Prevention of Unauthorised Access: Weak authentication can lead to unauthorised access, which is one of the most direct paths to sensitive data and system functionality. 
  • Data Integrity and Confidentiality: Authentication testing is vital because it directly impacts the security of user access controls
  • Regulatory Compliance: Many compliance standards require strong identity and access management controls to protect user data and privacy.

Testing for Credentials Transported over an Encrypted Channel

  • We test that all credentials are transmitted over secure, encrypted channels to prevent interception by malicious parties. We use tools like Wireshark or Burp Suite to monitor the data transmitted during authentication processes and verify that HTTPS or other secure protocols are used.

Testing for Default Credentials

  • We identify if default credentials provided by system manufacturers or software providers are still in use, which are a common vector for attacks. We attempt to log in using known default usernames and passwords or use scripts to do the same. This can include administrative credentials that have not been changed post-installation.

Testing for Weak Lock Out Mechanisms

  • We evaluate the effectiveness of the account lockout mechanisms after several failed login attempts to prevent brute force attacks. We conduct brute force attacks on the supplied user accounts to see if and when the account gets locked and how the application handles the lockout.

Testing for Bypassing Authentication Schema

  • We test the robustness of the authentication scheme to determine if there are ways to bypass it entirely. We employ various methods such as session hijacking, modification of session tokens, or manipulation of hidden fields to attempt to bypass the login process.

Testing the Remember Password Functionality

  • We evaluate if the 'remember me' functionality is implemented securely without allowing an attacker to hijack sessions or steal credentials.We analyse how the authentication tokens stored in cookies are secured and managed, checking for flags such as HttpOnly and Secure.

Testing for Browser Cache Weakness

  • We determine if sensitive information from the authentication process is stored insecurely in the browser cache.We check for sensitive data storage in browser cache through browser settings and inspect the cache storage manually after authenticating.

Testing for Weak Password Policy

  • We verify that the application enforces a strong password policy, reducing the risk of passwords being easily guessed or cracked. We attempt to register or change passwords to simple or commonly used passwords to test the enforcement of password complexity requirements

Testing for Weak Security Question/Answers

  • We assess the security of password recovery mechanisms that utilise security questions, ensuring they cannot be easily guessed. We analyse the difficulty of security questions and attempt to reset passwords using easily accessible or guessable information.

Testing for Weak Password Change or Reset Functionalities

  • We evaluate the security of mechanisms for changing or resetting passwords to ensure they do not introduce vulnerabilities. We attempt to change passwords without proper authorisation, or try intercepting reset links or tokens to check for vulnerabilities.

Testing for Weaker Authentication in Alternative Channel

  • We evaluate that the alternate authentication methods, such as mobile or email OTP, voice recognition, etc., maintain the same level of security as the primary authentication method. We test alternative channels for authentication weaknesses, such as susceptibility to interception or replay attacks.

Authorization Testing

The "Authorization Testing " phase of our Web Application Penetration Testing methodology, that scrutinises the controls that manage user permissions and ensure that users can only perform actions allowed by their privileges. This phase is crucial because flaws in authorisation can lead to unauthorized information disclosure, data modification, or execution of privileged operations.

This testing  phase is vital for several reasons:

  • Unauthorised Access: Ensures users cannot perform actions outside of their designated permissions.

  • Data Breaches: Protects sensitive data from being accessed or manipulated by unauthorized users.

  • Compliance Issues: Helps maintain compliance with regulations that require stringent data access controls, such as GDPR, HIPAA, or PCI DSS.

Testing Directory traversal/file include

  • We validate that the application properly restricts file access, preventing users from accessing files or directories outside of their intended permissions. We attempt to access files and directories that should not be accessible by manipulating input paths in URL parameters or file requests, such as using "../" patterns (directory traversal) or including files from external sources (file inclusion).

Testing for bypassing the authorisation schema

  • We verify that all mechanisms in place to enforce user permissions are robust and cannot be bypassed.We try accessing functionalities that should be restricted by manipulating session tokens, cookies, or crafting specialised requests to bypass normal authorization checks.

Testing for Privilege Escalation

  • We validate if lower-privileged users can escalate their privileges to access data or functions reserved for higher-privileged users. We modify user roles, access rights, or session information to attempt privilege escalation; this includes both vertical escalation (user to admin) and horizontal escalation (accessing data of another user at the same privilege level).

Testing for Insecure Direct Object References

  • Objective: We check for vulnerabilities that allow users to access objects directly by altering parameter values in the URL or request (e.g., database record identifiers). We manipulate reference numbers or strings in URLs or POST data to attempt to access unauthorised resources or actions. Monitor whether the system adequately checks for user permissions before serving these requests.

Session Management Testing

The "Session Management Testing" phase of our Web Application Penetration Testing methodology, focuses on ensuring that the web application correctly manages user sessions, protecting against attacks that exploit session management vulnerabilities. Effective session management is crucial for maintaining the integrity and security of user sessions throughout their interaction with the web application..

This testing  phase is vital for several reasons:

  • Protect User Data: Prevent unauthorised access to user sessions, thereby safeguarding user data.
  • Maintain Integrity: Ensure that user actions are performed securely and reliably during their session.
  • Enhance Security Posture: Addressing session management vulnerabilities contributes to the overall strengthening of the application’s security architecture.

Testing for Bypassing Session Management Schema

  • We evaluate the robustness of the session management controls to ensure they cannot be bypassed or manipulated.By attempting various attacks such as session fixation, where an attacker sets a user's session ID before they log in, or session hijacking, where an attacker takes over a user's session after they've authenticated.

Testing for Cookies Attributes

  • We ensure that cookies used in managing sessions have secure attributes set, such as HttpOnly, Secure, and SameSite. We:inspect cookies set by the application during and after authentication to verify that these attributes are correctly implemented to prevent cookies from being accessed by client-side scripts or transmitted over insecure connections.

Testing for Session Fixation

  • We test the application for vulnerabilities that allow session fixation attacks, where an attacker can force a specific session ID on a user. We try to inject or assign a known session ID and use that session ID to authenticate as the user, examining whether the application allows the session ID to persist through the authentication process.

Testing for Exposed Session Variables

  • We check if sensitive session variables such as authentication tokens are exposed through the client-side code or can be manipulated via the client. We review JavaScript and client-side code for exposure of sensitive session information and attempt to manipulate session variables using tools like browser developer tools or proxy tools.

Testing for Cross Site Request Forgery (CSRF)

  • We test that the application is not vulnerable to CSRF attacks, where an attacker can trick a user into performing actions that they are authenticated to do. We test for the presence of anti-CSRF tokens in state-changing requests and attempt CSRF attacks by crafting malicious requests that mimic legitimate requests from an authenticated user.

Testing for Logout Functionality

  • We verify that the logout functionality works correctly, ensuring that all session tokens are invalidated upon logout. We log out from the application and then attempt to reuse the previous session cookie(s) to access the application. And then check the server responses to ensure that the session is truly invalidated.

Test Session Timeout

  • We validate that the application properly times out inactive sessions to reduce the risk of session hijacking. We leave a session idle and attempt to perform actions after different periods of inactivity to see if the application enforces session expiration.

Testing for Session Puzzling

  • We test for session puzzling issues where an application does not properly handle simultaneous requests in a single session that can lead to logic flaws.We perform concurrent requests with conflicting or varied data using the same session tokens to see how the application handles these scenarios.

Input Validation Testing

The "Input Validation Testing" phase of our Web Application Penetration Testing methodology, is a critical component of web application penetration testing. This phase focuses on verifying that the application properly validates user and system input to prevent common vulnerabilities such as SQL injection, Cross-Site Scripting (XSS), and other injection flaws. Proper input validation is essential for securing the application against malicious data that could exploit the logic of the application..

This testing  phase is vital for several reasons:

  • Prevents Malicious Data Processing: Ensures that the application only processes appropriate and expected data.
  • Reduces Exploit Risks: Mitigates the risk of code injection, which can lead to data loss, corruption, unauthorized access, and other security breaches.
  • Enhances Application Stability and Security: Protects the integrity of application logic and maintains secure operations.

Testing for Reflected Cross Site Scripting

  • We validate if the application properly sanitises user input to prevent XSS where malicious scripts are reflected back to the user's browser. We input malicious JavaScript codes in forms, URL parameters, or any input vectors to see if they are executed in the browser.

Testing for Stored Cross Site Scripting

  • We ensure the application prevents user inputs containing malicious scripts from being permanently stored and later presented to users. We submit scripts through input fields that save data (like comments, profiles) and check if these scripts are executed on subsequent page views

Testing for HTTP Verb Tampering

  • We assess if the application responds appropriately to various HTTP methods or verbs that could alter the application state.We use tools like Burp Suite to send requests with different HTTP methods (PUT, DELETE, TRACE, etc.) and identify if unauthorised actions are possible.

Testing for HTTP Parameter Pollution

  • We evaluate the resilience of the application against attacks involving the manipulation of query string parameters.We inject multiple instances of the same parameter in HTTP requests to see if the application mishandles the input, leading to potential exploits.

Testing for SQL Injection

Involves examining the web application for vulnerabilities that allow an attacker to execute arbitrary SQL commands through the user input fields. SQL injection attacks can lead to unauthorised access to or manipulation of database information. Effective testing must consider the specifics of the database management system in use, as each system has unique features and vulnerabilities.

SQL: Oracle Testing

  • We verify SQL injection vulnerabilities in applications that use Oracle databases, by testing for typical SQL injection payloads such as ' OR '1'='1, but also Oracle-specific specific syntax to bypass standard SQL injection defenses, such as using alternative concatenation operators or exploiting Oracle functions.. We check for Oracle error messages that might reveal information about the database structure.

SQL: MySQL Testing

  • Objective: Focus on identifying SQL injection flaws in applications backed by MySQL databases.By 
    leveraging MySQL's string concatenation functions, format specifiers, and delay functions like SLEEP() to construct time-based blind SQL injection attacks. We explore vulnerabilities specific to MySQL such as the handling of escape characters or the batched queries using semicolons.

SQL: MS SQL Server Testing

  • We test for SQL injection vulnerabilities in systems utilising Microsoft SQL Server.By using payloads that exploit the EXEC command to run arbitrary SQL code.We test for out-of-band SQL injection by exploiting SQL Server’s ability to make DNS requests or HTTP requests using xp_dirtree, xp_fileexist, or similar extended stored procedures.Investigate the potential for error-based SQL injection by inducing errors that will return information about the database.

SQL: Testing PostgreSQL

  • We test for SQL injection vulnerabilities in applications using PostgreSQL databases. We exploit PostgreSQL's array functions and type casts to bypass input validation.and experiment with stacked queries and PostgreSQL-specific functions like COPY TO/FROM PROGRAM to perform command execution. We use the pg_sleep() function to facilitate time-based SQL injection tests.

SQL: MS Access Testing

  • We identify SQL injection issues in applications that interact with Microsoft Access databases. We
    test for simplistic payloads as Access does not support multiple queries in a single SQL statement. We use union-based SQL injection to extract data, focusing on the differences in SQL syntax between Access and other SQL databases.

SQL: Testing for NoSQL Injection

  • We examine NoSQL databases like MongoDB for injection vulnerabilities, which differ significantly from traditional SQL injection. We test for injection by supplying malformed JSON or JavaScript objects in inputs that interact with the database.We leverage MongoDB operators such as $gt, $ne, or $regex in user inputs to alter query logic.We explore the application’s handling of BSON (Binary JSON) and JavaScript code, often used in NoSQL queries, to perform unauthorized actions or retrieve data.

Testing for LDAP Injection

  • We evaluate how the application handles input used in constructing LDAP queries to prevent attackers from altering LDAP statements. We inject malicious LDAP statements through input fields to test if the application improperly filters input, potentially allowing unauthorised access.

Testing for ORM Injection

  • We test for vulnerabilities in Object Relational Mapping (ORM) that allow attackers to inject malicious input.We use ORM specific payloads to manipulate ORM queries through input fields, checking for improper handling of input.

Testing for XML Injection

  • We test for flaws in XML parsers and processing that could allow an attacker to inject malicious content.
    Techniques: Manipulate XML data inputs to test if the application fails to properly sanitise input, potentially allowing XML-related attacks like XXE

Testing for SSI Injection

  • We assess the application's vulnerability to Server-Side Includes (SSI) injection, which could lead to the execution of server-side commands. We inject SSI directives into input fields to see if they are executed by the server.

Testing for XPath Injection

  • We evaluate security measures against XPath injection attacks that could allow unauthorised access to XML documents.We use XPath injection techniques in any XML or XPath input fields to attempt to alter document structure or retrieve hidden data.

IMAP/SMTP Injection

  • We identify vulnerabilities where malicious commands are injected into IMAP or SMTP sessions. We craft inputs that may be interpreted by mail servers as commands, for instance by including CR (carriage return) or LF (line feed) characters to manipulate SMTP or IMAP server responses or actions. We test email fields or any feature interacting with mail servers for response splitting or unexpected command execution.

Testing for Code Injection

Code injection flaws occur when an attacker can introduce malicious code into a software system.

Code: Testing for Local File Inclusion

  • We determine if local files can be included in output, leading to information disclosure or server-side code execution. We manipulate file paths in URL parameters or input fields to include files that exist on the server, like configuration files or logs.

Code: Testing for Remote File Inclusion

  • We assess if external or remote files can be included or executed through the web application.
    Technique: Try to exploit any feature that fetches and executes files from a remote location by providing URLs pointing to files that the attacker controls.

Testing for Command Injection

  • We identify instances where shell commands injected through web inputs are executed on the server.We Input shell commands into form fields, URL parameters, or HTTP headers, looking for ways to escape the context of the input and execute commands.

Testing for Buffer Overflows

Buffer overflows can lead to arbitrary code execution, application crashes, or other unexpected behaviors.

Buffer: Testing for Heap Overflow

  • We test dynamic memory allocation for overflows that corrupt heap data.We attempt to overflow application buffers by providing input that exceeds the expected size, whilst monitoring application stability or behavior for signs of memory corruption.

Buffer: Testing for Stack Overflow

  • We check for vulnerabilities where the call stack is overflowed by user input.We provide excessive input data to functions that store data in stack-allocated buffers, particularly in languages susceptible to stack overflows like C or C++.

Buffer: Testing for Format String

  • We exploit format string vulnerabilities typically found in unmanaged code. We input format specifiers (e.g., %s, %x, %n) into text fields to try and manipulate the output or execute arbitrary memory addresses.

Testing for Incubated Vulnerabilities

  • We identify vulnerabilities that may not provide immediate gains for an attacker but can be combined with other exploits.We investigate lesser-known or low-severity issues that could lead to more significant vulnerabilities when chained with other exploits.

Testing for HTTP Splitting/Smuggling

  • We check if it's possible to manipulate HTTP headers and methods to perform HTTP response splitting or smuggling. We inject CR/LF characters into inputs that affect HTTP headers to alter response headers or split responses, potentially leading to cache poisoning or cross-user attacks.

Testing for HTTP Incoming Requests

  • We assess the handling of incoming HTTP requests for potential vulnerabilities. We monitor how the application processes incoming HTTP requests, testing for improper handling of methods, headers, or payloads that could lead to unauthorized access or information disclosure.

Testing for Error Handling

The "Testing for Error Handling" phase of our Web Application Penetration Testing methodology, evaluates how well an application manages errors, focusing on security and information leakage that could benefit an attacker leading to further exploitation

Analysis of Error Codes

  • We ensure that error codes do not disclose too much information about the architecture, design, or state of the application. We deliberately induce errors in the application to observe the error messages and codes returned. Analysing these messages for information that could aid an attacker, such as software versions, database table names, or details about the underlying technology stack.

Analysis of Stack Traces

  •  We validate if the exposure of stack traces to the end users occurs, as they can provide attackers with guidance on further exploitation opportunities. We trigger exceptions in the application and review the responses for stack traces. This is often done by inputting unexpected values (fuzzing) or malformed data to cause the application to crash or behave unexpectedly.

Testing for Weak Cryptography

The "Testing for Weak Cryptography" phase of our Web Application Penetration Testing methodology, is crucial in ensuring that the encryption techniques and the implementation of cryptographic functions in a web application adequately protect data against unauthorised access and modifications. This testing category focuses on identifying vulnerabilities associated with using outdated algorithms, weak keys, improper configurations, or faulty implementations that could compromise the security of the application.

This testing  phase is vital for several reasons:

  • Data Breaches: Weak cryptography can lead to several risks including data breaches, unauthorized data modifications, and exposure of sensitive information.
  • Compliance Issues: Ensuring robust cryptography is used not only helps in protecting data but also in maintaining trust with users and compliance with regulatory requirements like GDPR, PCI-DSS, and HIPAA, which mandate the use of strong encryption methods to protect data privacy and integrity.

Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection

  • We validate that only strong, secure cryptographic ciphers are used in SSL/TLS configurations to protect data during transmission. We use tools like SSL Labs' SSL Test, OpenSSL, or TestSSL.sh to scan the SSL/TLS configurations of the web server. These tools check for the presence of weak ciphers such as RC4 or DES, SSL versions 2 or 3, and weak key exchanges. They also review certificate chains for validity and configuration errors.

Testing for Padding Oracle

  • We detect vulnerabilities that allow attackers to decrypt data by manipulating the padding of encrypted messages, commonly found in CBC mode encryption. We perform active attacks using tools like Burp Suite’s Padding Oracle tool or scripts that systematically modify ciphertexts and observe the application's responses to determine if information on the padding validity is leaked, which can subsequently be used to decrypt data.

Testing for Sensitive Information Sent via Unencrypted Channels

  • We ensure that all sensitive data is transmitted over encrypted channels to prevent interception by unauthorised parties. We monitor network traffic using tools such as Wireshark or tcpdump to capture data packets. We then analyse these packets for any sensitive information (like passwords, credit card data, personal information) being sent over non-HTTPS or other unencrypted protocols.

Testing for Weak Encryption

  • We identify the use of encryption algorithms or protocols that are known to be weak and susceptible to decryption by attackers. We review the application’s codebase and configuration files for encryption methods.We look for the usage of deprecated algorithms like MD5 or SHA-1, small key sizes (e.g., RSA keys under 2048 bits), or improper usage of strong algorithms that could lead to vulnerabilities (e.g., ECB mode in block ciphers).

Business Logic Testing

The "Business Logic Testing" phase of our Web Application Penetration Testing methodology, is essential in identifying security vulnerabilities that arise from flaws or weaknesses in the application's processes, workflows, or functional operations. Unlike lower-level technical vulnerabilities, business logic errors typically involve legitimate use of the application's features in unintended ways that could compromise security.The main goal of business logic testing is to evaluate the application's logic, ensuring that it enforces the correct business rules and restrictions under various scenarios. This involves simulating user behavior and attempting to manipulate or circumvent the application’s intended use to uncover security flaws.

This testing phase is vital for several reasons:

  • Protection of Application-Specific Processes:Each application has unique functionalities and workflows that are tailored to specific business needs. Business logic testing ensures that these specific processes are secure and cannot be abused, circumvented, or used in a way that could harm the business or its customers.
  • Prevention of Fraud and Abuse:Many business logic vulnerabilities can be exploited to commit fraud or other types of abuse that may not immediately lead to data breaches but can still result in significant financial or reputational damage. For example, exploiting a flaw in a transaction system that allows a user to bypass payment processes or obtain unauthorised services.
  • Ensuring Data Integrity: Ensuring that business rules enforce the integrity of transactions and data manipulations is crucial. Business logic testing verifies that operations such as data entries, updates, and deletions are performed correctly and securely, preserving the integrity and trustworthiness of data throughout the application.
  • Regulatory Compliance:Many industries are subject to strict regulatory requirements that dictate how data must be handled and protected. Business logic testing helps ensure compliance by verifying that the application adheres to these regulations through proper implementation of business rules and processes.

Test Business Logic Data Validation

  • We ensure that all user inputs are validated according to business rules before processing. We test inputs for different data types and boundary values to check if the application improperly processes unexpected or incorrect data.

Test Ability to Forge Requests

  • We determine if users can manipulate requests to bypass the intended business logic, potentially leading to unauthorized actions or data access. We use tools like Burp Suite to modify requests, parameters, and headers to attempt actions beyond a user’s privileges or intended use cases.

Test Integrity Checks

  • We verify that all actions on data are properly checked for integrity, ensuring that data manipulation or transfer adheres to business rules. We manipulate data in transit or storage and observe whether the application detects and reacts appropriately to the integrity violation.

Test for Process Timing

  • We check if the application handles timing issues correctly, such as performing actions in a specific order or within certain time frames.We perform actions out of order or simulate race conditions to see if the application fails to enforce process timings, potentially allowing actions that should be blocked or managed differently.

Test Number of Times a Function Can be Used Limits

  • We ensure that the application enforces limits on the number of times a function can be used or invoked.We attempt to exceed usage limits to determine if the application properly enforces restrictions based on business rules.

Testing for the Circumvention of Work Flows

  • We identify if users can bypass required steps in workflows, potentially skipping necessary checks or actions. We attempt to complete application workflows in non-standard ways to check if all required steps are enforced.

Test Defenses Against Application Misuse

  • We assess the robustness of the application's defenses against misuse or abusive behavior.
    Technique: Simulate misuse scenarios like rapid submission of forms, simultaneous requests, or abuse of functionalities to test the application’s response and resilience.

Test Upload of Unexpected File Types

  • We verify that the application correctly handles file uploads, restricting file types according to business needs and security policies. We upload various unexpected or prohibited file types to test the application’s filtering and validation mechanisms.

Test Upload of Malicious Files

  • We ensure the application can identify and block uploads containing malicious content. We attempt to upload files that contain scripts, executables, or other potentially dangerous content to see if the application properly scans and blocks these files.

Client Side Testing

The "Client Side Testing" phase of our Web Application Penetration Testing methodology, is crucial because vulnerabilities on the client side can be exploited to manipulate application behaviors, steal sensitive information, or trick users into executing malicious actions. This testing phase assesses the security of the JavaScript code, HTML, and CSS, and other client-side resources.

This testing phase is vital for several reasons:

  • Exposure to Wide Audience: Client-side code is accessible to anyone using the application, making it a prime target for attackers who can examine the code and exploit any vulnerabilities they find.
  • Impact on User Security: Vulnerabilities like cross-site scripting (XSS) or insecure data storage directly affect the end users' security, potentially leading to data breaches or other exploits that compromise user privacy.
  • Complexity of Client-Side Logic: Modern applications often handle significant logic on the client side, including data validation, rendering, and processing. Errors in this logic can lead to security flaws that are only exploitable on the client side..

Testing for DOM-based Cross-Site Scripting

  • We ensure that the application is not vulnerable to DOM-based XSS, where malicious scripts are injected through client-side scripting. We manipulate DOM elements dynamically to inject harmful scripts and observe if they execute without proper sanitisation.

Testing for JavaScript Execution

  • We identify issues in JavaScript handling that could allow for unintended script execution.We input unexpected JavaScript commands into form fields, URLs, or other input vectors to test for JavaScript execution vulnerabilities.

Testing for HTML Injection

  • We conduct tests to prevent attackers from injecting arbitrary HTML content into the web page, which could alter the page's content or steal information.We inject HTML tags through user inputs and monitor if they are executed as part of the HTML DOM.

Testing for Client-Side URL Redirect

  • We check for vulnerabilities that allow unauthorised redirection to malicious websites.We craft URLs that manipulate redirection logic to redirect users to unintended websites or malicious sites.

Testing for CSS Injection

  • We determine if it's possible to inject custom CSS rules that could alter the appearance of the web page or be used for phishing attacks. We attempt to include external CSS styles or inline styles in user inputs to see if they are applied.

Testing for Client-Side Resource Manipulation

  • We ensure that client-side resources like cookies, localStorage, and sessionStorage are secure against unauthorized access and manipulation.We manipulate client-side storage objects to test for vulnerabilities like improper access controls or data exposure.

Test Cross-Origin Resource Sharing

  • We Verify that CORS policies are correctly implemented to prevent unauthorized cross-origin requests.
    Approach: Conduct tests to attempt accessing resources from different origins to evaluate CORS settings.

Testing for Cross-Site Flashing

  • We identify vulnerabilities related to Flash files that could be used to execute cross-site scripting or other malicious activities. We test for Flash parameter injection and cross-site loading issues.

Testing for Clickjacking

  • We assess if the application is vulnerable to clickjacking attacks, where users are tricked into clicking something different than expected. We use framing techniques to overlay transparent or opaque layers over the application to trick users into performing unintended actions.

Testing WebSockets

  • We ensure that WebSocket connections are secure and cannot be hijacked or manipulated. We test for vulnerabilities in the WebSocket handshake process and data transfer integrity.

Test Web Messaging

  • We verify the security of web messaging implementations, particularly postMessage use, to prevent cross-origin script attacks. Se send messages between different origins and test if messages are properly validated before processing.

Test Local Storage

  • We confirm that data stored in local storage is protected from unauthorised access and manipulation. We attempt to access or manipulate localStorage data from different contexts or origins. 

Maintaining Access and Lateral Movement (optional)

If within the scope of the engagement the "Maintaining Access and Lateral Movement" phase of our Web Application Penetration Testing methodology involves establishing persistent access to the environment and explores ways to expand control over additional resources and data. By mimicking the behavior of Advanced Persistent Threats (APT), we assess the depth of any potential breach and understand how an attacker could embed themselves into the system. The lateral movement part of this phase uses techniques to navigate through the Web Applications environment, expanding access from the initial foothold to other systems and resources.


Establishing Persistence

  • Backdoors: We install back-doors on compromised systems to ensure continued access, even if the original entry point is closed or the user credentials are changed.
  • Scheduled Tasks: We use native operating system features to create scheduled tasks or cron jobs that call back to the attacker’s control server or re-execute malware at regular intervals.
  • Web Shells: We deploy web shells on web servers, which allow for persistent, remote administration over the web interface.

Network Analysis and Manipulation

  • Sniffing and Traffic Analysis: We capture network traffic within Web Applications environment to extract credentials, session tokens, or other sensitive data.
  • Man-in-the-Middle Attacks: We position ourselves between two communicating parties to intercept or manipulate data being exchanged, typically by exploiting weaknesses in network protocols.

Credential Harvesting and Reuse

  • Extract Credentials: We use tools to extract credentials stored on compromised instances or intercepted during communication. The use software like hashcat using powerful GPU's to recover weak passwords.
  • Role Switching: We exploit stolen role credentials and the policies to grant broader access than initially available, including elevating privileges within Active Directory or other Directory services.
  • Exploiting System Vulnerabilities: We take advantage of system-level vulnerabilities or misconfigurations to escalate privileges from a lower-privileged user to an administrative user.

Lateral Movement Techniques

  • Pass-the-Ticket/Pass-the-Hash Techniques: We use techniques to authenticate to other systems using stolen Kerberos tickets or NTLM hash values without knowing the actual passwords.
  • Network Pivoting:  We utilise existing credentials or sessions to access other systems within the Web Applications environment, such as moving from one virtual machine to another within the same network. We also use a compromised VM as a pivot point to access internal networks or other virtual networks connected through peering.

Exploiting Trust Relationships

  • Service to Service Exploitation: We exploit connections or trust relationships between services, such as moving from a compromised web server to a connected database server. Or utilise permissions granted to one service (like API) to access or manipulate other services (like filesystems or databases).

Access to Key Assets

  • Data Access: Locate and access databases, file servers, and other storage solutions within the web applications environment to extract sensitive data.
  • Critical Infrastructure Access: Gain control over critical infrastructure components like domain controllers, network infrastructure devices, or security solutions to deepen control over the environment.

Command and Control Channels

  • Data Exfiltration Routes: We establish secure channels for data exfiltration to external servers or through DNS queries.
  • Covert Channels: We set up covert channels to communicate between compromised assets without detection.

Monitoring and Evasion Techniques

  • Log Manipulation: We modify or delete logs to erase traces of activity and evade detection by security monitoring tools.
  • Security Group Manipulation: We adjust security group rules to facilitate movement while attempting to remain under the radar.

ProCheckUp's Reporting Transparent, Tangible 

Every engagement culminates in a detailed report, featuring both high-level overviews for management and detailed technical findings for IT professionals. 

Our reports include

  • Executive Summary: Provides a high-level overview of the test objectives, methodology, key findings, and overall security posture.
  • Detailed Findings: Each finding is detailed with evidence, impact analysis, and clear, actionable remediation steps.
  • Technical Appendices: Includes raw data, logs, tool outputs, and detailed technical descriptions for deeper analysis by the IT team.

Reporting formats

  • Delivery Formats: We can supply the report in multiple formats, such as PDF for executives or spreadsheets for technical teams.
  • Review Meeting: A wash up meeting with all stakeholders to go through the findings, discussing the implications, and answer any questions.


Web Application Penetration Testing is a comprehensive process that scrutinizes every aspect of an Web  application’s operation—from server-side infrastructure and application logic to client-side interface and user interaction mechanisms. Through meticulous testing and validation of each component, we help organisations to identify vulnerabilities and implement more robust security measures, thereby fortifying their applications against both common and sophisticated cyber threats.

Need Help?

If you have any questions about cyber security or would like a free consultation, don't hesitate to give us a call!

Our Services

Keep up to date!

Subscribe to our newsletter. Keep up to date with cyber security.

For More Information Please Contact Us

Smiling Person