
The pitfalls of allowing file uploads on your website - BogdanCalin
http://blog.detectify.com/post/86298380233/the-pitfalls-of-allowing-file-uploads-on-your-website
======
ChuckMcM
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 like setting up a warez/malware camera
trap.

~~~
jacquesm
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.

~~~
teach
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.

~~~
rurounijones
As long as you read the files before you execute them.

Otherwise some bad actor could write a virus / local exploit into their
submission which will execute when you compile and run the file.

~~~
teach
I _never_ execute them. I just grade them by reading the code. Running them
takes FAR longer than reading.

~~~
rurounijones
Are these exceedingly simple programs 10 line programs? Otherwise:

How do you know they compile?

How do you know they work?

How do you know they handle all the edge cases you can throw at them.

If you have a 100% accurate parser and compiler in your head, I am impressed.

Our teachers (and this was 15 years ago) had test-runners which would compile
and run our programs to make sure they met the requirements of the homework
THEN they looked at the code and marked it for style etc.

Sometimes they provided these test runners to us so we could check them
ourselves, sometimes they didn't (this was, naturally, harder).

~~~
goblin89
Obviously such workflow, while being fairer, requires a reliable sandbox of
some kind—even though one might argue that in a university such things may be
of less importance and that allowing for some degree of hacking is educational
and perhaps should even be tacitly encouraged, still you'd want to make sure
that when students break your system they can't go Bobby Tables on it or dump
everyone's private data on black market.

------
tantalor
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.

~~~
rpedela
How does simply using a different domain protect against malware?

~~~
teraflop
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.

~~~
sp332
Reminds me of this Google Docs phishing scam, that uses a Google domain to
look legit [http://www.symantec.com/connect/blogs/google-docs-users-
targ...](http://www.symantec.com/connect/blogs/google-docs-users-targeted-
sophisticated-phishing-scam)

~~~
tantalor
Google Drive does let you host arbitrary content, but from googledrive.com,
not from google.com.

[https://support.google.com/drive/answer/2881970](https://support.google.com/drive/answer/2881970)

This is basically the same as github.io.

The Symantec article is interesting but only says the fake page is hosted on
"Google's servers", not "google.com", but users might believe
"googledrive.com" is trustworthy.

------
callmeed
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 really helpful. To take that a step
further, my preference now is to upload _directly_ to S3 and bypass my app
server altogether. At least in Rails, it's fairly easy to setup.

~~~
fransr
Problem is that many tend to use S3 but bind a subdomain to it. S3 does not
validate the content of those files, so combined with a [wildcard].domain.com
crossdomain.xml and you're still as vulnerable as per above.

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.

------
tehwebguy
A nice way to achieve this with Rails is to upload straight to S3 and then use
Paperclip to get, verify and process the file.

By uploading straight to S3 you also get a faster upload (than, say, Heroku)
and server separation.

------
staunch
> _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 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.

~~~
rhizome
Isn't it a reasonable workaround to scan the file for content-type and make
the file available once it passes the criteria for the upload? Find a php file
uploaded with an extension of .jpg? "Sorry, there was a problem with your
file. Please try again."

~~~
ubernostrum
And then you run into polyglot files which are valid for multiple types...

------
rebel
So out of curiosity, what would be the easiest way to _securely_ accept file
uploads? Taking into account all of the possible malicious attacks.

~~~
BogdanCalin
Host them on a separate domain like Google and Github does (eg. Google uses
googleusercontent.com and Github uses githubusercontent.com).

------
elchief
I'm pretty sure you can use Apache Tika to check the actual content type of a
file too. Either way, I hate flash.

------
tom_jones
Nice post, just goes to show the value of properly validating uploads!

