On Thu, Aug 05, 2010 at 10:49:52AM +0200, Grzegorz Nosek wrote:

> On Thu, Aug 05, 2010 at 12:19:22PM +0400, Igor Sysoev wrote:
> > The issue is that someone is able to upload a image file to a directory
> > with scripts (I do not know why he is not able to override some valid
> > images or even the scripts themself in this case). Then someone requests
>
> I guess it comes from apache-land, where the simplest config is "run all
> .php files via the interpreter" (compared to nginx's "run all files under
> this directory via the interpreter"). The directory where the user is
> able to upload files is often a subdirectory of the application, as in:
>
> /index.php
> /foo.php
> /uploads
> /1.gif
> /2.png
> /images
> /foo.gif
>
> The more naive apps simply allow uploading of everything and store that
> under /uploads, while the smarter ones try to filter files for validity.
> So you cannot overwrite /foo.php or /images/foo.gif (barring directory
> traversal bugs...) but can upload /uploads/anythingyoulike.gif

Then it can be easy fixed by

location ^~ /uploads/ {
or
location ~ ^/uploads/ {

> > the image file as "/dir/1.gif/2.php" making exploit. I do not see
> > how using types will help in a case when nginx ahs not access to remote
> > filesystem.
>
> It won't help at all in that case. The proposed types would be a feature
> of the static module. It wouldn't be useful in single-huge-site
> deployments, only for sites running on a single server (Nginx+PHP).

I never liked this Apache idea of internal MIME-types such as
application/x-httpd-php, text/x-server-parsed-html, etc.
I believe it confuses and complicates things.


--
Igor Sysoev
http://sysoev.ru/en/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx