Equivalent of Apache's SetEnv Variable

[Ed W]

  On 27/08/2010 03:20, Jim Ohlstein wrote:
> On 8/26/10 7:07 AM, Ed W wrote:
>
>
>> No one seems quite as excited about this as I feel? What am I missing?
>
> What you say is true, that such a file would be parsed as PHP if 
> requested in that manner but it needs to be uploaded successfully 
> first. Most modern PHP based galleries will not upload a file ending 
> with ".jpg" unless it actually is a JPEG. Same with a file 
> misidentified as a PNG. Try it with a phpinfo script. It won't upload 
> into apps like vBulletin or IPB. I can't speak for a lot of others 
> since I haven't tested them.
>
> If an app does upload a misidentified file so easily, then the onus is 
> on the webmaster to configure nginx correctly or, more simply, to not 
> use the app or to not allow uploads from untrusted sources. The method 
> proposed by Mike will work fine for such insecure apps, but the real 
> fix is to fix the app.
>
> The "try_files" approach will be much more efficient than any "if" 
> will be if you insist on using an insecure app.
>

I still think you guys aren't getting the point?

The wiki *documents* an insecure method of setting up many PHP 
applications.  It's almost the number one security vulnerability that 
you MUST secure your uploads directory and assuming that the PHP 
application can/will do this perfectly is optimistic at best.  A little 
help from the webserver is your minimum second layer of defence really.  
In fact many "secure" PHP applications delegate security of the upload 
directory completely to the webserver and ship with .htaccess files to 
disable php access...

It's not about whether you and I can setup a secure nginx setup, it's 
about the wiki encourage perhaps tens of thousands of users to setup 
their systems so that they can be *trivially* broken into.  Of course we 
can all sit back and call the users who followed "our" instructions 
idiots when this turns into a mass epidemic, but in the meantime there 
is a huge encouragement to setup a bunch of PHP apps so that they can be 
trivially broken into?

You are correct that all kinds of vague ways can defend against various 
aspects of this.  However, bottom line is that there are few perfect php 
applications which perfectly filter uploads.  There are a lot of clever 
ways to sneak junk past upload filters

Just to knock one final myth on the head.  Construct a .jpg file like 
this and it appears to me that it will work fine and also slip past many 
file filters:

# echo -e "\xff\xd8\xff\xe0" > test.jpg
# file test.jpg
test.jpg: JPEG image data
# php test.jpg
????
hello


The *correct* solution is to:
- Enable PHP for the minimum number of file locations possible
- Treat the upload directory as a special case and disable as much as 
possible there (beware ordering in conf files)
- If possible use try_files on certain locations to further limit scope 
of attack (may not be possible everywhere)

Why doesn't anyone think this is a huge accident waiting to blowup?

Ed W