> I think the best course of action is to get Ed's explanation of the
> issue onto the wiki, add a link from each and every PHP config back to
> it along with a request that someone who actually uses that config to
> verify that it is not vulnerable (or apply a fix if it is) and update
> the wiki. If we can't get that to happen then we deserve what we get.

Can we push first for a generic config that everyone can start from? I
think Maxim Dounin's response a few moments ago now covers the key areas:

Single script, enable only that single script:

location = /blah/script.php {
include /etc/nginx/fastcgi_params;
fastcgi_pass localhost:9000;
}


Exclude single dir, everything else executable:

location ^~/images/ {
# just handle as static, don't consult regexps
}

location ~ \.php$ {
fastcgi_pass ...
}



Or, alternatively (and much more clear, but may have problems
in older nginx versions), use inclusive/nested locations:

location / {
...

location ~ \.php$ {
fastcgi_pass ...
}
}

location/images/ {
# just handle as static
}




I don't really understand all the aspects of Brian Mercer's response - perhaps someone can meld the best bits into the above:

location ~ .*/files/.* {
try_files $uri =404 # or index.php?q=$uri or @drupal depending on your config
}


There may be additional aspects that we haven't considered given the generic fastcgi_params script and other CGI implementations? Anyone know of obvious abuses of "../" or any SSI type features?

Note we haven't addressed path_info with the above solution. I'm ignorant enough that I still think it's not a problem assuming you avoid executing scripts in untrusted file locations, but perhaps someone can show that we need to add that to the generic solution also?

Please improve and fully quote suggestions on the above so that we can cut and paste into the wiki

Thanks

Ed W

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