Classroom Glossary Public page

Week 4: Web Application Reconnaissance

1,399 words

Web applications are the most common attack surface in modern engagements. Before exploiting anything, you map the application: what routes exist, what technology is running, what input parameters are present, what authentication mechanisms protect what resources. This week you learn to enumerate systematically with Burp Suite as the observation layer.

Reading (~1.5 hr)

Required:

  • WAHH (Stuttard + Pinto), The Web Application Hacker's Handbook, Chapter 1 ("Web Application (In)security") and Chapter 4 ("Mapping the Application"). Chapter 1 frames why web applications are uniquely complex attack surfaces; Chapter 4 covers the enumeration methodology directly.
  • OWASP Testing Guide v4.2, Section OTG-INFO (owasp.org/www-project-web-security-testing-guide/), subsections on web server fingerprinting, web framework fingerprinting, and directory enumeration.

Supplementary:

  • Weidman, Penetration Testing, Chapter 14 ("Web Application Testing"), Burp Proxy subsection. The Burp Suite version in the book is older; the current Community Edition interface differs slightly but the proxy mechanics are identical.

Lecture outline (~1 hr)

Part 1: The web application attack surface (15 min)

A web application's attack surface is the sum of all entry points through which an attacker could interact with the application. Mapping the attack surface is the purpose of web recon.

Entry point categories:

  • URLs and routes: Every distinct URL is a potential entry point. A login page is an obvious one. A forgotten password reset endpoint is less obvious. An API endpoint at /api/v1/user/profile is less obvious still.
  • Input parameters: Every form field, URL query parameter (?id=1), HTTP header the application reads (X-Forwarded-For, User-Agent, Referer), and cookie value is a potential injection point.
  • Authentication surfaces: Login forms, OAuth callback URLs, password-reset tokens, "remember me" cookies, API key headers.
  • File upload points: A single file upload input can become an arbitrary code execution vector depending on how the server processes the upload.
  • Out-of-band channels: Webhooks, email sending, PDF generation, server-side HTTP requests triggered by user input.

WAHH frames this precisely: "The first and most fundamental approach to attacking a web application is to understand as much as possible about the application: how it works, what it does, and what technologies it uses." (Ch. 4 methodology overview.)

Part 2: Burp Suite as the observation layer (25 min)

Burp Suite Community Edition is a proxy that sits between your browser and the web application. Every HTTP request your browser sends passes through Burp; every response comes back through Burp. You can intercept, inspect, modify, and replay any request.

Setup:

burpsuite &  # or launch from Applications menu in Kali

In Burp: Proxy > Intercept > Off (to let traffic flow without manual interception).

In your browser: configure the proxy to 127.0.0.1:8080. On Kali with Firefox:

  • Settings > Network Settings > Manual proxy configuration
  • HTTP Proxy: 127.0.0.1, Port: 8080

For HTTPS interception: install the Burp CA certificate.

  • Browse to http://burpsuite while proxy is active
  • Download the CA certificate; import into Firefox (Settings > Privacy > Certificates > Import)

The Proxy HTTP History tab is the core of web recon. Browse the target application normally -- click every page, submit every form, log in and out -- and Burp records every request and response. This is the passive enumeration phase.

The Site Map tab builds a tree of every URL Burp has seen. After initial browsing, the site map shows the application's visible structure. Anything not in the site map yet is either undiscovered or requires different authentication.

Useful Burp Proxy workflow for Lab 4:

  1. Start Burp; set Firefox to proxy
  2. Browse the target application fully (every menu item, every page, every form)
  3. Check the Site Map: note every URL, every parameter, every file type
  4. Note the technologies: response headers (Server:, X-Powered-By:, Set-Cookie: cookie names), page source comments, framework-specific file names (.jsp = Java, .php = PHP, .aspx = ASP.NET)
  5. Right-click any request in HTTP History to send to Repeater (for manual replay) or Intruder (for fuzzing)

Part 3: Directory and endpoint enumeration (20 min)

Burp's passive observation only sees routes the application links to or the user navigates to. Many applications have routes that are never linked -- admin panels, backup files, API versions, forgotten test endpoints. Directory enumeration discovers these by trying known paths.

Tools:

# gobuster: word-list-based directory enumeration
gobuster dir -u http://target:8080 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,asp,aspx -o gobuster-output.txt

# feroxbuster: recursive, faster, handles redirects better
feroxbuster -u http://target:8080 -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt

# ffuf: fast web fuzzer; can fuzz any part of the request (URL, headers, body)
ffuf -u http://target:8080/FUZZ -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt

Wordlists in Kali: The default wordlists are at /usr/share/wordlists/. SecLists (github.com/danielmiessler/SecLists) is the industry-standard collection; install on Kali:

sudo apt install seclists -y
# wordlists at /usr/share/seclists/

Technology-specific wordlists: gobuster + a PHP-specific wordlist against a .php target finds more than a generic list. SecLists has technology-specific lists at Discovery/Web-Content/.

API endpoint enumeration: Modern applications use /api/v1/ or /api/v2/ patterns. Enumerate:

gobuster dir -u http://target/api -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt

Wappalyzer: The Firefox Wappalyzer extension (addons.mozilla.org) fingerprints technology stacks from HTTP headers, JavaScript includes, and HTML patterns without sending additional requests. Install it and browse the target; the popup shows the stack. This is passive from the target's perspective (it reads responses, does not probe).

Lab 4: Web Application Recon (~4 hr, graded)

See labs/lab-4-web-recon.md for the full lab.

Targets: DVWA running locally (Lab 4a) + WebGoat running locally (Lab 4b).

Authorization note: Both targets are running in Docker on your own Kali VM. You are authorized to test these applications. Do not run web recon tools against any external target.

Lab 4a: DVWA technology fingerprint and directory enumeration

  1. Configure Burp to proxy DVWA traffic.
  2. Browse every page of DVWA while Burp records. Log in (default credentials: admin / password).
  3. From Burp's Site Map, document: all URLs discovered, all form parameters, all cookie names.
  4. Run gobuster dir against DVWA with a medium wordlist.
  5. Note any routes found by gobuster that were not in Burp's site map from passive browsing.
  6. Fingerprint the stack: web server (from HTTP headers), PHP version (from X-Powered-By), any framework.

Lab 4b: WebGoat attack surface map

  1. Browse WebGoat completely (all lesson categories).
  2. Identify three distinct input injection points (form fields or URL parameters that accept user-controlled input).
  3. For each injection point, note: the HTTP method (GET/POST), the parameter name, the expected input format, and what the application appears to do with the input.
  4. This is reconnaissance only -- do not submit attack payloads yet. The goal is the attack surface map, not exploitation.

Deliverable: A Markdown report with two sections (DVWA and WebGoat). Each section: technology fingerprint, site map summary (how many routes discovered passively vs. via gobuster), and attack surface map (injection point inventory). Include the Burp HTTP History export and the gobuster output as appendices.

Independent practice (~3 hr)

  • OWASP ZAP comparison (1.5 hr): Run OWASP ZAP's Active Scan (with Active Scan turned off -- use the Spider only for this exercise) against DVWA. Compare the spider's site map to what Burp's passive proxy and gobuster found. ZAP and Burp have different discovery approaches; understanding both is practitioner-level fluency.
    zaproxy &
# or: owasp-zap &
  • Wappalyzer exercise (0.5 hr): Install Wappalyzer in Firefox. Browse DVWA and WebGoat. Note what stack information it surfaces without any additional probing.
  • Reflection (1 hr): Write the reflection prompts below.

Reflection prompts

  1. Burp Suite's Proxy History tab shows every HTTP request and response. After 30 minutes of browsing DVWA, how many distinct requests did Burp capture? How does this number relate to the number of URL routes in the Site Map? Why are these numbers different, and what does the difference tell you about the application's behavior?

  2. Directory enumeration tools like gobuster are "noisy" -- they generate hundreds or thousands of HTTP requests against the target server in a short period. On a real client engagement, when would you run gobuster, and when might you hold back? What would the ROE need to say to authorize aggressive directory fuzzing?

  3. WAHH Chapter 4 describes "application mapping" as a precursor to all other testing. The metaphor is cartography: you map before you navigate. What is lost if you skip the mapping phase and go directly to exploitation? What specific class of vulnerabilities is most likely to be missed if you only test what the application's navigation links you to?

Toolchain Diary: Week 4 additions

  • Burp Suite Community -- HTTP proxy + manual testing framework. Core web recon and exploitation tool. First canonical PEN-track introduction.
  • OWASP ZAP -- Automated web scanner + proxy. Complements Burp with scripted scanning capability; Active Scan runs a subset of the OWASP WSTG test cases automatically.
  • gobuster -- Directory/endpoint brute-forcer; wordlist-based URL discovery.
  • feroxbuster -- Recursive fast web content discovery; handles redirects and response filtering.
  • Wappalyzer -- Browser extension for passive technology fingerprinting.
  • SecLists -- The industry-standard wordlist collection; directory enumeration, usernames, passwords, API endpoints, fuzzing payloads.

What's next

Week 5 is the first time you actively look for exploitable vulnerabilities (as opposed to gathering information about the attack surface). Nessus and Nuclei automate the initial scan; the lecture teaches you why the triage step -- manually verifying and prioritizing scanner output -- is more important than the scan itself.