Web Assessment Methodology

A web application assessment follows a repeatable flow: enumerate the attack surface, discover vulnerabilities, exploit confirmed weaknesses, and pivot from initial access into deeper targets. Individual techniques covered across HackIndex pages become powerful when chained together. A directory traversal that reads a config file feeds database credentials into an authentication bypass. An SSRF that reaches an internal service opens a second attack surface invisible from the outside. This page ties the individual techniques together into a systematic approach that works for both real engagements and OSWA-style exam environments.

Assessment Flow

Every web assessment moves through four stages. Skipping stages or jumping straight to exploitation wastes time and misses attack paths that only appear through methodical enumeration.

Enumeration maps the application: technology stack, directory structure, parameters, authentication mechanisms, API endpoints, and JavaScript files. Tools like web crawlers, directory brute-forcers, and manual browsing with Burp proxy build a complete picture of the attack surface. Every parameter, header, and cookie value is a potential injection point.

Vulnerability Discovery tests each input for weaknesses. Inject traversal sequences into file parameters, SQL syntax into search fields, SSRF payloads into URL parameters, and XSS vectors into reflected inputs. The goal is to confirm what is vulnerable, not to exploit it yet. Document each confirmed issue with the exact parameter and payload that triggered it.

Exploitation turns confirmed vulnerabilities into access. Read sensitive files through traversal, extract database contents through SQLi, pop shells through command injection, steal sessions through XSS. Each successful exploit potentially reveals new attack surface for the next round of enumeration.

Post-Exploitation extracts value from the access gained. Harvest credentials from config files and databases, access internal services, pivot to other hosts, and escalate privileges. Every piece of data collected feeds back into the earlier stages, creating new enumeration and exploitation opportunities.

Chaining Vulnerabilities

Single vulnerabilities rarely give you everything. The real impact comes from chaining findings where the output of one exploit becomes the input for the next. Think of each vulnerability as a step in a path rather than an isolated finding.

Directory Traversal to Database Access

A directory traversal that reads arbitrary files targets application config files first. Laravel .env files, Django settings.py, WordPress wp-config.php, and Node.js .env all store database credentials in plaintext. If the database port is accessible (directly or through SSRF), those credentials provide full database access. From there, dump user tables, extract password hashes, or modify admin account credentials for authentication bypass.

SQL Injection to Remote Code Execution

SQL injection that supports stacked queries or file write functions escalates beyond data extraction. MySQL INTO OUTFILE writes a web shell to the document root. PostgreSQL COPY TO does the same. MSSQL xp_cmdshell executes OS commands directly without needing a web shell. Even without write access, extracting admin credentials from the database and logging in as admin often exposes additional functionality like file uploads or template editing that leads to code execution.

SSRF to Cloud Account Compromise

SSRF against cloud-hosted applications targets the metadata service first. A single request to 169.254.169.254 retrieves IAM role credentials that may have broad access to S3 buckets, databases, and other cloud resources. Even when metadata access is blocked, SSRF into internal admin panels, databases, or monitoring tools exposes credentials and functionality not visible from the outside.

XSS to Administrative Access

Stored XSS in a field that an administrator views (support tickets, user profiles, comments) steals admin session cookies. With the admin session, access administrative functionality: user management, file uploads, configuration panels, and template editing. Admin file upload often has weaker validation than public-facing upload, providing a direct path to web shell deployment.

IDOR to Privilege Escalation

IDOR vulnerabilities that expose other users' data become critical when they reach admin-level resources. Enumerating user IDs to find admin accounts, accessing admin API endpoints by changing the user ID parameter, or modifying your own role through an IDOR in the profile update endpoint all turn a low-severity IDOR into full administrative access.

Prioritizing Attack Paths

Not every vulnerability is worth pursuing immediately. Prioritize based on two factors: how likely is exploitation to succeed, and what access does it give you.

High priority: Anything that leads directly to code execution or credential access. Command injection, SQL injection with write capability, file upload bypasses, SSRF to cloud metadata, and deserialization vulnerabilities. These give you shells or credentials that open the entire target.

Medium priority: Vulnerabilities that require chaining but have clear paths forward. Directory traversal (needs a valuable file to read), blind SQL injection (slower extraction but still works), IDOR on sensitive endpoints, and authentication bypass. Each requires extra work but reliably delivers results.

Lower priority (initially): Reflected XSS (requires social engineering in an exam context), information disclosure that does not directly enable another attack, and CSRF in non-critical functions. Revisit these after exhausting higher-impact paths.

When stuck, go back to enumeration. The most common reason for hitting a wall is an incomplete attack surface map. Recheck for hidden parameters, API endpoints, JavaScript files containing hardcoded paths, and backup files that may reveal source code. When you have source code access, switch to source code review methodology for systematic sink-to-source tracing.

Common Chains in CTF and Exam Environments

Certain patterns appear repeatedly in OSWA-style assessments and CTF challenges. Recognizing these patterns saves time.

Login bypass into admin panel into code execution: Authentication bypass (SQL injection in login, default credentials, JWT manipulation, or password reset flaw) grants admin access. The admin panel contains a file upload, template editor, or plugin installer that accepts a web shell or reverse shell payload.

LFI/traversal into source code into hardcoded secrets: Reading application source code through traversal reveals hardcoded API keys, database passwords, or secret tokens used for session signing. Forging a valid admin session token with the leaked secret key bypasses authentication entirely.

Blind injection into data extraction into lateral access: A blind SQL injection or blind command injection requires patience but yields database contents or command output through boolean or time-based techniques. Extracted credentials from one application authenticate against a second application or service in the environment.

SSRF into internal application into second exploit: The external-facing application is hardened, but an internal application reachable through SSRF runs outdated software or lacks authentication. Exploit the internal application through the SSRF proxy to gain code execution on the internal host.

Chained low-severity into critical: An open redirect chains with SSRF filter bypass. An information disclosure reveals internal IP ranges for SSRF targeting. A self-XSS chains with CSRF to become a stored XSS affecting other users. Individually these are low-severity, but combined they create critical impact.

After each successful exploitation step, re-enumerate. New credentials, new access levels, and new network positions all expand the attack surface. The assessment is not linear. It loops back through enumeration and discovery with every new piece of information gained.