Scripting language injection
A scripting language injection vulnerability is present when user input is interpreted as code. In many cases, this leads to compromise of the server as the attacker is able to execute code within the security context of the interpreter process.
Because user-submitted data is passed to the
eval function, the calculator functionality of CMA is vulnerable to scripting language injection. Both the X and Y inputs can be used to execute arbitrary code, but because they are of the number type, client-side restrictions have to be bypassed. This bypass can be achieved by using a web debugging proxy:
or by creating the query string manually:
The effects of the scripting injection attacks on the evaluated code are:
echo 1 + 1;system("calc"); and here:
echo 1;system("calc");// + 1;
Avoid evaluating user input as code. Relevant functionality can usually be created by using safer API functions (this is the approach taken in Listing 28). If it cannot be avoided, apply strict validation (whitelist if possible), and reject any input that is deemed unsafe. Do not attempt to sanitize user input.
Listing 28. Rewritten calculator logic
<?php $x = $_GET["x"]; $y = $_GET["y"]; $operation = $_GET["operation"] == "operation-add" ? "+" : "-"; // Patched reflected XSS vulnerability $arithmetic = htmlentities("$x $operation $y"); echo $arithmetic . " = "; if ($operation == "+") echo $x + $y; else echo $x - $y; ?>
Because use of
eval is avoided in the updated code, it is secured against script language injection.
The next section explains how arbitrary file creation can be exploited to a similar effect.