IndirectCommandInjection.qhelp

<!DOCTYPE qhelp PUBLIC
"-//Semmle//qhelp//EN"
"qhelp.dtd">
<qhelp>
	<overview>

		<p>

			Forwarding command-line arguments to
			<code>child_process.exec</code> or some other library routine that
			executes a system command within a shell can change the meaning of the
			command unexpectedly due to unescaped special characters.

		</p>

		<p>

			When the forwarded command-line arguments come from a parent
			process that has not escaped the special characters in the arguments,
			then the parent process may indirectly be vulnerable to command-line
			injection since the special characters are evaluated unexpectedly.

		</p>

	</overview>
	<recommendation>

		<p>

			If possible, use hard-coded string literals to specify the
			command to run or library to load. Instead of forwarding the
			command-line arguments to the process, examine the command-line
			arguments and then choose among hard-coded string literals.

		</p>

		<p>

			If the applicable libraries or commands cannot be determined
			at compile time, then add code to verify that each forwarded
			command-line argument is properly escaped before using it.

		</p>

		<p>

			If the forwarded command-line arguments are part of the
			arguments of the system command, prefer a library routine that handles
			the arguments as an array of strings rather than a single concatenated
			string. This prevents the unexpected evaluation of special characters.

		</p>

		<p>

			In the latter case, if you are given the arguments as a single
			string, note that it is not safe to simply split the string on
			whitespace, since an argument may contain quoted whitespace which
			would cause it to be split into multiple arguments. Instead, use a
			library such as <code>shell-quote</code> to parse the string into an
			array of arguments.

		</p>

	</recommendation>
	<example>

		<p>

			The following wrapper script example executes another
			JavaScript file in a child process and forwards some command-line
			arguments. This is problematic because the special characters in the
			command-line arguments may change the meaning of the child process invocation
			unexpectedly. For instance, if one of the command-line arguments is
			<code>"dollar$separated$name"</code>, then the child process will
			substitute the two environment variables <code>$separated</code> and
			<code>$name</code> before invoking <code>node</code>.

		</p>

		<sample src="examples/indirect-command-injection.js" />

		<p>

			If another program uses <code>child_process.execFile</code> to
			invoke the above wrapper script with input from a remote user, then
			there may be a command-line injection vulnerability.

			This may be surprising, since a command-line invocation with
			<code>child_process.execFile</code> is generally considered safe.  But
			in this case, the remote user input is simply forwarded to the
			problematic <code>process.exec</code> call in the wrapper script.

		</p>

		<p>

			To guard against this, use an API that does not perform environment
			variable substitution, such as <code>child_process.execFile</code>:

		</p>

		<sample src="examples/indirect-command-injection_fixed.js" />

	</example>

	<references>

		<li>
			OWASP:
			<a href="https://www.owasp.org/index.php/Command_Injection">Command Injection</a>.
		</li>

		<li>
			npm:
			<a href="https://www.npmjs.com/package/shell-quote">shell-quote</a>.
		</li>

	</references>

</qhelp>