Allowing file uploads by end users, especially if done without full understanding of risks associated with it, is akin to opening the floodgates for system compromise. If you are designing a new application that accepts file uploads or you already have one please keep reading. Below you will find a list of security requirements that will help you to control the file upload risks in your application.

Here are the top threats to watch out for:

• File metadata – The user controlled input like path or a file name can trick an application into copying the file to an unexpected location e.g. control characters in the filename could trick the system to overwrite an important configuration file and cause unexpected behaviour. User controlled metadata like Exif when parsed incorrectly could lead to a buffer overflow and remote code execution. E.g. https://hackerone.com/reports/371135

• File size – An unexpectedly large or zero size file can cause an application to overload or fail e.g. botnet could trigger concurrent uploads of a very large file resulting in DDoS.

• File content – The content of the file can be use to manipulate the behaviour of the application and allow remote code execution. This depends on how the file is processed server-side. See https://imagetragick.com/

• File access – The access rules around uploaded files can be misconfigured, resulting in unauthorised. For example, a misconfigured AWS S3 configuration could result in uploaded files being accessible to the public.

  MoSCoW : Must, Should, Could, Won’t

General Requirements

Ref	Requirement	MoSCoW
SFU01	All operations on files obtained from untrusted source must must be carried out in a sandbox. This is to ensure that in the unlikely event of a compromise, malicious actions are limited to the isolated environment, protecting the rest of the system from harm.	M
SFU02	Maintain a strict whitelist of allowed file extensions. Avoid file types that allow of embedding custom objects e.g. PDF, DOC, SVG.	M
SFU03	Run MIME checks to ensure that the file type matches the Content-Type supplied (check file’s magic number or a special magic pattern). Reject all files that do not match the approved types/extensions.	M
SFU04	The user supplied file name must not be used. Rename according to a predetermined convention.	M
SFU05	Make it impossible to overwrite an existing file.	M
SFU06	Ensure that the maximum file name length and the file name size is defined. Never rely on the Content-Length provided, always check the actual size.	M
SFU07	Maintain strong logical segmentation between the component responsible for uploading files and the component responsible for reading the files e.g. create two different apps.	S
SFU08	Log all upload activity. Ensure that both successful and failed attempts are logged.	M
SFU09	Limit the upload functionality to authenticated and authorised users if possible.	C
SFU10	Remove any unnecessary file metadata that may contain personal information before storing. E.g. Exif may contain geolocation, custom tags and other sensitive data.	S

Malware Protections

Ref	Requirement	MoSCoW
SFU11	Files obtained from untrusted sources must be scanned by one or more anti malware scanners to prevent upload of known malicious content.	M
SFU12	Ensure that all incoming images are sanitised using re-writing or content disarm and reconstruction (CDR) especially if file type allows custom object embedding.	S
SFU13	Antivirus and CDR must run in a sandbox.	M

Denial of Service

Ref	Requirement	MoSCoW
SFU14	Implement application specific rate limiting e.g. allow only N-number of concurrent uploads from a single IP.	M
SFU15	Enforce reasonable limits to defend against resource exhaustion e.g. maximum number of files stored per user (space exhaustion), maximum time allowed for the file to be process (CPU exhaustion).	M
SFU16	Detect and prevent automated systems from uploading content. Use captcha or other bot management solution.	S

Storage and Privacy

Ref	Requirement	MoSCoW
SFU17	All files must be encrypted at rest and in transit using strong encryption.	M
SFU18	A random encryption key must be generated per file and wrapped using a master Key Encryption Key (KEK).	M
SFU19	KEK must be securely stored in tamper-resistant hardware security models (HSM).	M
SFU20	Key management including key revocation and mandatory periodic key rotation must be implemented.	M
SFU21	When applicable apply the principle of least privilege such that the file upload component can only write files and doesn’t have read access to the underlying storage.	S
SFU22	Data retention should be implemented. Files older than N-months should be automatically removed.	S
SFU23	The service should be designed to allow seamless processing of ‘right of access’ and ‘right to be forgotten’ requests.	S