View source for LII:Web Application Security Guide/File upload vulnerabilities

==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.

Additionally, an attacker could upload custom HTML or JavaScript files and direct a victim to them. Since they come from a directory inside your application, this can be used to subvert the same-origin policy protection by the victim’s browser, for example to steal cookies. Some broken browsers (notably Internet Explorer) ignore the MIME type of files in some cases and detect the file type based on the file content.

===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 problematic file types like HTML, CSS, JavaScript, XML, SVG and executables using a whitelist of allowed file types
* Prevent users from uploading special files (e.g. .htaccess, web.config, robots.txt, crossdomain.xml, clientaccesspolicy.xml)
* Prevent users from overwriting application files
* Consider delivering uploaded files with the “Content-disposition: attachment” header

===Rationale===
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.

User-uploaded HTML, CSS, JavaScript and similar files can contain scripts that run in the origin of the web site and thus are allowed to access cookies or web site content. XML and SVG files are often overlooked, but can also execute scripts. This can lead to various attacks like session stealing, CSRF etc.  Executables can be dangerous to the user and should therefore be blocked. A whitelist should be used as creating a reliable and complete list of dangerous extensions is not possible. ZIP files can be dangerous for outdated browsers (notably Firefox 2.x). Note that various files are technically also ZIP files, notably documents from OpenOffice (e.g. odt, ods) and Microsoft Office 2007 and newer (e.g. docx, xlsx).

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:
** [[mediawikiwiki:Manual:$wgMimeTypeBlacklist|Manual:$wgMimeTypeBlacklist]]
** [[mediawikiwiki:Manual:$wgFileBlacklist|Manual:$wgFileBlacklist]]
** [[mediawikiwiki:Manual:Mime type detection|Manual:Mime type detection]]

==Notes==
The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/File_upload_vulnerabilities the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license.