WebOTG-ID-001 — Injection Security Review

Objective

Injection occurs when application-controlled data is incorporated into an interpreter or execution context in a way that allows the supplied data to influence the intended operation.

The vulnerability is not limited to SQL. Depending on the application architecture, injection can affect database queries, operating-system commands, directory services, template engines, expression languages, XML processors, interpreters and other execution contexts.

Scope

Review all application-controlled input that reaches an interpreter or parser, including:

Prerequisites

Methodology

Injection testing should establish the complete path from an attacker-controlled input to the interpreter that consumes that input.

Test procedure

Input and sink mapping

A professional assessment should maintain a traceable relationship between an input source and the interpreter that ultimately consumes it.

Injection classes

Controlled reproduction

Reproduction should demonstrate the security property being violated without causing unnecessary damage to the target system or its data.

Baseline request

GET /products?search=example HTTP/1.1
Host: application.example
Accept: application/json

Controlled test input

GET /products?search=[controlled-test-value]
HTTP/1.1

Observe:

- HTTP status
- Response structure
- Error behavior
- Result-set changes
- Timing differences
- Application logs, where authorized

Confirming the finding

A reliable injection finding normally requires more than seeing a database error. The tester should establish that the input changes interpreter behavior in a way that is attributable to the tested parameter.

Assessment

Failure criteria

Remediation

The preferred remediation is to eliminate the interpreter boundary where possible or use an API that maintains strict separation between data and executable instructions.

General controls

1. Use parameterized queries for relational database operations.
2. Use safe, structured APIs for NoSQL databases.
3. Avoid shell invocation when an equivalent direct API exists.
4. If command execution is unavoidable, use a restricted argument interface and strict allowlisting appropriate to the application.
5. Use context-specific encoding or escaping where required by the interpreter.
6. Apply allowlist validation to values with a clearly defined business format.
7. Avoid dynamically constructing executable template or expression content from untrusted input.
8. Use safe parser configurations for structured formats.
9. Apply least privilege to database and service accounts so that an injection flaw has reduced impact.
10. Do not rely on client-side validation as a security boundary.

SQL parameterization example

$stmt = $db->prepare(
    "SELECT id, name
     FROM products
     WHERE name = ?"
);

$stmt->bind_param("s", $search);

$stmt->execute();

Post-remediation verification

Evidence requirements

Classification

References

WebOTG should maintain the authoritative source references, document versions and review dates through its content management system rather than embedding mutable reference information into application logic.