Type: Security Hotspot Detection
Message:Make sure this file handling is safe here.
Irrelevant for Languages:CSS, HTML, XML
Analysis Scope:Main Sources
Handling files is security-sensitive. It has led in the past to the following vulnerabilities:
Any access to the file system can create a vulnerability. Exposing a file's content, path or even its existence or absence is dangerous. It is also extremely risky to create or write files without making sure that their permission and content is safe and controlled. Using a file path or reading a file content must be always done with caution as they could have been tampered with.
The file system is a resource which can be easily exhausted. Opening too many files will use up all file descriptors, preventing other software from opening files. Filling the storage space will also prevent any additional write from happening.
This rule flags code that initiates the use of files. The goal is to guide manual security code reviews.
- the file or directory path you are using is coming from a user input or could have been tampered with.
- the code exposes to an unauthorized person the existence of a file or directory. Any hint given to a user might be dangerous. The information could be given by displaying an error if the file/directory does not exist or just by returning an "Unauthorized" error when the file/directory exists but the person can't perform an action.
- the code exposes to an unauthorized person the paths of files and/or directories, for example by listing the content of a directory and displaying the output.
- a file or directory may be created with the wrong permissions.
- an unvalidated user input is written into a file.
- a file is read and its content is used without being validated.
- a file is read and its content is exposed to an unauthorized person.
- a file is open, created or written into each time a user performs an action.
- files are open and not closed before executing a child process. This is only dangerous if file descriptors are inherited in your programming language (example: C, C++).
You are at risk if you answered yes to any of those questions.
Avoid using paths provided by users or other untrusted sources if possible. If this is required, check that the path does not reference an unauthorized directory or file. See OWASP recommendations as to how to test for directory traversal. Note that the paths length should be validated too.
No File and directory names should be exposed. They can contain sensitive information. This means that a user should not be able to list the content of unauthorized directories.
Make sure that no attackers can test for the existence or absence of sensitive files. Knowing that a specific file exists can reveal a vulnerability or at least expose file and directory names.
Files and directories should be created with restricted permissions and ownership. Only authorized users and applications should be able to access the files, and they should have as little permissions as needed. Modifying a file's permissions is not good enough. The permissions should be restricted from the very beginning.
Writing user input into files should be done with caution. It could fill the storage space if the amount of data written is not controlled. It could also write dangerous data which will later be used by an application or returned to another user. This is why the user input should be validated before being written.
Reading a file can lead to other vulnerabilities. Any file could have been modified by an attacker. Thus the same validation as for any user input should be performed on file content.
Once a file is read, its content should only be exposed to authorized users.
Add limits to the number of files your application access simultaneously or create because of a user action. It is possible to perform a Denial of Service attack by opening too many files, and thus exhausting available file descriptors, or by filling the file system with new files. Release file descriptors by closing files as soon as possible.
We also recommended to have tools monitoring your system and alerting you whenever resources are nearly exhausted.
- OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
- MITRE, CWE-732 - Incorrect Permission Assignment for Critical Resource
- MITRE, CWE-73 - External Control of File Name or Path
- MITRE, CWE-20 - Improper Input Validation
- MITRE, CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
- MITRE, CWE-400 - Uncontrolled Resource Consumption ('Resource Exhaustion')
- MITRE, CWE-538 - File and Directory Information Exposure
- MITRE, CWE-403 - Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
- CERT, FIO01-J. - Create files with appropriate access permissions
- CERT, FIO06-C. - Create files with appropriate access permissions
- CERT, FIO22-C. Close files before spawning processes
- SANS Top 25 - Risky Resource Management
- SANS Top 25 - Porous Defenses