Web Application Hacking

Novice testers open Burp, enable intercept, and start throwing single quotes. Experts first learn what the application does, who can do it, and where the application trusts the client. A complete map turns a sprawling SPA into a finite checklist of endpoints, roles, and data objects. Without that map, you re-test login fifty times and never notice the export job that dumps customer PII with a sequential ID.

Mapping is not passive. Every click, form submit, and XHR should be logged: method, path, parameters, cookies, JSON body fields, and which role performed the action. Burp Target and HTTP history become your living inventory. When the engagement ends, that inventory is also evidence that you covered the product rather than a random subset of pages.

Treat mapping as iterative. First pass as an unauthenticated user. Second as a low-privilege user. Third as an admin or privileged role if the RoE provides accounts. Differences between those maps are often your highest-signal authorization findings.

Build a simple matrix: rows are roles (anonymous, user A, user B, admin); columns are objects and actions (view profile, edit profile, view order, cancel order, list users). As you walk the app, mark allowed, denied, or untested. Authorization bugs appear when a cell that should be denied succeeds — especially horizontal IDOR where user A reaches user B objects, and vertical escalation where a user reaches admin functions.

IDs in URLs, request bodies, and tokens are not decoration. Note every identifier: UUIDs, sequential integers, usernames, account numbers, document keys. Predictability plus missing server-side ownership checks is a classic high-impact pattern. When IDs are opaque, still test by substituting another user's captured ID from a second session.

Multi-step workflows (checkout, password reset, onboarding wizards) deserve special attention. State machines often enforce steps only in the UI. Replaying step three without step two, reusing tokens across users, or skipping confirmation endpoints is core business-logic testing — still an OWASP concern even when no classic injection exists.

A trust boundary is any place data or identity crosses from less trusted to more trusted: browser to origin server, origin to microservice, app to database, app to filesystem, app to cloud metadata. Injection and SSRF live at those boundaries. When you map, annotate where user input is stored, rendered, or used to build URLs, file paths, queries, or commands.

High-value functions for professional tests include authentication and session management, password reset and MFA enrollment, account linking, file upload/download, search and reporting, admin consoles, webhook receivers, import/export, and any integration that reaches internal networks. These functions concentrate risk because they combine sensitive data with elevated capability.

Modern apps hide surface in JavaScript bundles, mobile APIs, and undocumented admin hosts. Review loaded scripts for API base paths, feature flags, and hardcoded endpoints. Spidering alone is insufficient when critical routes never appear as HTML links.

The OWASP Top 10 and Testing Guide give shared vocabulary with clients and developers. Use them to organize notes and remediations, not as a score-chasing checklist that forces every item into every report. Broken Access Control often outranks injection in real impact; security misconfiguration may be a single header, or an entire debug console on production.

When you find an issue, classify it by root cause and impact. Is this injection? Access control? Cryptographic failure? Insecure design? That classification drives remediation: parameterized queries differ from adding CSRF tokens. Clients act faster when the finding maps to a familiar category and a concrete fix class.

PortSwigger Web Security Academy and intentionally vulnerable labs (Juice Shop, WebGoat, DVWA in isolated networks) are the curriculum backbone. Treat academy labs as deliberate practice: understand the sink, craft the proof, write the client-facing sentence, then move on. Authorized lab only — never practice payloads against systems you do not own or have written permission to test.

Configure a browser to proxy through Burp with a trusted CA for HTTPS interception on lab targets. Scope the project to in-scope hosts so Intruder and Scanner noise stay controlled. Walk every menu, form, and role switch. Rename interesting requests in history. Add comments for hypotheses: possible IDOR on orderId, reflects search term, uploads to /files/.

Export or screenshot the Target site map after major mapping sessions. Cross-check against your role matrix. Any authenticated endpoint that never appeared under a lower role should be tested for direct access. Any parameter present only in POST bodies of multi-step flows should still be fuzzed later with content discovery techniques.

Leave mapping with three deliverables: (1) endpoint inventory, (2) role/object matrix with priority marks, (3) a short list of first exploitation hypotheses ordered by business risk. That package is what separates structured assessment from tool-driven thrashing.

Time is finite. Rank surfaces by sensitivity of data, privilege of action, and likelihood of server-side trust in client input. Prefer proving one solid access-control issue over collecting twenty low-severity fingerprint findings. Experts write the impact sentence early: who is affected, what can be done, what business process breaks.

Capture evidence as you map: response status when a lower role hits an admin path, error messages that leak stack traces, cookies without Secure/HttpOnly in a lab comparison. Mapping notes feed the report directly; you should not re-discover the same path during write-up week.

Stay proportional. On production engagements, prefer read-only proofs and single-record demonstrations. Destructive tests (mass delete, full dump) need explicit RoE language. In labs, you can be more thorough — still document as if a client will read it.

Injection is not a family of magic strings; it is user-controlled data reaching an interpreter without adequate separation of code and data. The interpreter might be SQL, a shell, a template engine, LDAP, or a browser's HTML/JS parser. Your job is to find the sink, characterize how input is embedded, and craft the minimum proof that demonstrates risk under authorization.

Always start from observed behavior. Does the parameter change query results? Does a quote produce a database error? Does a template expression evaluate? Does input reappear in HTML attributes or script contexts? Hypothesize the sink language before escalating payloads. Random payload lists without a model waste time and generate noise defenders will rightly ignore.

On production engagements, prefer non-destructive proofs: boolean confirmation, single-row reads of non-sensitive columns, harmless time delays within agreed limits, or XSS that alerts in your own session. Full database dumps and reverse shells require explicit RoE. In labs such as DVWA, WebGoat, and PortSwigger, you may practice deeper exploitation while still writing notes as if impact must be justified.

Detection: inject benign syntax probes (' " )) -- # /*) and compare responses. Look for errors, differential content lengths, and logic flips when boolean conditions change (AND 1=1 vs AND 1=2). For blind cases, use measurable differences carefully — short sleeps only if RoE allows timing tests, or out-of-band channels only on authorized infrastructure.

Once confirmed, determine database family and injection context (WHERE clause, ORDER BY, INSERT). Stacked queries may or may not be available. UNION-based extraction needs matching column counts and types. Prefer extracting version, current user, and a single non-sensitive sample over vacuuming entire tables during client work.

sqlmap is an accelerator after you have a working parameter and request. Feed it a saved Burp request, restrict risk/level appropriately, and point it only at lab or in-scope URLs. Understand what it is doing: DBMS fingerprinting, technique selection, and dump stages. Blindly maxing --level/--risk against production login forms is how accounts lock and relationships end.

Command injection appears when apps build shell strings from input: diagnostics (ping, traceroute), filename conversion, backup tools, or legacy admin utilities. Probes include separators (; | || & && ` $()) adapted to OS and API. Prefer out-of-band or timing proofs in sensitive environments; in labs, a controlled whoami/id demonstration is enough for learning.

Server-Side Template Injection (SSTI) shows when template expressions like {{7*7}} or ${7*7} evaluate in rendered output. Identify the engine (Jinja, Twig, Freemarker, etc.) because exploitation paths differ. Goal in professional testing is usually proof of code execution risk or secret read capability with minimal damage — not ransomware-style impact demos.

Both classes often sit behind weak input validation that regex-blacklists a few characters. Encoding, alternative separators, and second-order injection (data stored safely then used unsafely later) defeat shallow filters. Document the filter bypass as part of the finding so developers do not ship a slightly longer blacklist.

XSS is injection into a browser context. Map where input is reflected or stored, then identify context: HTML body, attribute, JavaScript string, URL, or SPA DOM sink. Payloads that work in one context fail in another. CSP, HttpOnly cookies, and framework auto-escaping change impact; still report XSS when script execution is demonstrated, with honest notes on exploitability.

Reflected XSS often needs social engineering of a URL; stored XSS can hit admins viewing a ticket queue. DOM XSS may never hit the server. Use dalfox or similar scanners as assistants after manual discovery of reflection points. Manual control in Burp Repeater remains essential for encoding edge cases and WAF evasion research in labs.

Proportional proof: a dialog showing document.domain or a controlled beacon to an Interactsh-style OOB domain you operate for the engagement. Avoid cookie-stealing demos against real users. In labs, practice polyglots and filter bypasses, then write the remediation as output encoding plus CSP defense-in-depth.

nuclei templates catch known CVEs and misconfigurations quickly across many hosts. Use tagged templates relevant to the tech fingerprint; do not fire every community template blindly at a fragile production host. Tune rate limits. Save JSON/markdown output into the engagement folder.

Specialized tools (sqlmap, dalfox, tplmap, ssrfmap) shine when the sink class is known. They fail when auth flows are complex, CSRF tokens rotate, or logic is multi-step. Be ready to convert any automated success into a minimal manual reproduction for the report — clients and retesters need a short curl or Burp request, not a 400-line tool log.

False positives are a professional risk. Verify. A nuclei match that does not reproduce manually is not a finding. Conversely, absence of scanner hits means nothing if you never tested authorization or business logic.

A strong injection finding includes: exact endpoint and parameter, authentication requirements, technique used, redacted sample output, and business impact (read customer data, bypass login, RCE on app host). Screenshots plus raw request/response pairs beat vague claims.

Remediation must match the sink: parameterized queries / ORM bind parameters for SQLi; avoid shelling out or use strict allowlists for commands; auto-escaping and sandboxing for templates; context-aware encoding and CSP for XSS. Least-privilege database and OS accounts reduce blast radius even when bugs remain.

Second-order and chained issues deserve narrative: XSS in admin panel plus CSRF, or SQLi that yields password hashes leading to credential attacks in Module 6. Chain only as far as authorization and objectives require; stop when risk is proven.

Production applications accumulate dead admin panels, old API versions, backup files, staging virtual hosts, and debug routes that never appear in the marketing site. Attackers and professional testers both know that the linked UI is the best-tested surface; the forgotten surface is where defaults and verbose errors survive.

Discovery without discipline produces megabytes of noise. Every soft-404 that returns 200 OK will bury real hits if you filter only on status codes. Learn to baseline response length, word count, and hash. ffuf and feroxbuster become precise instruments when you invest in filter calibration on each target.

Stay in scope: vhost and DNS discovery can touch sibling hosts that are out of bounds. Confirm which hostnames and IP ranges are authorized before aggressive virtual-host fuzzing. Authorized lab only for learning exercises.

Start with a focused wordlist sized to the engagement window (SecLists discovery lists, tech-specific lists for common platforms). Use extensions appropriate to the stack: .php, .aspx, .bak, .old, .git, .env, .zip. Recursion is powerful and noisy — enable it when the tree is shallow or after interesting directories appear.

Calibrate filters: run a known-bad path, note length/words/lines, then filter those out. Watch for WAFs that throttle; lower threads and randomize delays on fragile apps. Authenticated fuzzing often finds more: provide session cookies or tokens so discovery covers role-gated areas without inventing new auth bypasses first.

Interesting hits include backup archives, config samples, source maps, .git directories, actuator endpoints, swagger/openapi docs, and admin paths returning 401/403 (still valuable — auth gates can be tested for weak credentials later under RoE). Record full URLs and response characteristics in notes immediately.

Many reverse proxies route on Host headers. Fuzzing Host values against an IP can reveal internal names, staging apps, or legacy brands. Use wordlists of company names, environment labels (staging, dev, admin), and names from OSINT/certificate transparency when authorized.

Confirm that discovered vhosts are in scope before deeper testing. A response that differs in title or length is a lead, not yet a vulnerability. Follow with mapping as in the previous lesson.

DNS and TLS certificate SANs remain complementary: content discovery on HTTP does not replace proper recon from earlier modules, but it finds what DNS never advertised.

Hidden parameters drive mass assignment, debug modes (debug=1, test=true), alternate views, and injection points never shown in forms. Mine Burp history, JavaScript, and archived URLs (wayback/paramspider-style workflows) for candidate names. Arjun and similar tools brute common parameter names against endpoints that accept flexible query/body parsing.

For each new parameter that changes behavior, add it to the injection and access-control test queues. A parameter that adds fields to a JSON response may enable data over-disclosure; one that alters pricing or role flags is business-logic gold.

Document parameter discovery as its own mini-methodology: source of name, endpoint, method, observed effect, follow-up tests planned. That prevents lost leads during long assessments.

REST APIs need object-level authorization tests on every resource ID. Replay user A's token against user B's /api/orders/{id}. Test verb tampering (GET vs DELETE), content-type switches, and version prefixes (/v1 vs /v2). OpenAPI/Swagger docs, when exposed, are both a map and sometimes an over-exposed artifact worth reporting if they reveal internal-only routes on production.

GraphQL consolidates many operations on one endpoint. Introspection (if enabled) lists types and mutations — treat that as recon. Test batching, nested queries for denial-of-service risk only when RoE allows, and authorization on each mutation/field. graphql-tools and manual Postman/Burp collections help structure coverage.

Token handling matters: JWTs in localStorage vs cookies, refresh flows, and API keys in headers. jwt-tool assists analysis of algorithm confusion and claim tampering in labs. Always test whether expired or other-user tokens are accepted on sensitive operations.

Not every discovered path is a vulnerability. Exposed .git or backup files that yield source may be critical. An open Swagger UI on an external API may be medium informational or higher if it enables efficient abuse. Frame findings by confidentiality of exposed data and whether the path bypasses intended access models.

Feed discovery results back into mapping and injection lessons: new endpoints need role tests and sink analysis. Keep wordlist hits organized so retests can confirm remediation (path gone, now 404, or properly authenticated).

Rate and noise control are professional ethics: discovery should not become accidental DoS. Coordinate with RoE for aggressive scans on shared infrastructure.