11–20 of 32 posts
Should clarify: "The pitfalls of hosting user-uploaded files on your website" Hosting user-uploaded files on a separate domain would probably solve this problem.
Indeed. Nothing about this applies to sites that accept uploads for internal use (e.g. parsed as input data).
The idea that you can "verify the contents" is pretty much just wrong. You actually have to parse the files and write out your own known-safe version. It's a real pain in the butt to do that correctly and securely across a wide variety of file types.
Even parsing arbitrary user uploads with something like ImageMagick is probably exploitable, simply because those libraries weren't designed to handle hostile input.
Hold-on, doesn't using a Content-Disposition: attachment; filename=”image.jpg” header mean you can no longer display the image in your service? Won't browsers treat it as a file download? Most services that allow image uploads do so because the images will get displayed on a page? (that's what I do) Most services seem to be moving file uploads to S3 (or similar services) these days, so I'm not sure this advice is rea…
Some also restricts so that different filetypes on S3 will be served as Inline content, but that will just save you from XSS, and not the CSRF leakage. It's still suprisingly common with a crossdomain.xml restricted to [wildcard].domain.com.
By uploading straight to S3 you also get a faster upload (than, say, Heroku) and server separation.
The bottom line is this, if users can upload something to your site, and then your site will show that thing to other users before you have a chance to figure out if its a problem, then your site will be exploited by bad actors. For a long time an out of the box server installation would include anonymous ftp access. Of course nothing is quite so attractive as a 'free' place to dump and retrieve stuff. It was kind of…
Even if it does not show anything to other users, just having the wrong extension can already bite you badly. Uploading php files instead of images has been used to gain access to machines. Anything that gets stored as a file on the filesystem of the destination machine is a huge risk. All it takes is one little misconfiguration somewhere else and you're wide open.
I have a site that allows uploads (students turning in Java files) but the files are just stored in a folder on the server that isn't in the web-served path. They can't see the file again once uploaded. I assume (and I think rightly) that there's no security risk in my case.
The bottom line is this, if users can upload something to your site, and then your site will show that thing to other users before you have a chance to figure out if its a problem, then your site will be exploited by bad actors. For a long time an out of the box server installation would include anonymous ftp access. Of course nothing is quite so attractive as a 'free' place to dump and retrieve stuff. It was kind of…
Even if it does not show anything to other users, just having the wrong extension can already bite you badly. Uploading php files instead of images has been used to gain access to machines. Anything that gets stored as a file on the filesystem of the destination machine is a huge risk. All it takes is one little misconfiguration somewhere else and you're wide open.
So if someone uploads a file called `image.php.jpg`, the file is executed by Apache as PHP code. And obviously verifying the MIME type or even the content of the file won't help you here, since you can just write a JPEG header and then throw in `` after it.
Even when you think you're safe based on what you'd consider to be obvious assumptions ("the file extension is whatever comes up after the last period"), there are weird things like this that might bite you.
Earlier quoted context omitted.
Even if it does not show anything to other users, just having the wrong extension can already bite you badly. Uploading php files instead of images has been used to gain access to machines. Anything that gets stored as a file on the filesystem of the destination machine is a huge risk. All it takes is one little misconfiguration somewhere else and you're wide open.
This is only if you subsequently give them a link to what they uploaded, correct? I have a site that allows uploads (students turning in Java files) but the files are just stored in a folder on the server that isn't in the web-served path. They can't see the file again once uploaded. I assume (and I think rightly) that there's no security risk in my case.
Just make sure it is a hardcoded path, and not one that users can manipulate in any way (a filename of "../../../../file.java" for example). And if there is some other interface that reads files from that directory and outputs them to a page, that will also need to be secured against XSS.
Should clarify: "The pitfalls of hosting user-uploaded files on your website" Hosting user-uploaded files on a separate domain would probably solve this problem.
How does simply using a different domain protect against malware?
The blog post in the OP solely discusses XSS vulnerabilities that are introduced by unrestricted file uploads. There are numerous other issues that can occur from arbitrary file uploads (malware hosting, arbitrary code execution if it's PHP, phishing), but to prevent against a user content ever reaching sensitive data via XSS, placing all user data on a separate domain is pretty much your best bet.
> So if you allow file uploads or printing arbitrary user data in your service, you should always verify the contents as well as sending a Content-Disposition header where applicable. The idea that you can "verify the contents" is pretty much just wrong. You actually have to parse the files and write out your own known-safe version. It's a real pain in the butt to do that correctly and securely across a wide variety…
If a PHP page is allowing file uploads and only verifies the content of the data, but nothing else, then no protection is offered against arbitrary code execution. It's easy to craft a JPEG header and then place `` right after it; you could even append it to a valid JPEG body, too.