SXGuard — Swiss Security
...
Web Application Penetration Testing
Methodology

Web Application Penetration Testing

Manual, OWASP-aligned testing of your web software for exploitable flaws such as XSS, SQL injection, and broken authentication.

A laptop displaying web application code

I) Introduction

Definition

A Web Application Penetration Test (WAPT) is a specialized security assessment that focuses on identifying and exploiting vulnerabilities within a web-based application, its components (like APIs), and its underlying configuration. It simulates a targeted attack on the application layer to find flaws in code, logic, and implementation.

Primary Goal

The primary goal is to identify security weaknesses that could be exploited by an attacker to compromise the application, access or modify data, or affect other users. This goes beyond simple scanning to demonstrate the real-world business risk associated with these vulnerabilities.

WAPT vs. Network Penetration Test

  • Network Pen Test: Focuses on the underlying infrastructure (servers, firewalls, ports, services). Asks, "Can I compromise the server?"
  • Web App Pen Test (This Methodology): Focuses on the application running on the server (usually on ports 80/443). Asks, "Can I compromise the application's code or logic?"

II) Penetration Test Phases

Phase 1: Planning and Scoping

1.1. Define Objectives

  • Clearly define the goals of the test (e.g., "Attempt to gain administrative access," "Access another user's data," "Compromise the underlying server").

1.2. Define Scope

  • In-Scope: Explicitly list all target URLs, domains, and API endpoints (e.g., https://example.com/login, https://api.example.com/v2).
  • Out-of-Scope: Define what must not be tested (e.g., https://partner.example.com, social engineering, denial-of-service attacks).

1.3. Define Test Type & Credentials

  • Black Box: No prior knowledge or credentials. Simulates an external, unauthenticated attacker.
  • Grey Box (Most Common): Partial knowledge and/or credentials for one or more user roles (e.g., a "regular user" account, an "admin" account). This allows for testing both unauthenticated vulnerabilities and authenticated-user privilege escalation.
  • White Box: Full access to source code, documentation, and diagrams. This is a comprehensive review, often blending penetration testing with static code analysis.

1.4. Establish Rules of Engagement (ROE)

  • Authorization: Obtain explicit, written permission ("Get Out of Jail Free" card).
  • Testing Window: Define specific dates and times when testing is permitted (e.g., only after-hours to avoid impacting production users).
  • Data Handling: Define how sensitive data (e.g., PII discovered in a database) will be handled, masked in the report, and securely purged after the engagement.
  • Communication Channels: Establish a dedicated point of contact for real-time communication if a critical vulnerability is found or a system becomes unresponsive.

Phase 2: Reconnaissance & Application Mapping

2.1. Passive Reconnaissance (OSINT)

  • Gather information without directly interacting with the application.
  • Examples: Reviewing robots.txt and sitemap.xml, Google dorking for indexed pages or errors, and identifying the technology stack (e.g., via Wappalyzer, job postings, or error banners).

2.2. Active Reconnaissance & Spidering

  • Actively probe the application to map its structure.
  • Automated Spidering: Use a proxy tool (e.g., Burp Suite, OWASP ZAP) to crawl all accessible links, pages, and directories.
  • Manual Discovery: Manually browse the application, submitting forms and following links (especially for multi-step processes like "add to cart" or "password reset") to discover all functionality.
  • Directory & File Brute-Forcing: Use tools (e.g., dirb, gobuster) with common wordlists to find hidden files or directories that are not linked (e.g., /admin, /backup.zip, .git).

Phase 3: Vulnerability Analysis & Testing

The core of the security testing process involves the systematic examination of the mapped application for common vulnerabilities. This phase primarily utilizes the guidelines and common issues outlined in the OWASP Testing Guide and the OWASP Top 10.

This is the current list (2021 edition).

  • Broken Access Control: The #1 risk. It occurs when users can act outside of their intended permissions (e.g., a regular user accessing an admin page or viewing another user's data).
  • Cryptographic Failures: Formerly known as "Sensitive Data Exposure." This involves failures in encryption, such as storing passwords in plain text, using weak encryption algorithms, or transmitting data over HTTP instead of HTTPS.
  • Injection: This happens when untrusted data is sent to an interpreter as part of a command or query. The most common types are SQL Injection (SQLi) and Cross-Site Scripting (XSS).
  • Insecure Design: This is a new category focusing on risks related to design and architectural flaws. It argues that we need to "shift left" and bake security into the design phase, rather than just patching code later.
  • Security Misconfiguration: This includes using default passwords, leaving unnecessary features enabled, not patching systems, or revealing too much information in error messages.
  • Vulnerable and Outdated Components: Using libraries, frameworks, or other software modules that have known vulnerabilities. This is a major issue in modern web development (e.g., the Log4j vulnerability).
  • Identification and Authentication Failures: Weaknesses in how the application confirms the user's identity. This includes allowing weak passwords, lacking Multi-Factor Authentication (MFA), or failing to invalidate session IDs after logout.
  • Software and Data Integrity Failures: Relying on plugins, libraries, or updates from untrusted sources or without verifying their integrity (e.g., a supply chain attack).
  • Security Logging and Monitoring Failures: Not logging critical security events (like failed login attempts) or not monitoring logs, which allows attackers to maintain access for long periods without detection.
  • Server-Side Request Forgery (SSRF): Occurs when a web application fetches a remote resource without validating the user-supplied URL. This allows an attacker to coerce the application into sending a crafted request to an unexpected destination (often internal systems).

Phase 4: Exploitation

This phase moves beyond mere identification and proof-of-concept into the active demonstration of real-world risk and business impact. The primary objective is to successfully chain identified vulnerabilities to achieve the maximum possible detrimental effect, thereby providing irrefutable evidence of the risk severity. This is a critical stage where the hypothetical risk becomes a tangible security failure.

4.1 Chaining Vulnerabilities (Multi-Stage Attacks)

  • This involves using the output or effect of one vulnerability as the necessary input for the next, creating a sophisticated attack vector. The goal is to escalate privileges or access data that would be otherwise unreachable.
  • Example Scenario: A Low-severity Stored Cross-Site Scripting (XSS) vulnerability is discovered in a user comment section. This vulnerability is then exploited to steal a High-Privilege administrator's session cookie when they view the comment. The stolen cookie is subsequently used to hijack the administrator's session, granting the attacker full administrative control over the application without needing a password.

4.2 Gaining Server Access (Remote Command Execution)

  • The ultimate goal in many web application tests is to move from application-level compromise to operating system-level control. This is often achieved through vulnerabilities that allow for the execution of arbitrary operating system commands.
  • Example Scenario: A Command Injection (or similar Remote Code Execution - RCE) vulnerability is identified in a function that processes user-supplied data using a system shell command (e.g., ping, exec). The attacker leverages this to inject a payload that forces the web server to connect back to an attacker-controlled listener, establishing a persistent reverse shell. This grants the attacker command-line access to the underlying web server operating system.

4.3 Data Exfiltration (Sensitive Information Theft)

  • A key metric of a successful penetration test is the ability to access and retrieve sensitive or proprietary data. This demonstrates a direct impact on customer privacy, regulatory compliance, and business operations.
  • Example Scenario: An application is found to be susceptible to a Blind or Time-Based SQL Injection (SQLi) vulnerability. This vulnerability is then methodically exploited to iterate through database schemas, table names, column names, and finally, to dump the entire user database containing personally identifiable information (PII), hashed passwords, and other sensitive details.

4.4 Proving Maximum Impact and Scope

  • All exploitation efforts must be meticulously documented to prove the maximum potential damage. The proof must be undeniable, reproducible, and non-destructive to the integrity of sensitive data. It is critical that real, sensitive data is not exfiltrated or tampered with.
  • Example Proofs:
    • Privilege Escalation: Taking a timestamped screenshot of the previously inaccessible admin configuration panel or a specific system audit log only viewable by high-level users.
    • Database Compromise: Successfully retrieving a single, non-sensitive row of data (e.g., a sample product name or a dummy user ID) from the deepest or most protected table in the database, demonstrating the potential to access all data.
    • Server Control: Dropping a non-harmful text file onto the server's public web root (e.g., pwned.txt), or obtaining the system's hostname and kernel version via the established reverse shell.
    • This phase is essential for translating technical flaws into a clear, business-risk context for stakeholders, providing the justification for critical remediation efforts.

4.5 Post-Exploitation

  • This advanced phase is executed exclusively when a server-level vulnerability, such as Remote Code Execution (RCE) or a shell upload, has been successfully exploited, granting initial access to the underlying server operating system. The goal shifts from finding vulnerabilities to maximizing access and understanding the internal environment.
  • Note: This sophisticated level of testing will only be executed with explicit, documented authorization.

4.5.1 Initial Foothold and System Triage

Immediately after gaining the initial shell, the focus is on stability and initial information gathering:

  • Establish Persistence: Implement a method (e.g., scheduled task, malicious service, modified startup script) to ensure continued access even if the exploited service crashes or the system reboots. This often involves creating a more stable reverse or bind shell.
  • System and User Enumeration: Determine the operating system version, kernel details, installed patches, and the security context (user ID/group) under which the compromised web service is running (e.g., www-data, apache, iisuser).
  • Configuration Review: Analyze critical configuration files for clear-text credentials, API keys, or connections strings (e.g., wp-config.php, database configuration files, environment variables).

4.5.2 Internal Reconnaissance

Leveraging the compromised server as a beachhead, the tester begins to map the internal network infrastructure:

  • Network Mapping: Use built-in utilities (like ipconfig/ifconfig, route, netstat) to identify the server's network interfaces, IP addresses, default gateway, and active network connections.
  • Neighbor Discovery: Attempt to use tools or system commands (if available or uploaded) like arp -a, PING sweeps, or local port scans to discover other hosts and services residing on the same subnet(s) that the web server is connected to.
  • Firewall/ACL Evasion: Identify any host-based firewalls or access control lists and determine techniques to bypass or circumvent them to reach other internal targets.

4.5.3 Privilege Escalation

The access gained via the web service is typically a low-privilege user (e.g., www-data on Linux, a service account on Windows). The immediate objective is to escalate privileges to a higher level, ideally root on Linux/macOS or SYSTEM/Administrator on Windows:

  • Kernel/OS Exploits: Scan for known vulnerabilities in the operating system kernel or services based on the version identified.
  • Weak Service Permissions: Check for services or executables running with elevated privileges that have weak permissions, allowing the low-privilege user to modify the service binary or configuration.
  • Misconfigurations: Look for common misconfigurations like:
    • SUDO/SUID Abuse (Linux): Identify binaries that the low-privilege user can run as root without a password.
    • Unquoted Service Paths (Windows): Exploiting spaces in file paths to execute arbitrary code.
    • Clear-text credentials in logs or memory.

4.5.4 Lateral Movement

Once local administrator/root access is achieved, or if suitable credentials are found, the tester attempts to pivot from the compromised web server to other valuable assets on the internal network:

  • Credential Harvesting: Extract passwords, hashes, and Kerberos tickets from memory, configuration files, or local credential managers.
  • Pivoting Techniques: Use the compromised machine to access resources not reachable from the external internet. This might involve:
    • SSH Tunneling/RDP: Connecting to other internal hosts using captured credentials.
    • Proxying: Setting up an internal proxy (e.g., using Socks or Chisel) to route internal traffic through the compromised host.
  • Targeting High-Value Assets: Focus on critical systems that were not in the original external scope, such as:
    • Database Servers: (e.g., SQL, Oracle) for sensitive customer/business data.
    • Domain Controllers/Identity Servers: (e.g., Active Directory) for enterprise-wide control.
    • Internal Source Code Repositories or File Shares.

Phase 5: Reporting

  • Executive Summary: A high-level, non-technical summary for management, focusing on business risk, key findings, and the overall security posture.
  • Technical Report: A detailed report for developers and IT teams.
  • Attack Narrative: A step-by-step walkthrough of the most significant exploit chains.
  • Vulnerability Details: For each finding, provide:
  • Description: A clear explanation of the vulnerability (e.g., "OWASP A03: Injection").
  • Affected URLs/Parameters: The exact location of the flaw.
  • Evidence: Screenshots, HTTP requests/responses, and code snippets.
  • Impact: The potential business impact.
  • Risk Rating: A score (e.g., Critical, High, Medium, Low) to prioritize.
  • Remediation: Provide clear, prioritized, and step-by-step instructions for fixing each vulnerability, including code examples where possible

Phase 6: Remediation and Re-testing

  • Present the findings to the client in a debrief meeting.
  • After the client's development team has implemented the fixes, perform a targeted re-test to validate that the vulnerabilities have been successfully remediated.
Back to all services

Ready to scope this engagement?

Tell us about your environment and objectives — we'll return a tailored scope, timeline, and quote within 24 hours.

Request a Free Scoping Call