Insecure File Management
Why is this important?
Any functionality related to file management requires careful usage. If attackers are able to influence the input to file access related APIs, then it can have a serious impact. For example, attackers could read the all files on your application server.
In other cases, this can allow attackers to include their own code, or files, that are then executed by the application at runtime.
Check out this video for a high-level explanation on local file inclusion issues:
Another high-level explanation on remote file inclusion issues:
Fixing Insecure File Management
Option A: Avoid Usage of mktemp()
According to the libc manpage for mktemp - "Never use this function". Since on the one hand the names are easy to guess, and on the other hand there is a race between testing whether the name exists and opening the file, every use of mktemp() is a security risk.
- Go through the issues that GuardRails identified in the PR.
- Identify the use of
mktemp() - Replace it with either mkstemp or mkdtemp.
- Ship it 🚢 and relax 🌴
Option B: Use functions that process filename arguments securely
The following functions are processing filename arguments, which can lead to serious flaws if exploited by attackers.
Follow the steps below:
- Go through the issues that GuardRails identified in the PR.
- Identify the use of the above listed functions
- Wherever they use path names that can be influenced by user input, rely on hard-coded expected values instead, or ensure that the content is sanitized.
- Test it, ship it 🚢 and relax 🌴