@@ -8,22 +8,28 @@ 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
16
<p >Validate user input before using it to construct a file path.</p >
17
17
18
- <p >The choice of validation depends on the use case.</p >
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 >
19
20
20
- <p >If you want to allow paths spanning multiple folders , a common strategy is to make sure that the constructed
21
- file path is contained within a safe root folder, for example by checking that the path starts with the root folder.
22
- Additionally, you need to ensure that the path does not contain any ".." components, since these would allow
23
- the path to escape the root folder.</p >
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 >
24
25
25
- <p >A safer (but more restrictive) option is to use an allow list of safe paths and make sure that
26
- the user input is one of those paths.</p >
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 >
27
33
28
34
</recommendation >
29
35
<example >
@@ -34,12 +40,9 @@ such as "/etc/passwd".</p>
34
40
35
41
<sample src =" TaintedPath.java" />
36
42
37
- <p >Simply checking that the path is under a trusted location (such as the user's home directory) is not enough,
38
- however, since the path could contain relative components such as "..". For example, the string
39
- "/home/[user]/../../etc/passwd" starts with the user's home directory, but would still result in the code reading
40
- the file located at "/etc/passwd".</p >
41
-
42
- <p >To fix this, we check that the user-provided path does not contain ".." and starts with the user's home directory.</p >
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, we check that the it does
45
+ not contain ".." and starts with the public folder.</p >
43
46
44
47
<sample src =" TaintedPathGood.java" />
45
48
0 commit comments