@@ -13,21 +13,26 @@ attacker being able to influence behavior by modifying unexpected files.
1313
1414<recommendation >
1515<p >
16- Validate user input before using it to construct a file path, either using an off-the-shelf library function
17- like <code >werkzeug.utils.secure_filename</code >, or by performing custom validation.
16+ Validate paths constructed from untrusted user input before using them to access files.
1817</p >
1918
2019<p >
21- Ideally, follow these rules:
20+ The choice of validation depends on the use case.
2221</p >
2322
24- <ul >
25- <li >Do not allow more than a single "." character.</li >
26- <li >Do not allow directory separators such as "/" or "\" (depending on the file system).</li >
27- <li >Do not rely on simply replacing problematic sequences such as "../". For example, after
28- applying this filter to ".../...//", the resulting string would still be "../".</li >
29- <li >Use an allowlist of known good patterns.</li >
30- </ul >
23+ <p >
24+ If you want to allow paths spanning multiple folders, a common strategy is to make sure that the constructed
25+ file path is contained within a safe root folder. First, normalize the path using <code >os.path.normpath</code > or
26+ <code >os.path.realpath</code > to remove any ".." segments. Then check that the normalized path starts with the
27+ root folder. Note that the normalization step is important, since otherwise even a path that starts with the root
28+ folder could be used to access files outside the root folder.
29+ </p >
30+
31+ <p >
32+ More restrictive options include using a library function like <code >werkzeug.utils.secure_filename</code > to eliminate
33+ any special characters from the file path, or restricting the path to an allow list of safe paths. These options are
34+ safe, but can only be used in particular circumstances.
35+ </p >
3136</recommendation >
3237
3338<example >
0 commit comments