Equivalent of Apache's SetEnv Variable

[Ed W]

  Slow reply - apologies

>> See, just checked the wiki.  Surely this example allows you to
>> immediately upload a new file with a .php suffix and exploit the server?
>>       http://wiki.nginx.org/NginxMediaWiki
> Mediawiki doesn't allow that.  It filters by an allowed list of
> extensions, and .php isn't among them.

Uh uh.  As demonstrated above, you appear to be able to bypass this by 
adding /.php to the URL

Lets spell this out.  Anyone using these suggested default 
configurations is massively vulnerable to injected php scripts.  Just 
upload an "phpinfo()" script named hello.jpg then browse to 
http://url/hello.jpg/.php and watch as your php gets executed

There may be a bunch of ways that this isn't a vulnerability on all 
configurations, but the point is this is a *default* and a simple scan 
of a bunch of nginx machines is going to reveal a high count of machines 
vulnerable to injection?  Not sure why this isn't getting more attention?

Look I'm being a bit subtle about this, but I would have thought this 
was an urgent scramble to fix kind of thing?

> Of course, if you can also let Nginx provide another ounce of
> prevention, then all the better.

This isn't an nginx "problem", it's a configuration problem.  "we" (the 
wiki) are advising people to incorrectly configure their PHP apps

>    Unfortunately most PHP applications
> expect to be able to run arbitrary PHP scripts from almost any directory
> under the sun,

Hmm, I disagree on "most".  The small selection that I use tend to use 
only a small number of locations.

In my config I either:
- Move the data dirs out of the htdocs patch altogether (gallery2 and 
others support this)
- Configure only certain files or restricted directories to be treated 
as PHP apps
- Reluctantly I might do the reverse and allow all .php files to be 
treated as PHP, but then add an "if" in the location to prevent the data 
dirs from being scanned.  I needed to do this for mediawiki for 
example.  Note that this is a tricky config because generally you use a 
regexp location for the .php and so you can't override it with a 
"location /uploads" since it's parsed later - instead you need to add an 
"If" into the php location...

>   or simply
> make sure that it's not possible to upload files ending with .php.

This is a partial solution at best.  As shown previously it doesn't 
actually help you for a lot of configuration examples since trivially 
appending /.php on the end allows you to get the file to be parsed by 
the PHP interpretor under many configurations?



Webapps are often built assuming apache and will ship with a bunch of 
.htaccess files that stop the php interpretor running files in that 
location, ie the upload files dir will have a .htaccess in it turning 
off the php interpretor.  Now even under Apache this is hit and miss 
because many installations will disable htaccess files for performance 
reasons (or not allow all actions from the .htaccess).  Of course when 
you install your PHP app on nginx I would guess it's quite normal for 
the operator to forget to scan for .htaccess files and translate these 
to nginx config rules (not nginx's fault, this is an app configuration 
issue)

No one seems quite as excited about this as I feel?  What am I missing?

Ed W