Classroom Glossary Public page

Lab 8: Web Application Exploitation

1,034 words

Week 8 graded lab. SQL injection, XSS, SSRF, IDOR, file upload, deserialization. Juice Shop + WebGoat. Local Docker only.

Learning objectives

  • Execute manual SQL injection to bypass authentication and extract data
  • Trigger reflected and stored XSS vulnerabilities
  • Identify and exploit IDOR vulnerabilities through API inspection
  • Bypass file-upload restrictions and understand the attack vectors
  • Perform a basic SSRF attack
  • Document each attack in reproducible finding format

Authorization

Targets: OWASP Juice Shop at http://127.0.0.1:3000 and OWASP WebGoat at http://127.0.0.1:8080/WebGoat. Both run in Docker on your local Kali VM.

Do not run these attacks against any external target.

Pre-lab setup

# Verify both containers are running:
sudo docker ps | grep -E "juice-shop|webgoat"

# Start session logging:
mkdir -p ~/pen101-workspace/lab-08
script -a ~/pen101-workspace/lab-08/session.log

# Configure Firefox proxy to Burp Suite (127.0.0.1:8080) if not already done
# This captures all traffic to and from both applications

Juice Shop Exercises

Exercise 1: SQL injection login bypass

Objective: Log in to Juice Shop as the admin user without knowing the password.

Step 1: Identify the login endpoint

Navigate to http://127.0.0.1:3000/#/login. Intercept the login request in Burp Suite (Proxy > Intercept > On; submit a normal login attempt to capture the request).

Burp will show a POST to /rest/user/login with a JSON body like:

{"email":"test@test.com","password":"test"}

Step 2: Test for injection

Send the request to Burp Repeater (right-click > Send to Repeater). In Repeater, modify the email field:

{"email":"' OR '1'='1","password":"anything"}

Or the classic MySQL form:

{"email":"admin@juice-sh.op'--","password":"anything"}

If the application returns a user object (not an error), SQL injection is confirmed and you are authenticated.

Screenshot required: The Burp Repeater response showing a successful authentication (200 OK with a user token in the response body).

Finding documentation: Which specific character(s) triggered the injection? What does the -- comment operator do in SQL? Write the full finding in five-part format.

Exercise 2: Reflected XSS

Objective: Find a reflected XSS vulnerability and execute a payload in the browser.

Approach: Search Juice Shop's UI for any place where user-controlled input is reflected in the page without encoding. Common locations: search bars, feedback forms, product names in URLs.

Test the search bar by searching for:

<script>alert(document.domain)</script>

If this returns an alert box, reflected XSS is confirmed. If not, look for other reflection points.

Check the URL structure when you search: does the search term appear in the URL? Does it appear in the page HTML source? Use Burp to inspect the response body for your injected string.

Screenshot required: The alert box showing the domain, or DOM manipulation showing your payload executed.

Finding documentation: Where is the reflection point? What encoding (if any) does the application apply to user input before reflecting it? Why does the payload execute?

Exercise 3: IDOR -- Access another user's order history

Objective: Access order data belonging to a user other than yourself.

Step 1: Create an account and place an order

Register for a new account at http://127.0.0.1:3000/#/register. Log in. Add an item to the basket and complete the checkout process (no real payment is processed).

Step 2: Find the order API endpoint

In Burp's HTTP History, look for requests to /api/orders or /rest/track-order/ that appear after checkout. Note the order ID format.

Step 3: Enumerate other orders

If the order ID is predictable (sequential integers, or a short alphanumeric string), modify it in Burp Repeater to retrieve another user's order data.

GET /rest/track-order/1001
GET /rest/track-order/1002
GET /rest/track-order/1003

If the application returns data for an order you did not place, IDOR is confirmed.

Screenshot required: A Burp Repeater response showing order data for a user other than yourself (note: if the response contains a name or email, you have demonstrated data exposure).

Finding documentation: What is the predictability pattern of the order ID? What data is exposed? CVSS v3.1 score: show the vector derivation.

Exercise 4: File upload bypass

Objective: Attempt to upload a file with a restricted extension and bypass the restriction.

Step 1: Find the upload endpoint

Juice Shop has a file upload endpoint in the complaint/feedback section. Navigate to http://127.0.0.1:3000/#/complain.

Step 2: Attempt a restricted file

Create a test PHP file:

echo '<?php system($_GET["cmd"]); ?>' > shell.php

Attempt to upload shell.php via the complaint form.

Step 3: Observe the restriction and attempt bypasses

Note what restriction the application applies (extension filter? MIME type? Magic bytes?). Attempt at least two bypasses:

  • Rename to shell.php.jpg -- does the application check the full extension or just the last one?
  • Change the Content-Type header in Burp from application/x-php to image/jpeg -- does the server trust the client-supplied MIME type?
  • Prepend a JPEG magic byte (FF D8 FF) before the PHP code

Document: What protection was in place (quote the error message)? Which bypass (if any) succeeded? If no bypass succeeded, explain what protection layer prevented it.

Exercise 5: SSRF

Objective: Force the Juice Shop server to make an HTTP request to an address you specify.

Find the endpoint: Juice Shop has a product image URL feature. When browsing product pages, look for requests that include a URL parameter that the server fetches. Check Burp HTTP History for requests containing URL-like parameters.

If found, test it with:

http://127.0.0.1:3000/   (loopback -- server requests itself)
http://169.254.169.254/latest/meta-data/  (AWS IMDSv1 -- will fail in local Docker but demonstrates the attack vector)

Use Burp Repeater to make the request and observe whether the server returns content from the specified URL.

Document: The vulnerable parameter, the payload, the response (or "not reachable in this lab environment" with an explanation of what would happen in a cloud-hosted application).

WebGoat Exercises

Exercise 6: SQL injection (WebGoat lesson)

Navigate to WebGoat > Injection Flaws > SQL Injection. Complete the SQL injection lesson.

Do not click through using the lesson's "Show Me" hints before attempting manually. Use Burp Suite to intercept the lesson's form submissions and attempt the injection payload yourself first.

After completing manually: document in the lab report:

  • Which field was injectable
  • What payload achieved the goal
  • What SQL query was being constructed (WebGoat often shows the query in the response)

Exercise 7: Insecure deserialization (WebGoat lesson)

Navigate to WebGoat > Insecure Deserialization. Complete the lesson.

In your lab report: explain what was being deserialized unsafely. What class of object? What programming language? What is the attack vector (does the attacker control the serialized bytes directly)?

Deliverable

A lab report with seven sections (one per exercise). Each section in five-part finding format:

  1. Finding title
  2. CVSS v3.1 score + vector string
  3. Description (what and why)
  4. Evidence (Burp Repeater screenshots; exact requests and responses)
  5. Business impact in client-addressable language
  6. Remediation (specific, not generic)

The Lab 8 evidence requirement is stricter than Lab 7: every finding must show the Burp Repeater view of the request AND the response, not just a browser screenshot.

Appendix: session.log from your script session; Burp HTTP History export (for both Juice Shop and WebGoat sessions).