UnsafeShellCommandConstruction.qhelp

<!DOCTYPE qhelp PUBLIC
"-//Semmle//qhelp//EN"
"qhelp.dtd">
<qhelp>
<overview>
	<p>
		Dynamically constructing a shell command with inputs from library 
		functions may inadvertently change the meaning of the shell command.
		
		Clients using the exported function may use inputs containing
		characters that the shell interprets in a special way, for instance
		quotes and spaces.

		This can result in the shell command misbehaving, or even
		allowing a malicious user to execute arbitrary commands on the system.
	</p>


</overview>
<recommendation>

	<p>
		If possible, provide the dynamic arguments to the shell as an array 
		to APIs such as <code>subprocess.run</code> to avoid interpretation by the shell.
	</p>

	<p>
		Alternatively, if the shell command must be constructed
		dynamically, then add code to ensure that special characters 
		do not alter the shell command unexpectedly.
	</p>

</recommendation>
<example>

	<p>
		The following example shows a dynamically constructed shell
		command that downloads a file from a remote URL.
	</p>

	<sample src="examples/unsafe-shell-command-construction.py" />

	<p>
		The shell command will, however, fail to work as intended if the
		input contains spaces or other special characters interpreted in a 
		special way by the shell. 
	</p>

	<p>
		Even worse, a client might pass in user-controlled
		data, not knowing that the input is interpreted as a shell command. 
		This could allow a malicious user to provide the input <code>http://example.org; cat /etc/passwd</code>
		in order to execute the command <code>cat /etc/passwd</code>.
	</p>

	<p>
		To avoid such potentially catastrophic behaviors, provide the
		input from library functions as an argument that does not
		get interpreted by a shell:
	</p>

	<sample src="examples/unsafe-shell-command-construction_fixed.py" />

</example>
<references>

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

</references>
</qhelp>