CWE-88 Argument Injection or Modification


What is ‘Argument Injection or Modification’ ?

Argument injection is a type of attack based on tampering with input parameters of a page.

This can enable attackers to see data which they normally cannot see or to modify data which they normally cannot modify, via the user interface.

What is the impact ?

Argument injection can usually be used to obtain various information.

The weakness allows attackers to access potentially sensitive information, trigger unintended commands or code execution or cause other unintended behavior.

The attacker can, for example, read pages or view images belonging to different users and so on.

The threat usually depends on the sensitivity of the information. But sometimes, the attacker can read invoices or other kind on sensitive information.

And the worst case is if the attacker can change something.

When it was introduced ?

The vulnerability is introduced during Architecture and Design, Implementation stages.

Some Examples

Example 1

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

Example Language: C

int main(int argc, char** argv) {
    char cmd[CMD_MAX] = "/usr/bin/cat ";
    strcat(cmd, argv[1]);

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected.

However, if an attacker passes a string of the form

; rm -rf /

, then the whole command will be like:

/usr/bin/cat; rm -rf /

The call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Example 2

The following code takes untrusted input and uses a substring function to filter a 3-character “../” element located at the 0-index position of the input string. It then appends this result to the /home/user/ directory and attempts to read the file in the final resulting path.

Example Language: Perl

$Username = substr($Username, 3);
if (substr($Username, 0, 3) eq '../') {
	$Username = substr($Username, 3);
my $filename = "/home/user/" . $Username;

Since the if function is only looking for a substring of “../” between the 0 and 2 position, it only removes that specific “../” element. So an input value such as:


will have the first “../” filtered, resulting in:


This value is then concatenated with the /home/user/ directory:


which causes the /etc/passwd file to be retrieved once the operating system has resolved the ../ sequences in the pathname. This leads to relative path traversal .

Example 3

The following code, victim.php, attempts to include a function contained in a separate PHP page on the server. It builds the path to the file by using the supplied ‘module_name’ parameter and appending the string ‘/function.php’ to it.

Example Language: PHP

$dir = $_GET['module_name'];
include($dir . "/function.php");

The problem with the above code is that the value of $dir is not restricted in any way, and a malicious user could manipulate the module_name parameter to force inclusion of an unanticipated file. For example, an attacker could request the above PHP page (example.php) with a module_name of “” by using the following request string:


Upon receiving this request, the code would set module_name to the value “” and would attempt to include, along with any malicious code it contains.

For the sake of this example, assume that the malicious version of function.php looks like the following:


An attacker could now go a step further in our example and provide a request string as follows:


The code will attempt to include the malicious function.php file from the remote site. In turn, this file executes the command specified in the ‘cmd’ parameter from the query string. The end result is an attempt by tvictim.php to execute the potentially malicious command, in this case:

/bin/ls -l

Note that the above PHP example can be mitigated by setting allow_url_fopen to false, although this will not fully protect the code. See potential mitigations.


After getting the idea of what this vulnerability is about and how to reproduce it, we should then focus on the actions to prevent it. Same as the timing of the introduction, the prevention of this weakness comes in design and implementation phases. In addition to those two phases, testing is also an reasonable phase for pinpointing any potential risks.

The most practical and widely-used strategy is input validation. As the name suggests, this strategy involves enforcing restrictions on the input. To this end, we need to gain insight into the potential areas where the untrusted input could enter the system at the early stage of software development,like the phase of architecture and design. The source of the input data could be a parameter, http request, cookies, files on disk, stream from socket, etc. So the input validation has to be performed in the interfaces that data comes in.

When doing the real check on the input, a whitelist should be adopted. The whitelist prescribes what the incoming data should be strictly conformed to. If the data does not meet the specification, it could be dropped or transformed into something that does. The validation should be conducted on all potential properties, like type, range, syntax, business rule, etc.

Why not blacklist? The truth is relying solely on blacklist would leave out at least one type of the undesirable input. Even for the most sophisticated developers, they could not name all possible malicious input. The left-out area would give attackers enough room to play around.

Relevance with other weaknesses

Command Injection

As example 1 stated, developer are not aware of the potential vulnerability or danger when trying invoke system function by recieving parameters from user. By executing such functions, the application gives an attacker a privilege or capability that they would not otherwuse have.

Here is a example aiming to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run the shell script to delete temporary files.

String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K \"
c:\\util\\rmanDB.bat "


Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form “& del c:\dbms\.”, then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Injecting on input field

This attack occurs when the malicious user finds the vulnerable parts of the website and sends it as appropriate malicious input. Malicious script is being injected into the code and then sent as the output to the final user. Here is a simple example online.

Many testers mix up Cross Site Scripting attack with Javascript Injection, which is also being performed on the client side. In both, the attacks malicious script is being injected. However, in the XSS attack case