The pitfalls of allowing file uploads on your website

Post by bsder » Wed, May 21, 2014, 12:11 AM UTC

teraflop wrote: post #4

rpedela wrote: post #3

Earlier quoted context omitted.

How does simply using a different domain protect against malware?

As the article explains, the problem is that SWF files hosted on one domain can execute in the security context of that domain, even when embedded in a page on a completely different site. So allowing attacker-controlled uploads makes any credentials on that domain, such as session cookies and CSRF tokens, vulnerable. If the SWF is hosted on a domain with no sensitive credentials, this particular problem goes away.

Post by rhizome » Wed, May 21, 2014, 1:05 AM UTC

staunch wrote: post #13

> 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…

Post by rurounijones » Wed, May 21, 2014, 1:22 AM UTC

teach wrote: post #16

jacquesm wrote: post #9

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.

Post by teraflop » Wed, May 21, 2014, 3:58 AM UTC

bsder wrote: post #21

teraflop wrote: post #4

Earlier quoted context omitted.

As the article explains, the problem is that SWF files hosted on one domain can execute in the security context of that domain, even when embedded in a page on a completely different site. So allowing attacker-controlled uploads makes any credentials on that domain, such as session cookies and CSRF tokens, vulnerable. If the SWF is hosted on a domain with no sensitive credentials, this particular problem goes away.

I don't understand. How does serving a flash applet from my domain get you access to anything other than that applet? I'm not arguing that this attack doesn't exist. I just don't understand what the attacker gets access to.

Post by tom_jones » Wed, May 21, 2014, 5:26 AM UTC