File upload - pallavitewari21/Secure-Code GitHub Wiki

Risks

Sophisticated hackers typically exploit a combination of vulnerabilities when attacking your site – uploading malicious code to a server is step one in the hacker playbook. The next step is finding a way to execute the malicious code.

Even big companies fall foul to this vulnerability, particularly if they are running complex, legacy code bases.

Prevention

Segregate Your Uploads

File uploads are generally intended to be inert. Unless you are building a very particular type of website, you are typically expecting images, videos, or document files, rather than executable code. If this is the case, making sure uploaded files are kept separate from application code is a key security consideration.

Consider using cloud-based storage or a content management system to store uploaded files. Alternatively, if you are sure of your ability to scale your backend, you could write uploaded files to your database. Both of these approaches prevent the accidental execution of an executable file.

Even storing uploaded files on a remote file server or in a separate disk partition helps, by isolating the potential damage a malicious file can do.

Ensure Upload Files Cannot Be Executed

However, you end up storing your uploaded files, if they are written to disk, ensure they are written in such a way that the operating system knows not to treat them as executable code. Your webserver process should have read and write permissions on the directories used to store uploaded content, but should not be able to execute any files there. If you are using a Unix-based operating system, make sure uploaded files are written without the “executable” flag in the file permissions.

Rename Files on Upload

Rewriting or obfuscating file names will make it harder for an attacker to locate a malicious file once they have uploaded it. Uploaded files are generally made available back over HTTP – what’s the point of uploading an image if it isn’t available anywhere on your site, for instance? Implement a method of indirection when serving the uploaded content back in the browser, so the content is not referenced by its name from the original upload.

Validate File Formats and Extensions

Make sure you check the file extension of uploaded files against a white-list of permitted file types. Do this on the server-side, since client-side checks can be circumvented.

Validate the Content-Type Header

Files uploaded from a browser will be accompanied by a Content-Type header. Make sure the supplied type belongs to a white-listed list of permitted file types. (Be aware that simple scripts or proxies can spoof the file type, though, so this protection, while useful, is not enough to dissuade a sophisticated attacker.)

Use a Virus Scanner

Virus scanners are very adept at spotting malicious files masquerading as a different file type, so if you are accepting file uploads, running up-to-date virus scanning is strongly recommended.

other considerations

Check File Sizes A cheap and easy way to perform a denial-of-service attack is to upload a very large file, in the hope that the server runs out of space. Make sure you put a maximum size on the size of the files you accept.

Sanitize Filenames

Overlong filenames could be abused to exploit buffer overflow vulnerabilities. Similarly, files with special characters in the name can cause weird behavior, depending on how they are treated by your software. It is good practice to ensure file names are sanitized before being written to disk.

Be Careful with Compressed Files

If your site accepts compressed content, such as zip files, be aware that it is possible to create malicious archive files designed to crash or render useless the program or system reading them. A zip bomb is crafted so that unpacking it will take up a large amount of time, disk space, or memory – typically, the zip will expand to be huge on disk when unpacked. Don’t deal with compressed content unless you absolutely have to, and make sure to run an anti-virus scanner if you do!"