TaintedPath.qhelp

<!DOCTYPE qhelp PUBLIC
  "-//Semmle//qhelp//EN"
  "qhelp.dtd">
<qhelp>
<overview>
<p>Accessing paths controlled by users can allow an attacker to access unexpected resources. This
can result in sensitive information being revealed or deleted, or an attacker being able to influence
behavior by modifying unexpected files.</p>

<p>Paths that are naively constructed from data controlled by a user may contain unexpected special characters,
such as "..". Such a path may potentially point to any directory on the file system.</p>

</overview>
<recommendation>

<p>Validate user input before using it to construct a file path. Ideally, follow these rules:</p>

<ul>
<li>Do not allow more than a single "." character.</li>
<li>Do not allow directory separators such as "/" or "\" (depending on the file system).</li>
<li>Do not rely on simply replacing problematic sequences such as "../". For example, after applying this filter to
".../...//" the resulting string would still be "../".</li>
<li>Use a whitelist of known good patterns.</li>
<li>Sanitize potentially tainted paths using <code>HttpRequest.MapPath</code>.</li>
</ul>

</recommendation>
<example>

<p>In the first example, a file name is read from a <code>HttpRequest</code> and then used to access a file. However, a
malicious user could enter a file name which is an absolute path - for example, "/etc/passwd". In the second example, it
appears that the user is restricted to opening a file within the "user" home directory. However, a malicious user could
enter a filename which contains special characters. For example, the string "../../etc/passwd" will result in the code
reading the file located at "/home/[user]/../../etc/passwd", which is the system's password file. This file would then be
sent back to the user, giving them access to all the system's passwords.</p>

<sample src="TaintedPath.cs" />

</example>
<references>

<li>
OWASP:
<a href="https://www.owasp.org/index.php/Path_traversal">Path Traversal</a>.
</li>

</references>
</qhelp>