<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 27/08/2010 20:06, Michael Shadle wrote:
<blockquote
cite="mid:AANLkTinkOhAkj=DPzuH=ZsDzwGOk=mn4+pPf+oXDzBXc@mail.gmail.com"
type="cite">
<pre wrap="">Initial testing shows:
cgi.fix_pathinfo = 0
and Igor's suggestion:
location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
fastcgi_pass 127.0.0.1:11000;
fastcgi_param SCRIPT_FILENAME $document_root$script;
fastcgi_param PATH_INFO $path_info;
include fastcgi_params;
}
To be working properly. I need to check out PATH_INFO using old style
and new style, make sure it still reports the expected behavior for
PHP scripts (PATH_INFO, PHP_SELF, all that jazz)
</pre>
</blockquote>
<br>
<br>
I will believe you that this works, but it seems incredibly subtle
and I for one don't quite understand why it's working? <br>
<br>
My point is only that we need to document how/why this is the
solution or users will deviate (innocently) and re-introduce the
problem<br>
<br>
<br>
Please, please also lets have the final solution also include an
example of how to efficiently *exclude* a certain directory. A good
proportion of apps that I have seen, ship with example Apache
configurations that do exactly this. <br>
<br>
The suggestion was adding an excluded location:<br>
<br>
<pre wrap=""> location ^~ <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>images<span class="moz-txt-tag">/</span></i> {
# just handle as static, don't consult regexps
}
</pre>
However, the issue I see here is that the user then needs to
specifically configure how that location should be handled, rather
than it being an *exclusion* to the original location<br>
<br>
Can we work excluded locations into the regexp (negative lookahead
supported?):<br>
<br>
<pre wrap=""> location ~ ^<meta http-equiv="content-type" content="text/html; charset=UTF-8"><tt class="regex">(?!/images/)</tt>(?<script>.+\.php)(?<path_info>.*)$ {
</pre>
<br>
The justification for excluding specific locations from the PHP
interpretor is that *most* applications don't encourage uploaded
executable cgi scripts and better apps are going to ship with a
recommendation to disable script execution in the upload directory.
Actually the situation is worse on Apache because there are so many
ways to trick the interpreter to run files. However, it's seems to
be such standard practice on Apache that it seems prudent to include
it in our standardised solution?<br>
<br>
Lots of justifications for this via google:<br>
<a class="moz-txt-link-freetext" href="http://www.google.co.uk/search?hl=en&q=disable+php+script+execution+upload">http://www.google.co.uk/search?hl=en&q=disable+php+script+execution+upload</a><br>
<br>
Someone argued that this might be *wanted* by the application...
(Some apps *wants* users to upload .php files which should then be
executable...??!!). I claim that it will be a serious minority of
applications desire this, and the vast majority will want uploaded
files to be non executable (regardless of extension)<br>
<br>
Can we please, please, please try and make sure the recommended
configuration includes examples of specifically *excluding*
locations not expected to contain executable scripts... My proposal
above...<br>
<br>
Ed W<br>
</body>
</html>