@@ -8,32 +8,44 @@ can result in sensitive information being revealed or deleted, or an attacker be
8
8
behavior by modifying unexpected files.</p >
9
9
10
10
<p >Paths that are naively constructed from data controlled by a user may contain unexpected special characters,
11
- such as "..". Such a path may potentially point to any directory on the file system.</p >
11
+ such as "..". Such a path may potentially point anywhere on the file system.</p >
12
12
13
13
</overview >
14
14
<recommendation >
15
15
16
- <p >Validate user input before using it to construct a file path. Ideally, follow these rules: </p >
16
+ <p >Validate user input before using it to construct a file path.</p >
17
17
18
- <ul >
19
- <li >Do not allow more than a single "." character.</li >
20
- <li >Do not allow directory separators such as "/" or "\" (depending on the file system).</li >
21
- <li >Do not rely on simply replacing problematic sequences such as "../". For example, after applying this filter to
22
- ".../...//" the resulting string would still be "../".</li >
23
- <li >Ideally use a whitelist of known good patterns.</li >
24
- </ul >
18
+ <p >The choice of validation depends on whether you want to allow the user to specify complex paths with
19
+ multiple components that may span multiple folders, or only simple filenames without a path component.</p >
20
+
21
+ <p >In the former case, a common strategy is to make sure that the constructed file path is contained within
22
+ a safe root folder, for example by checking that the path starts with the root folder. Additionally,
23
+ you need to ensure that the path does not contain any ".." components, since otherwise
24
+ even a path that starts with the root folder could be used to access files outside the root folder.</p >
25
+
26
+ <p >In the latter case, if you want to ensure that the user input is interpreted as a simple filename without
27
+ a path component, you can remove all path separators ("/" or "\") and all ".." sequences from the input
28
+ before using it to construct a file path. Note that it is <i >not</i > sufficient to only remove "../" sequences:
29
+ for example, applying this filter to ".../...//" would still result in the string "../".</p >
30
+
31
+ <p >Finally, the simplest (but most restrictive) option is to use an allow list of safe patterns and make sure that
32
+ the user input matches one of these patterns.</p >
25
33
26
34
</recommendation >
27
35
<example >
28
36
29
- <p >In this example, a file name is read from a <code >java.net.Socket</code > and then used to access a file in the
30
- user's home directory and send it back over the socket. However, a malicious user could enter a file name which contains special
31
- characters. For example, the string "../../etc/passwd" will result in the code reading the file located at
32
- "/home/[user]/../../etc/passwd", which is the system's password file. This file would then be sent back to the user,
33
- giving them access to all the system's passwords.</p >
37
+ <p >In this example, a file name is read from a <code >java.net.Socket</code > and then used to access a file
38
+ and send it back over the socket. However, a malicious user could enter a file name anywhere on the file system,
39
+ such as "/etc/passwd".</p >
34
40
35
41
<sample src =" TaintedPath.java" />
36
42
43
+ <p >Simply checking that the path is under a trusted location (such as a known public folder) is not enough,
44
+ however, since the path could contain relative components such as "..". To fix this, check that it does
45
+ not contain ".." and starts with the public folder.</p >
46
+
47
+ <sample src =" TaintedPathGood.java" />
48
+
37
49
</example >
38
50
<references >
39
51
0 commit comments