Other injections: commands, LDAP and NoSQL

SQL injection is the most famous member of a large family. The pattern is always the same: a program builds an instruction by gluing user input into text, then hands that text to an interpreter. Change the interpreter and you change the name of the flaw: operating system, directory service, document database. In this lesson you learn to recognise the family resemblance.

The general model

Every injection has three ingredients:

1. An interpreter that executes instructions: a database engine, a shell, a directory server, a template engine.
2. A command built as text by the application, combining fixed parts and user input.
3. Input containing special characters of that interpreter’s language that change the structure of the command.

Once you grasp this, every new injection type becomes an easy extension: only the vocabulary changes. You ask, “what interpreter receives my input, and what characters have a special meaning in its language?”

OS command injection

Some applications call operating system commands to perform a task: pinging a host for a diagnostic page, converting an image, compressing a file. If the user’s value is concatenated into the command line, it may carry shell metacharacters that add or alter commands.

A deliberately vulnerable PHP example, typical of a “network diagnostic” page in a training app:

$host = $_POST['host'];
$output = shell_exec("ping -c 1 " . $host);
echo "<pre>" . $output . "</pre>";

The developer expects an address, but the shell treats certain characters, such as separators between commands, as instructions. The program therefore may execute whatever command follows. The impact is typically severe, because commands run with the privileges of the web server’s user, which may allow reading files, altering the system, or pivoting into the internal network.

The DVWA “Command Injection” module is made exactly for this. At the low level there is no filtering; at higher levels, naive filters block some characters, which illustrates a recurring lesson: blacklists of dangerous characters are fragile, because attackers have many variations while defenders must anticipate them all.

How a tester recognises it

• The feature visibly performs a system task: ping, DNS lookup, file conversion, report generation.
• The output looks like that of a system command.
• Delays or differences in response appear when the input changes the command’s behaviour (the blind version of the flaw).

LDAP injection

LDAP (Lightweight Directory Access Protocol) is widely used in companies to store accounts, groups and contacts, and to handle login in internal tools. Searches are expressed as filters in a specific syntax with parentheses. If an application builds a filter by concatenating the username, the characters that structure the filter can be abused to change its meaning, for instance to make a login filter match any entry.

// Vulnerable: the filter is built from the user input
$filter = "(&(uid=" . $username . ")(userPassword=" . $password . "))";

The effects range from authentication bypass to leaking directory information. You are more likely to meet LDAP in internal corporate applications than on public websites, which is why it is often found during internal assessments. The remedy is the same family of ideas: escape the special characters of the LDAP language according to context and use the library’s safe filter-building functions.

NoSQL injection

“NoSQL” databases, such as document stores, do not use SQL, so some developers assume they are immune. They are not. Two typical weak points:

• Query operators in the input. Many NoSQL systems use structured queries with operators such as “not equal” or “greater than”, expressed in JSON. If the application takes the user’s JSON (or form data that is converted into structured objects) and uses it as is in the query, a user might supply an operator in place of a plain value, turning “the password equals X” into something like “the password is not equal to X”, which matches almost anything.
• Server-side JavaScript. Some databases allow evaluating JavaScript expressions in queries, and building them from input mixes data and code again.

// Vulnerable idea: the whole object from the request is used as the filter
const user = await users.findOne({ name: req.body.name, password: req.body.password });

If the front end sends text for both fields but the API accepts JSON, a tester checks whether sending an object instead of a string changes how the query is understood. This is a good example of why you should look at the requests, not only at the interface. The remedy is to enforce types: convert and verify that each field is a string, number or other expected type before using it, and to use the query-building features of the driver.

Other relatives in the family

Type	Interpreter	Idea
Server-side template injection	Template engine	User input is treated as part of the template and can be evaluated
XPath / XML injection	XML query engine	Input alters an XML query or document structure
Header injection	HTTP	Line break characters in input let the user add headers to a response or an email
Log injection	Log files	Fake lines are inserted in logs to mislead investigators
Expression language injection	Framework expression evaluator	Input is evaluated as an expression by the framework

You do not need to learn them all now. Recognising the pattern prepares you to read the OWASP Testing Guide pages on each one when you need them.

The shared root cause

Look at the four vulnerable snippets in this chapter so far: SQL, shell, LDAP and NoSQL. All of them mix code and data in the same string or object. Whatever the language, the solution is to keep them separated: pass the data through a channel that the interpreter cannot confuse with instructions, or avoid the interpreter altogether. We cover this in detail in the next lesson.

Your turn: name the interpreter

For each feature, say which interpreter is probably behind it and which injection you would put on your test list: (1) a “check if this server is online” page in an admin tool, (2) a company intranet login that authenticates against the corporate directory, (3) a mobile app API at /api/login that accepts JSON and uses a document database, (4) an invoice generator that builds a document from a template using customer-supplied text.

See a solution

1. The server check probably calls a system command: OS command injection.
2. Directory authentication: LDAP injection.
3. JSON login with a document database: NoSQL injection (types and operators in the input).
4. Template-based generation with user content: server-side template injection.

In each case the first test is the same as in the previous lesson: record normal behaviour, then change one thing at a time in a lab and observe. Add the four lines to your inventory with the word “interpreter”.

Now for the good news: injections are among the most preventable flaws there are. Let us see how.