diff --git a/go/ql/src/Security/CWE-022/TaintedPath.qhelp b/go/ql/src/Security/CWE-022/TaintedPath.qhelp index 061ffbe34712..94edec4e4f4b 100644 --- a/go/ql/src/Security/CWE-022/TaintedPath.qhelp +++ b/go/ql/src/Security/CWE-022/TaintedPath.qhelp @@ -9,23 +9,35 @@ Accessing files using paths constructed from user-controlled data can allow an a unexpected resources. This can result in sensitive information being revealed or deleted, or an attacker being able to influence behavior by modifying unexpected files.
++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. +
-Validate user input before using it to construct a file path, either using an off-the-shelf library -or by performing custom validation. +Validate user input before using it to construct a file path. +
++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. +
++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. +
++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.
-Ideally, follow these rules: +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.
-+If the input should only be a file name, you can check that it doesn't contain any +path separators or ".." sequences. +
++Note that this approach is only suitable if the input is expected to be a single file name. +
++If the input can be a path with multiple components, you can make it safe by verifying +that the path is within a specific directory that is considered safe. +You can do this by resolving the input with respect to that directory, and then checking +that the resulting path is still within it. +
+
+Note that /home/user
is just an example, you should replace it with the actual
+safe directory in your application. Also, while in this example the path of the safe
+directory is absolute, this may not always be the case, and you may need to resolve it
+first before checking the input.
+