|
2 | 2 | "-//Semmle//qhelp//EN"
|
3 | 3 | "qhelp.dtd">
|
4 | 4 | <qhelp>
|
5 |
| - |
6 | 5 | <overview>
|
7 |
| -<p> |
8 |
| -Accessing files using paths constructed from user-controlled data can allow an |
9 |
| -attacker to access unexpected resources. This can result in sensitive |
10 |
| -information being revealed or deleted, or an attacker being able to influence |
11 |
| -behavior by modifying unexpected files. |
12 |
| -</p> |
13 |
| -</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> |
14 | 12 |
|
| 13 | +</overview> |
15 | 14 | <recommendation>
|
16 |
| -<p> |
17 |
| -Validate user input before using it to construct a file path, either using an |
18 |
| -off-the-shelf library like <code>ActiveStorage::Filename#sanitized</code> in |
19 |
| -Rails, or by performing custom validation. |
| 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. |
20 | 25 | </p>
|
21 | 26 |
|
22 | 27 | <p>
|
23 |
| -Ideally, follow these rules: |
| 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. |
24 | 31 | </p>
|
25 | 32 |
|
26 |
| -<ul> |
27 |
| -<li>Do not allow more than a single "." character.</li> |
28 |
| -<li>Do not allow directory separators such as "/" or "\" (depending on the file |
29 |
| -system).</li> |
30 |
| -<li>Do not rely on simply replacing problematic sequences such as "../". For |
31 |
| -example, after applying this filter to ".../...//", the resulting string would |
32 |
| -still be "../".</li> |
33 |
| -<li>Use a whitelist of known good patterns.</li> |
34 |
| -</ul> |
35 |
| -</recommendation> |
| 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> |
36 | 35 |
|
| 36 | +</recommendation> |
37 | 37 | <example>
|
| 38 | + |
| 39 | +<p>In this example, a file name is read from a query parameter and then used to access a file |
| 40 | +and send it back over the socket. 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/tainted_path.rb" /> |
| 44 | + |
38 | 45 | <p>
|
39 |
| -In the first example, a file name is read from an HTTP request and then used to |
40 |
| -access a file. However, a malicious user could enter a file name which is an |
41 |
| -absolute path, such as <code>"/etc/passwd"</code>. |
| 46 | +If the input should only be a file name, you can check that it doesn't contain any path separators or ".." sequences. |
42 | 47 | </p>
|
43 | 48 |
|
| 49 | +<sample src="examples/tainted_path_normalize.rb" /> |
| 50 | + |
44 | 51 | <p>
|
45 |
| -In the second example, it appears that the user is restricted to opening a file |
46 |
| -within the <code>"user"</code> home directory. However, a malicious user could |
47 |
| -enter a file name containing special characters. For example, the string |
48 |
| -<code>"../../etc/passwd"</code> will result in the code reading the file located |
49 |
| -at <code>"/home/user/../../etc/passwd"</code>, which is the system's password |
50 |
| -file. This file would then be sent back to the user, giving them access to all |
51 |
| -the system's passwords. |
| 52 | +If the input should be within a specific directory, you can check that the resolved path |
| 53 | +is still contained within that directory. |
52 | 54 | </p>
|
53 | 55 |
|
54 |
| -<sample src="examples/tainted_path.rb" /> |
55 |
| -</example> |
| 56 | +<sample src="examples/tainted_path_folder.rb" /> |
56 | 57 |
|
| 58 | +</example> |
57 | 59 | <references>
|
58 |
| -<li>OWASP: <a href="https://owasp.org/www-community/attacks/Path_Traversal">Path Traversal</a>.</li> |
| 60 | + |
| 61 | +<li> |
| 62 | +OWASP: |
| 63 | +<a href="https://owasp.org/www-community/attacks/Path_Traversal">Path Traversal</a>. |
59 | 64 | <li>Rails: <a href="https://api.rubyonrails.org/classes/ActiveStorage/Filename.html#method-i-sanitized">ActiveStorage::Filename#sanitized</a>.</li>
|
| 65 | +</li> |
| 66 | + |
60 | 67 | </references>
|
61 | 68 | </qhelp>
|
0 commit comments