|
| 1 | +<!DOCTYPE qhelp PUBLIC |
| 2 | + "-//Semmle//qhelp//EN" |
| 3 | + "qhelp.dtd"> |
| 4 | +<qhelp> |
| 5 | +<overview> |
| 6 | +<p>Accessing paths controlled by users can allow an attacker to access unexpected resources. This |
| 7 | +can result in sensitive information being revealed or deleted, or an attacker being able to influence |
| 8 | +behavior by modifying unexpected files.</p> |
| 9 | + |
| 10 | +<p>Paths that are naively constructed from data controlled by a user may be absolute paths, or may contain |
| 11 | +unexpected special characters such as "..". Such a path could point anywhere on the file system.</p> |
| 12 | + |
| 13 | +</overview> |
| 14 | +<recommendation> |
| 15 | + |
| 16 | +<p>Validate user input before using it to construct a file path.</p> |
| 17 | + |
| 18 | +<p>Common validation methods include checking that the normalized path is relative and does not contain |
| 19 | +any ".." components, or checking that the path is contained within a safe folder. The method you should use depends |
| 20 | +on how the path is used in the application, and whether the path should be a single path component. |
| 21 | +</p> |
| 22 | + |
| 23 | +<p>If the path should be a single path component (such as a file name), you can check for the existence |
| 24 | +of any path separators ("/" or "\"), or ".." sequences in the input, and reject the input if any are found. |
| 25 | +</p> |
| 26 | + |
| 27 | +<p> |
| 28 | +Note that removing "../" sequences is <i>not</i> sufficient, since the input could still contain a path separator |
| 29 | +followed by "..". For example, the input ".../...//" would still result in the string "../" if only "../" sequences |
| 30 | +are removed. |
| 31 | +</p> |
| 32 | + |
| 33 | +<p>Finally, the simplest (but most restrictive) option is to use an allow list of safe patterns and make sure that |
| 34 | +the user input matches one of these patterns.</p> |
| 35 | + |
| 36 | +</recommendation> |
| 37 | +<example> |
| 38 | + |
| 39 | +<p>In this example, a user-provided file name is read from a HTTP request and then used to access a file |
| 40 | +and send it back to the user. However, a malicious user could enter a file name anywhere on the file system, |
| 41 | +such as "/etc/passwd" or "../../../etc/passwd".</p> |
| 42 | + |
| 43 | +<sample src="examples/TaintedPath.rs" /> |
| 44 | + |
| 45 | +<p> |
| 46 | +If the input should only be a file name, you can check that it doesn't contain any path separators or ".." sequences. |
| 47 | +</p> |
| 48 | + |
| 49 | +<sample src="examples/TaintedPathGoodNormalize.rs" /> |
| 50 | + |
| 51 | +<p> |
| 52 | +If the input should be within a specific directory, you can check that the resolved path |
| 53 | +is still contained within that directory. |
| 54 | +</p> |
| 55 | + |
| 56 | +<sample src="examples/TaintedPathGoodFolder.rs" /> |
| 57 | + |
| 58 | +</example> |
| 59 | +<references> |
| 60 | + |
| 61 | +<li> |
| 62 | +OWASP: |
| 63 | +<a href="https://owasp.org/www-community/attacks/Path_Traversal">Path Traversal</a>. |
| 64 | +</li> |
| 65 | + |
| 66 | +</references> |
| 67 | +</qhelp> |
0 commit comments