[PLUG] i can't believe this hasn't come up before

[Joe Pruett]

> Is this realization triggered by the recent Wordpress issue?
>
>  http://seclists.org/fulldisclosure/2009/Nov/141
>  http://seclists.org/fulldisclosure/2009/Nov/148
>
>
> The whole concept of placing executable text files in a web root and
> then allowing one to mix them with non-executable content (HTML,
> images, css, etc) is a pretty insane.  Yes, I know, everyone does it
> on nearly every platform, but that doesn't make it good.  Anytime you
> take static content and mix it with executable content, and then
> intentionally blur the line between the two, it's a recipe for
> disaster.  (Examples: MS office macro viruses, PDF+JavaScript,
> HTML+JavaScript, Flash+JavaScript, ...)
>
> Never trust your distro's defaults for Apache httpd.  They're almost
> always not right for you, and many distros continue to enable entirely
> too many "features" that no one ever uses.
>
>
> If you're writing an app for file uploads here are some approaches to
> keep it safe (in order of preference):
>
> A. Don't allow file uploads.  Find a way around it.
>
> B. Allow file uploads, but don't store files on disk.  Instead,
>   capture the uploaded file name an contents and store them in
>   database records.
>
> C. Store the file on disk, but *do not* use the provided file name to
>   store it.  Instead, store a record in the database which includes
>   the name of the file provided by the user, a unique identifier for
>   the file, and any other attributes you care to.  Ensure that you:
>
>    1. Do not store the contents of the file under the web root at
>       all.  Use a separate script to download the file based on the
>       unique identifier.
>
>    2. Use a file name based on the unique identifier that your code
>       generated during the upload.
>
> In cases B and C, watch out for SQL injection, cross-site scripting,
> and HTTP header injection.  Oh, not to mention, are users uploading
> files that contain viruses or trojans?  Are you becoming an accomplice
> to attacks from one user to another?  (Option A becomes more appealing
> now.)
>
>
> On the topic of badly designed PHP apps that allow file uploads, if
> any of you host osCommerce installations or apps derived from hit, you
> definitely want to take a look at this thread:
>  http://seclists.org/fulldisclosure/2009/Nov/169

yes, the wordpress alert was what triggered me to look at things more 
closely.  allowing someone to upload a jpg/gif/etc into a web space is a 
pretty standard thing.  and i doubt that most programmers would think that 
foo.php.jpg would be run by the php system.  the methods you list are 
certainly other ways around the issue.  but that isn't going to fix all 
the apps that are out there already.  from what i can tell, using the 
filematch apache method will deal with all of them.  there is a similar 
issue with addhandler being used for .cgi files, but that requires extra 
file permissions as well as other apache setup, so that is far less likely 
to be a problem for foo.cgi.jpg files.