1051
Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected
type and size. It may be possible for an attacker to hide code in some file segments that will still
be executed by the server. For example, GIF images may contain a free-form comments field.
Phase: Implementation
Do not rely exclusively on the MIME content type or filename attribute when determining how to
render a file. Validating the MIME content type and ensuring that it matches the extension is only
a partial solution.
Phase: Architecture and Design
Phase: Operation
Strategy = Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks
[REF-76]. If possible, create isolated accounts with limited privileges that are only used for a
single task. That way, a successful attack will not immediately give the attacker access to the
rest of the software or its environment. For example, database applications rarely need to run as
the database administrator, especially in day-to-day operations.
Phase: Architecture and Design
Phase: Operation
Strategy = Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between
the process and the operating system. This may effectively restrict which files can be accessed
in a particular directory or which commands can be executed by the software. OS-level examples
include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide
some protection. For example, java.io.FilePermission in the Java SecurityManager allows the
software to specify restrictions on file operations. This may not be a feasible solution, and it
only limits the impact to the operating system; the rest of the application may still be subject to
compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness = Limited
The effectiveness of this mitigation depends on the prevention capabilities of the specific
sandbox or jail being used and might only help to reduce the scope of an attack, such as
restricting the attacker to certain system calls or limiting the portion of the file system that can be
accessed.
Demonstrative Examples
Example 1:
The following code intends to allow a user to upload a picture to the web server. The HTML code
that drives the form on the user end has an input field of type "file".
Example Language: HTML (Good)
<form action="upload_picture.php" method="post" enctype="multipart/form-data">
Choose a file to upload:
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>
</form>
Once submitted, the form above sends the file to upload_picture.php on the web server. PHP
stores the file in a temporary location until it is retrieved (or discarded) by the server side code. In
this example, the file is moved to a more permanent pictures/ directory.
Example Language: PHP (Bad)
CWE Version 4.14
CWE-434: Unrestricted Upload of File with Dangerous Type
CWE-434: Unrestricted Upload of File with Dangerous Type