Web Application Security Guide/File upload vulnerabilities
Web servers apply specific criteria (e.g. file extension) to decide how to process a file. If an application allows file uploads (e.g. for profile pictures, attached documents), ensure that the uploaded files cannot be interpreted as script files by the web server. Otherwise, the attacker may upload a script in your application’s programming language and run the arbitrary code contained therein by requesting the uploaded file.
To prevent this type of attack
- Avoid unnecessary file uploads
- Ensure that files uploaded by the user cannot be interpreted as script files by the web server, e.g. by checking the file extension (or whatever means your web server uses to identify script files)
- Ensure that files cannot be uploaded to unintended directories (directory traversal)
- Try to disable script execution in the upload directory
- Ensure that the file extension matches the actual type of the file content
- If only images are to be uploaded, consider re-compressing them using a secure library to ensure they are valid
- Ensure that uploaded files are specified with the correct Content-type when delivered to the user
- Prevent users from uploading special files (e.g. .htacces, web.config, robots.txt, crossdomain.xml, clientaccesspolicy.xml)
- Prevent users from overwriting application files
- Consider delivering uploaded files with the “Content-disposition: attachment” header
File upload facilities are hard to protect correctly. If they are provided to support “gimmick” functions, they may not be worth the risk.
It is crucial that the web server will not attempt to interpret the uploaded files as scripts, as this could result in arbitrary code execution. Make sure to use the same method as your web server for deciding whether a file will be interpreted as a script or not.
Directory traversal attacks could allow an attacker to overwrite application or server files. Preventing these is also necessary to ensure that disabling script execution for the upload directory is actually effective.
Disabling script execution ensures that if attackers manage to upload a script file, it will still not be executed. However, this should not be relied upon: If the application gets transferred to a different server, the setting could get lost.
Mismatched file names/extensions can be used to upload forbidden data types (e.g. HTML, XML, SVG - see below). Even if the server sets the Content-type according to the extensions, some browsers may ignore this, analyze the file contents (MIME sniffing) and parse the file as HTML.
Re-compressing images ensures that any malicious content is destroyed. However, the image processing library needs to be secure, as it is exposed to user content and could be attacked using e.g. buffer overflow exploits.
Specifying the correct Content-type when delivering the files ensures that the file will be handled correctly by most browsers. This is required for correct functionality, but also relevant for security as incorrect handling of the file could lead to MIME sniffing, resulting in security issues.
Special files like .htacces, web.config, robots.txt, crossdomain.xml and clientaccesspolicy.xml could allow attackers to change security settings (.htaccess, web.config), cause load (robots.txt) or allow cross-site scripting/cross-site request forgery attacks using plugins (crossdomain.xml and clientaccesspolicy.xml). Note that crossdomain.xml files are also valid if they appear in subdirectories.
Allowing the user to overwrite files belonging to the application can not only damage the application, but also allow other attacks, e.g. make code execution possible or enable the attacker to change critical settings.
The Content-disposition: attachment header forces browsers to save the file instead of immediately opening it, thus reducing the risk for some of the attacks. Note that this can significantly annoy the users and is not possible in all situations.
The following resources provide additional information on this topic:
- Guide about MIME sniffing: http://h-online.com/-746229
- MediaWiki resources about upload protection: