@@ -8,32 +8,44 @@ can result in sensitive information being revealed or deleted, or an attacker be
88behavior by modifying unexpected files.</p >
99
1010<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 >
1212
1313</overview >
1414<recommendation >
1515
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 >
1717
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 >
2533
2634</recommendation >
2735<example >
2836
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 >
3440
3541<sample src =" TaintedPath.java" />
3642
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+
3749</example >
3850<references >
3951
0 commit comments