www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David J N Begley <d.beg...@uws.edu.au>
Subject Re: mod_actions/8711: HTTP authentication variables not propogated to Action scripts
Date Tue, 12 Mar 2002 01:19:20 GMT
On 11 Mar 2002, trawick@apache.org wrote:

> [In order for any reply to be added to the PR database, you need]
> [to include <apbugs@Apache.Org> in the Cc line and make sure the]

BTW, is "apache-bugdb@" sufficient or do you need both it and "apbugs@"?
There is an inconsistency between the comments in the email and the actual
email address used.

> Please set up authorization for /cgi-bin/phpwrap and let us know if the
> problem is resolved.

Is the auth'd user now logged in access_log?  Yes.
Are the appropriate CGI variables now available to PHP scripts?  Yes.
Is this an acceptable solution/work-around?  Not really - see below.

> After looking at the code, it is clear that with Apache 2.0 you need to set
> up authorization for the target of the subrequest (/cgi-bin/phpwrap in your
> case).

Why such a fundamental shift from Apache 1.3?  There are a number of problems
with this approach:

- Subrequests utilising generalised scripting engines are not the ultimate
  target of authentication anyway, that's the original content.

- The authentication actually happened with the original content, it's just
  not visible either in the access_log nor to the script (run by the engine,
  which is in turn run as a subrequest from within Apache).

- Since you'd now need to apply authentication to every subrequest target
  you can't have just one copy of the generalised scripting engine installed;
  one for each separate authentication realm on the Web server, plus one for
  non-authenticated requests.  This is quickly spiralling outta control...

- Then there's the basic end-user confusion of why something that seemed
  logical and worked with Apache 1.3 no longer works with 2.0.  :-(

I guess I'm asking for some logical rationale as to why this was changed for
Apache 2.0 - at this stage, it seems pretty dumb to me.  :-(

> /cgi-bin/phpwrap would need to be protected anyway in case the client could
> request that resource anyway (e.g., specify /cgi-bin/phpwrap directly).

At first I agreed whole-heartedly with this (and generally speaking, still
agree) - then I remembered (and tried) PHP's built-in security in this regard;
I requested "/cgi-bin/phpwrap" directly (with no authentication) and got what
I expected:

  Security Alert! PHP CGI cannot be accessed directly.

  This PHP CGI binary was compiled with force-cgi-redirect enabled. This means
  that a page will only be served up if the REDIRECT_STATUS CGI variable is
  set. This variable is set, for example, by Apache's Action directive

It should be possible to still protect the "subrequest target" in this case
anyway by just refusing requests wherein the request URI contains/matches
"/cgi-bin/phpwrap" without screwing up subrequest processing (since in that
case the _real_ subrequest target would only appear in the SCRIPT_xxx
variables, not in REQUEST_xxx, REDIRECT_xxx or PATH_xxx).


View raw message