You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: csharp/ql/src/Security Features/CWE-022/TaintedPath.md
+67-15Lines changed: 67 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,23 @@
1
1
# Uncontrolled data used in path expression
2
2
Accessing paths controlled by users can allow an attacker to access unexpected resources. This can result in sensitive information being revealed or deleted, or an attacker being able to influence behavior by modifying unexpected files.
3
3
4
-
Paths that are naively constructed from data controlled by a user may contain unexpected special characters, such as "..". Such a path may potentially point to any directory on the file system.
4
+
Paths that are naively constructed from data controlled by a user may be absolute paths, or may contain unexpected special characters such as "..". Such a path could point anywhere on the file system.
5
5
6
6
7
7
## Recommendation
8
-
Validate user input before using it to construct a file path. Ideally, follow these rules:
8
+
Validate user input before using it to construct a file path.
9
+
10
+
Common validation methods include checking that the normalized path is relative and does not contain any ".." components, or checking that the path is contained within a safe folder. The method you should use depends on how the path is used in the application, and whether the path should be a single path component.
11
+
12
+
If the path should be a single path component (such as a file name), you can check for the existence of any path separators ("/" or "\\"), or ".." sequences in the input, and reject the input if any are found.
13
+
14
+
Note that removing "../" sequences is *not* sufficient, since the input could still contain a path separator followed by "..". For example, the input ".../...//" would still result in the string "../" if only "../" sequences are removed.
15
+
16
+
Finally, the simplest (but most restrictive) option is to use an allow list of safe patterns and make sure that the user input matches one of these patterns.
9
17
10
-
* Do not allow more than a single "." character.
11
-
* Do not allow directory separators such as "/" or "\\" (depending on the file system).
12
-
* Do not rely on simply replacing problematic sequences such as "../". For example, after applying this filter to ".../...//" the resulting string would still be "../".
13
-
* Use a whitelist of known good patterns.
14
-
* Sanitize potentially tainted paths using `HttpRequest.MapPath`.
15
18
16
19
## Example
17
-
In the first example, a file name is read from a `HttpRequest`and then used to access a file. However, a malicious user could enter a file name which is an absolute path - for example, "/etc/passwd". In the second example, it appears that the user is restricted to opening a file within the "user" home directory. However, a malicious user could enter a filename which contains special characters. For example, the string "../../etc/passwd" will result in the code reading the file located at "/home/\[user\]/../../etc/passwd", which is the system's password file. This file would then be sent back to the user, giving them access to all the system's passwords.
20
+
In this example, a user-provided file name is read from a HTTP request and then used to access a file and send it back to the user. However, a malicious user could enter a file name anywhere on the file system, such as "/etc/passwd" or "../../../etc/passwd".
18
21
19
22
20
23
```csharp
@@ -26,16 +29,65 @@ public class TaintedPathHandler : IHttpHandler
26
29
{
27
30
publicvoidProcessRequest(HttpContextctx)
28
31
{
29
-
Stringpath=ctx.Request.QueryString["path"];
32
+
Stringfilename=ctx.Request.QueryString["path"];
30
33
// BAD: This could read any file on the filesystem.
31
-
ctx.Response.Write(File.ReadAllText(path));
34
+
ctx.Response.Write(File.ReadAllText(filename));
35
+
}
36
+
}
37
+
38
+
```
39
+
If the input should only be a file name, you can check that it doesn't contain any path separators or ".." sequences.
40
+
32
41
33
-
// BAD: This could still read any file on the filesystem.
0 commit comments