Web Application Security Testing Methodology

Executive Summary

Web applications are the primary attack surface for most organisations. OWASP reports that web application attacks are consistently the leading initial access vector in breaches, and the 2024 DBIR confirms that web application exploitation remains in the top three attack patterns year after year.

This document describes the CyberneticsPlus web application penetration testing methodology, aligned with the OWASP Testing Guide v4.2 and OWASP Top 10 2021. It is intended for security professionals conducting application assessments and for application owners who want to understand what a rigorous web application penetration test involves.

Chapter 1: Methodology Overview

OWASP Testing Framework

The OWASP Testing Guide organises web application testing into 12 categories:

Testing Phases

1. Pre-engagement: Scope definition, rules of engagement, credential provisioning
2. Information gathering: Application mapping, technology fingerprinting, surface enumeration
3. Active testing: Systematic testing across all categories
4. Exploitation: Confirming exploitability and demonstrating impact
5. Reporting: Documented findings with evidence and remediation guidance
6. Retest: Verifying remediation of critical and high findings

Testing Environment

Web application testing should ideally be performed against a staging/UAT environment that mirrors production. Testing against production is acceptable with written authorisation, but:

• Avoid testing that could cause data loss or service disruption in production
• Use dedicated test accounts, not production user accounts
• All actions should be reversible or have negligible business impact

Chapter 2: Information Gathering

Application Mapping

Before testing, build a complete map of the application:

Automated spidering:

• Burp Suite Pro: use the site map and active crawl to discover pages, forms, and endpoints
• Note: modern SPAs (React, Angular, Vue) require browser-based crawling; passive proxy observation during manual browsing is more effective than traditional spidering

Manual browsing: Walk through every application function as each user role:

1. Unauthenticated user
2. Standard authenticated user
3. Privileged user (admin, manager)
4. Any other distinct roles

Document: every URL, every form, every parameter, every file upload, every AJAX request.

Technology Fingerprinting

Identify the technology stack for targeted testing:

• Web server: Apache, Nginx, IIS — version from response headers
• Framework: Laravel, Django, Rails, Spring Boot, ASP.NET — error pages, cookies, headers
• JavaScript frameworks: React, Angular, Vue, jQuery — page source inspection
• Third-party components: CDN-hosted scripts, API integrations
• Cloud platform: AWS (S3 URLs, CloudFront headers), Azure (azurewebsites.net), GCP

Tools: Wappalyzer (browser extension), BuiltWith, Whatweb (command line)

OSINT and External Recon

• Subdomains: crt.sh (certificate transparency), Amass, subfinder
• Historical URLs: Wayback Machine, CommonCrawl for old endpoints
• Leaked credentials: Have I Been Pwned for the target domain; public GitHub for hardcoded credentials
• Job postings: Technology stack clues from engineering job descriptions
• JavaScript files: Source-mapped or unminified JS may expose API endpoints, hardcoded keys

Chapter 3: Configuration and Deployment Testing

HTTP Security Headers

Check for the presence and correctness of security headers:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: DENY  (or use CSP frame-ancestors)
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Tool: securityheaders.com (external check) or Burp Suite manual review.

TLS Configuration

• Verify TLS 1.2+ (TLS 1.0, 1.1, SSLv3 should not be accepted)
• Check for weak cipher suites: RC4, 3DES, NULL, EXPORT ciphers must not be offered
• Certificate validity: expiry date, correct hostname, trusted CA chain
• HSTS header presence and correct max-age (minimum 1 year = 31536000)

Tool: testssl.sh (comprehensive TLS assessment) or SSL Labs (external web check).

Exposed Content and Sensitive Files

Common sensitive paths to check:

/.git/                  # Git repository exposure
/.env                   # Environment variables (credentials)
/backup.zip, /db.sql    # Database or source backups
/phpinfo.php            # PHP configuration (version, paths, variables)
/admin/, /administrator/, /manager/
/api/swagger.json, /api/openapi.yaml  # API documentation
/server-status          # Apache server status
/.DS_Store              # macOS metadata (directory listing)
/web.config, /app.config  # ASP.NET configuration files

Tool: gobuster or ffuf with SecLists wordlists for directory/file enumeration.

Chapter 4: Authentication Testing

Username Enumeration

Identify whether the application reveals whether a username exists:

• Login response: different error messages for “username not found” vs “wrong password”
• Password reset: “Email sent” vs “Account not found”
• Registration: “Username already taken” on existing accounts

Test both HTTP response content and response timing (timing oracle attacks).

Password Policy Assessment

• Minimum length (should be ≥ 12 characters)
• No complexity requirements (modern NIST guidance prefers length over complexity)
• Breached password check (HIBP API or similar)
• No restriction on using the same password as previous passwords

Brute Force and Rate Limiting

Login endpoint:

1. Submit 10 rapid login requests with wrong credentials
2. Observe: is there rate limiting? Account lockout? CAPTCHA trigger?
3. Test lockout bypass: change IP via proxy, rotate User-Agent, add X-Forwarded-For header
4. Verify lockout is per-account, not per-IP (IP-only lockout is trivially bypassed)

Password reset:

1. Request password reset for an account
2. Attempt to brute-force the reset token (test token length and character set)
3. Check token expiry: request a token and use it 2+ hours later

Multi-Factor Authentication Testing

• Test MFA bypass: attempt to access authenticated pages after providing correct password but skipping MFA step (step-skip attack)
• Test MFA code rate limiting: can you brute-force the 6-digit TOTP code?
• Test backup codes: are backup codes one-time use? Appropriately long?
• Test MFA code reuse: can the same TOTP code be used twice in its validity window?

Chapter 5: Session Management Testing

Session Token Analysis

Collect 100+ session tokens and analyse:

• Entropy: Tokens should be ≥ 128 bits of cryptographic randomness. Low entropy enables prediction.
• Predictability: Sequential, time-based, or otherwise predictable token patterns
• Tool: Burp Suite’s Sequencer — provides statistical analysis of token randomness

Session Fixation

1. Note the session token before authentication
2. Log in
3. Check whether the session token changed after authentication

If the pre-authentication token is the same as the post-authentication token, the application is vulnerable to session fixation — an attacker can set a known session ID and hijack the session after the victim logs in.

Session Termination

• Logout: Verify the session token is invalidated server-side on logout (not just deleted client-side)
• Timeout: Verify inactive sessions expire within a reasonable period (30 minutes for sensitive applications)
• Token invalidation on password change: Changing password should invalidate all other active sessions

Cookie Security Attributes

All session cookies should have:

Set-Cookie: sessionid=abc123;
  Secure;          ← HTTPS only
  HttpOnly;        ← JavaScript cannot read
  SameSite=Strict; ← CSRF protection
  Path=/;
  Max-Age=1800     ← 30 minute session

Chapter 6: Injection Vulnerabilities

SQL Injection

Detection — error-based:

Input: ' (single quote)
Expected: Database error revealing SQL syntax error

Detection — boolean-based (blind):

Input 1: ' AND '1'='1  → normal response (condition is true)
Input 2: ' AND '1'='2  → different response (condition is false)

Detection — time-based (fully blind):

MySQL: ' AND SLEEP(5)--
MSSQL: '; WAITFOR DELAY '0:0:5'--
PostgreSQL: '; SELECT pg_sleep(5)--

If response time increases by ~5 seconds, SQL injection exists even with no visible difference.

Automated testing:

sqlmap -u "https://target.com/app?id=1" --dbs --level=3 --risk=2

Exploit — confirm impact:

• Demonstrate database version extraction: @@version (MySQL/MSSQL), version() (PostgreSQL)
• Demonstrate table listing (information_schema enumeration)
• Do NOT dump customer data — demonstrate schema access only

Cross-Site Scripting (XSS)

Reflected XSS test payload:

<script>alert(document.domain)</script>
"><script>alert(1)</script>
'><img src=x onerror=alert(1)>
javascript:alert(1)

Stored XSS: Submit payload in persistent inputs (comments, profile fields, message bodies). Browse to the location where it is rendered and observe execution.

DOM XSS: Identify JavaScript that reads from dangerous sources (location.hash, document.URL, window.name) and writes to sinks (innerHTML, eval(), document.write()).

Impact demonstration for reports: Rather than alert(1), use a payload that demonstrates real impact without causing harm:

// Demonstrates cookie access without theft
<script>alert('XSS Demo — Cookie value: ' + document.cookie.substring(0,20))</script>

XML External Entity (XXE)

For applications parsing XML input (file uploads, SOAP endpoints, XML-based APIs):

<?xml version="1.0"?>
<!DOCTYPE test [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

If /etc/passwd content appears in the response, XXE is confirmed.

SSRF via XXE:

<!DOCTYPE test [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>

Server-Side Template Injection (SSTI)

Template injection occurs when user input is rendered inside a server-side template without sanitisation.

Detection payload:

${7*7}    → Jinja2, Freemarker
{{7*7}}   → Jinja2 (Python), Twig (PHP)
<%= 7*7 %> → ERB (Ruby)
#{7*7}    → Ruby
*{7*7}    → Spring (Java)

If the application returns 49, SSTI exists. SSTI can lead to Remote Code Execution.

Chapter 7: Access Control Testing

Horizontal Privilege Escalation (IDOR)

Test every object reference in the application:

1. Log in as User A (testuser_a@test.com)
2. Perform actions and collect all object IDs from responses: order IDs, document IDs, account IDs, etc.
3. Log in as User B (testuser_b@test.com)
4. Attempt to access User A’s objects using the captured IDs in URL paths, query parameters, and request bodies
5. Document any successful cross-account data access

Vertical Privilege Escalation

Test access to functions above your user’s privilege level:

1. Identify admin/elevated functions (admin panel, bulk operations, user management)
2. Attempt to access these functions with standard user credentials
3. Test parameter manipulation to escalate roles:
   • Add role=admin to registration or profile update requests
   • Modify isAdmin=false to isAdmin=true in request bodies
   • Test forced browsing to admin URLs directly

Forced Browsing

Access functionality without going through the intended application workflow:

• Direct URL access to authenticated pages while unauthenticated
• Bypassing multi-step workflows (go directly to step 3 without completing steps 1–2)
• Accessing “hidden” functionality by guessing URLs

Chapter 8: Business Logic Testing

Business logic vulnerabilities are application-specific — they cannot be detected by automated scanners. They require understanding how the application is supposed to work and testing whether it can be made to work differently.

Common Business Logic Patterns

Negative values:

• Submit negative quantities in shopping carts: does the application issue a refund?
• Submit negative amounts in transfer endpoints
• Submit negative prices in any field that accepts numeric input

Workflow bypass:

• Skip the payment step in checkout: add item → skip to “order confirmation”
• Skip email verification: register → go directly to authenticated functionality
• Access review/approval results before the review step

State manipulation:

• Change the status of orders, requests, or approvals via API parameters
• Replay completed transactions

Race conditions:

• Submit two concurrent requests for a single-use resource (coupon code, referral bonus)
• Use Burp Suite’s “Send to Intruder” with 20 parallel threads against a single-use action
• Look for cases where the application processes the same request twice

Coupon/discount abuse:

• Apply the same coupon multiple times
• Apply multiple different discount codes simultaneously
• Apply a coupon to a cart that doesn’t meet the conditions

Chapter 9: Client-Side Security Testing

Content Security Policy Analysis

Evaluate the CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'

unsafe-inline in script-src defeats XSS protection — inline script execution is permitted. Flag as a finding.

CSP validator tools: CSP Evaluator (Google), Burp Suite CSP Scanner.

Sensitive Data in Client-Side Storage

Inspect browser storage for sensitive data:

• localStorage: Should not contain authentication tokens, PII, or sensitive business data
• sessionStorage: Same constraints
• IndexedDB: Review for sensitive data storage
• Cookies: All authentication cookies should have HttpOnly flag; sensitive data should not be stored unencrypted in non-HttpOnly cookies

Subresource Integrity

Third-party scripts loaded from CDNs should use Subresource Integrity (SRI) to prevent supply chain attacks:

<script
  src="https://cdn.example.com/jquery.min.js"
  integrity="sha384-[base64-hash]"
  crossorigin="anonymous">
</script>

Missing SRI means a compromised CDN can serve malicious JavaScript that executes on your users’ browsers.

Chapter 10: Tooling Reference

Core Tools

Burp Suite Workflow Tips

• Enable the Burp Collaborator for out-of-band vulnerability detection (blind SQLi, SSRF, XXE)
• Use the Logger++ extension for detailed request/response logging
• Use the Autorize extension for automated authorisation testing across roles
• Use the Param Miner extension to discover hidden parameters

Conclusion

A rigorous web application penetration test systematically covers every category of the OWASP Testing Guide, combining automated scanning with manual expert testing. The distinguishing factor between a quality assessment and a scan-and-report engagement is the manual testing — particularly for business logic, authorisation, and contextual injection vulnerabilities that automated tools miss.

Every web application penetration test should result in:

• A complete finding list with severity, evidence, and remediation guidance
• An executive summary presenting risk in business terms
• Remediation support — developers should be able to implement fixes from the report alone
• A retest cycle confirming critical and high findings are resolved

CyberneticsPlus performs OWASP-aligned web application penetration tests for SaaS platforms, financial applications, healthcare systems, and e-commerce platforms. Contact us to discuss a web application security assessment.