« first day (3524 days earlier)      last day (1348 days later) » 

3:45 AM
Hi everyone. I'm looking for some help. I want to implement an image upload feature to my site but I am aware there are many possible security issues with image uploads. I wondering if anyone can suggest an article that describes the proper way to securely handle file, specifically image, uploads. I've found some articles but they are all very general.
 
 
14 hours later…
5:59 PM
I don't have an article handy but here are the highlights for top-notch image security:

1. Verify the file *contents* and make sure it is the kind of image you are expecting (note: not the file extension - that's useless). Different platforms/languages have different way to verify that the file is actually an image *with the format* you want. If you are expecting JPG/PNG don't allow PDF/SVG. (and that is probably a good rule in general - PDFs and SVGs can be a bit more dangerous than the others).
I'd be happy to expand on any of those points if you want.
 
6:19 PM
@ConorMancone Thanks for those points. I have a couple questions regarding those.
First, I'd like to store them on my server instead of using a cloud bucket. Secondly, ideally I'd like to keep the metadata intact, is there a possible security issue with doing that? I understand that I should check the magic number to ensure it's a really the type that it claims to be. However, one can embed payloads into legitimate image formats. I've heard to mitigate that, one should resize the image (as those algorithms remove...
...extraneous and possibly malicious data), however, I'd like to keep the same resolution as uploaded. Also, you can't resize a PDF. So for the PDF file format, I'm unsure how to mitigate embedded payloads.
 
 
3 hours later…
9:02 PM
@JBis removal of the meta data is a (only partial) solution to bedded code. So is copying them to a cloud platform. Resizing the images generally won't help. If you want to keep it on server and also leave meta data in then you need to make sure it is not executable either as server side code or as JavaScript. The way to prevent it from executing server side depends on your server setup and language, so you'll have to look into that one yourself.
It is obviously more of a risk for dynamic languages (PHP) and less of a concern for compiled languages (Go). For instance If your server executed anything with a .php extension as PHP and you let the user upload files with a .php extension, you will have trouble.
For JavaScript you don't want a file that the browser will execute as JavaScript, because then an attacker can send a link to it and it will execute arbitrary JavaScript hosted (basically an XSS attack). The way to avoid that is by making sure the server always sends a proper content type for your images
 
9:33 PM
Often (but not always) the server decides what content type to send based on the extension, so a lot of this comes down to making sure to give a "safe" filename and ignoring the one from the user. That isn't always a 100% guarantee, but generally if your file has a .jpg extension and the server returns an image/jpg content type, it won't practically matter if there is JavaScript hiding in the header because the browser will never try to execute it as such
Hosting it in, for instance, an S3 bucket just simplifies that and provides good defense layers. There is little chance that a file in S3 will be executed, and if someone uploaded a file and tricked the browser into treating it as JavaScript/HTML, it won't matter because it is hosted on a completely different domain
 
@ConorMancone Yes, I'm aware that PHP makes it easy to make yourself vulnerable to this type of thing. I'm using Node.js so it shouldn't be as likely if an issue.
@ConorMancone makes sense
@ConorMancone I could possibly host it on a different subdomain
Thank you for all the information. I think I will host on a different domain to make sure.
 

« first day (3524 days earlier)      last day (1348 days later) »