Equivalent of Apache's SetEnv Variable

Igor Sysoev igor at sysoev.ru
Thu Aug 5 13:58:04 MSD 2010


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/



More information about the nginx mailing list