You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1997/11/10 17:23:37 UTC

How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Should we be chopping out the Proxy-Authorization before it is passed to
CGIs as well?

---------- Forwarded message ----------
>Path: scanner.worldgate.com!news.maxwell.syr.edu!newsfeed.eerie.fr!oleane!jussieu.fr!univ-angers.fr!univ-rennes1.fr!enst-bretagne.fr!not-for-mail
>From: Aymeric Poulain Maubant <Ay...@enst-bretagne.fr>
>Newsgroups: comp.infosystems.www.servers.unix
>Subject: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication)
>Date: 10 Nov 1997 15:02:32 +0100
>Lines: 45
>Sender: maubant@bernoulli.enst-bretagne.fr
>Message-ID: <wk...@bernoulli.enst-bretagne.fr>
>References: <87...@dejanews.com> <34...@uab.ericsson.se>
>NNTP-Posting-Host: bernoulli.enst-bretagne.fr
>X-Newsreader: Gnus v5.4.66/Emacs 19.34
>Xref: scanner.worldgate.com comp.infosystems.www.servers.unix:35237     


Michael Salmon <Mi...@uab.ericsson.se> writes:
[...]
> A script shouldn't get the authorization line, the web server should
> take care of all authorization. [...]

Hmm, not quite true.

- from  RFC 2068 : "Proxies MUST be completely transparent regarding
	user agent authorization. That is, they MUST forward the 
	WWW-Authenticate and Authorization headers untouched [...]"

Thus, a proxy server MUST let the last server in the chain resolve
the authorization process.


I do have a question on this topic, btw. I'm currently using an Apache
1.2.4 somewhere, and wrote a cgi-script which need to challenge the
client by sending her a WWW-Authenticate header. I WANT not my apache
server to deal then with the "Authorization: ..." response. Instead, I
WANT my cgi-script get this header untouched and play with it (this
script need to know who is calling it, and then pass along the
Authorization data to a second web server in a transparent manner).

I tried a version where the script sends a Proxy-Authenticate (407) to
the client : the Proxy-Authorization response from the client is
passed to the script via the apache1.2.4 as an ENV variable
(HTTP_PROXY_AUTHORIZATION).  Great! Unfortunately, not all browsers
know what is a 407 answer.

I would like this behaviour to work with a 401 answer as well. That
is, I would like apache1.2.4 to pass the simple "Authorization: ..."
response to my script, via an ENV variable. I read somewhere it is
possible which apache (otherwise it won't be RFC 2068 compliant), but
how can I do it ?

Thanks for your answers,

	Aymeric



Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Elizabeth Mattijsen <li...@xxlink.nl>.
Aren't you already able to do just this with mod_perl and/or mod_php?  If
so, why bother about it: "use mod_perl or mod_php" should be the answer then.


Elizabeth Mattijsen
xxLINK Internet Services

Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Martin Kraemer <Ma...@mch.sni.de>.
On a side topic: OH, YES: Proxy Authentication works just fine in 1.3bx.
(And for that matter, the Proxy-Authenticate: header ought to be zapped
just as well. Dirk, I can understand you very well. I've often wanted to
"use the available authentication mechanism" to have CGI scripts control
who they work for, and what authetication data base they use. If it was for
me, I might be tempted to allow another "Option CGIAuth" option which was
disabled by default. But you can still convince me ;-)

About Proxy Auth: use it like in
<Directory proxy:*>
 <Limit GET POST ...>
  require valid-user
...
Works just fine. I'm using it here.

    Martin

On Mon, Nov 10, 1997 at 06:59:32PM +0100, Dirk-Willem van Gulik wrote:
> >  You are treating the
> > Proxy-Authenticate header as if it is only ever used for passwords that
> > security does not matter for.
> 
> No; it is used for username and passwords which are (currently) not used
> by any part of apache.
>  
> > You are arguing that we need to pass proxy-authenticate because we don't
> > pass Authorization, and because of this then passing proxy-authenticate
> > is not as bad as passing Authorization.
> 
> Hmm, I was trying to argue that they are fundamentally different, as one
> set is used by the apache server, and relates to data and responsibilties 
> of the server; and the other most certainly does not relate to data or
> reps. which are not part of the security realm managed by the server.
> 
> But perhaps one day; someone will add
> Auth module support on proxy level... and they of course your point is
> perfectly valid.

-- 
| S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Dirk-Willem van Gulik <di...@elect6.jrc.it>.
On Mon, 10 Nov 1997, Marc Slemko wrote:
> On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:
> > On Mon, 10 Nov 1997, Marc Slemko wrote:
> > > On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:
> >  
> > > You miss the point.  You can argue about why you should have the
> > > Authorization: header passed as well.  The point is that it is not secure,
> > > period.  Any possible uses of it does not make it secure.  
.... 
> > Now the third issue; what if the server is setup to allow CGI scripts to
> > do proxying on behalf of the user. Now the only Auth header it can get
> > (and possibly needs to, to do its jobs) is that intented for its role as a
> > proxy; Proxy-Auth.. i.e. outside mod_auth.c uses.
> > 
> > So the user gives the CGI script a proxy username/password pair which is
> > only of relevance to the CGI script and cannot be used outside that
> > context; the CGI script has to do the checking itself (mod_*_auth.c is not
> > going to do that) and the uid/pwd pair has no relevance to any of the
> > realms the server itself is responsible for.
> 
> You can argue the exact same thing about the Authorization header.  "oh,
> you can just use seperate passwords for it so you don't really have to
> worry about it since people won't be dumb".  You are treating the
> Proxy-Authenticate header as if it is only ever used for passwords that
> security does not matter for.

No; it is used for username and passwords which are (currently) not used
by any part of apache.
 
> You are arguing that we need to pass proxy-authenticate because we don't
> pass Authorization, and because of this then passing proxy-authenticate
> is not as bad as passing Authorization.

Hmm, I was trying to argue that they are fundamentally different, as one
set is used by the apache server, and relates to data and responsibilties 
of the server; and the other most certainly does not relate to data or
reps. which are not part of the security realm managed by the server.

If you take the moral high-ground; then I can see your point easily; but I
am trying to strike a balance between sound paranoia when it comes to
protecting data managed by the server itself, and a slightly slacker
regime when it comes to data which only passes through the server, and
with whom it has little dealings. But perhaps one day; someone will add
Auth module support on proxy level... and they of course your point is
perfectly valid. My question left is; is that reasonable to assume or just
level of paranoia more difficult to support... though I DO strongly
support the first two levels described.

:-)

Dw.


Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:

> On Mon, 10 Nov 1997, Marc Slemko wrote:
> 
> > On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:
>  
> > You miss the point.  You can argue about why you should have the
> > Authorization: header passed as well.  The point is that it is not secure,
> > period.  Any possible uses of it does not make it secure.  
> 
> I agree that we seem to be on different wavelengths; Security wise, it is
> absolutely essential that the apache, while it is being a proxy to an
> untrusted environment, filters out the Proxy-Auth* line prior to passing
> it on to the next server. This I absolutely agree with. 

Correct, but irrelevant.

> 
> Likewise it is very essential that in an untrusted user environment the
> Auth header is zapped as well, prior to passing it on to the CGI script. 

Correct.

> Now the third issue; what if the server is setup to allow CGI scripts to
> do proxying on behalf of the user. Now the only Auth header it can get
> (and possibly needs to, to do its jobs) is that intented for its role as a
> proxy; Proxy-Auth.. i.e. outside mod_auth.c uses.
> 
> So the user gives the CGI script a proxy username/password pair which is
> only of relevance to the CGI script and cannot be used outside that
> context; the CGI script has to do the checking itself (mod_*_auth.c is not
> going to do that) and the uid/pwd pair has no relevance to any of the
> realms the server itself is responsible for.

You can argue the exact same thing about the Authorization header.  "oh,
you can just use seperate passwords for it so you don't really have to
worry about it since people won't be dumb".  You are treating the
Proxy-Authenticate header as if it is only ever used for passwords that
security does not matter for.

The point is that there is exactly the same risk of exposure.  Arguments
about how it _can_ be useful to pass it to a CGI changes nothing.  You can
make the exact same arguements for the Authorization header.  Any way you
look at it, it is not secure to allow scripts to get either of them in the
environment.

You are arguing that we need to pass proxy-authenticate because we don't
pass Authorization, and because of this then passing proxy-authenticate
is not as bad as passing Authorization.


Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Dirk-Willem van Gulik <di...@elect6.jrc.it>.
On Mon, 10 Nov 1997, Marc Slemko wrote:

> On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:
 
> You miss the point.  You can argue about why you should have the
> Authorization: header passed as well.  The point is that it is not secure,
> period.  Any possible uses of it does not make it secure.  

I agree that we seem to be on different wavelengths; Security wise, it is
absolutely essential that the apache, while it is being a proxy to an
untrusted environment, filters out the Proxy-Auth* line prior to passing
it on to the next server. This I absolutely agree with. 

Likewise it is very essential that in an untrusted user environment the
Auth header is zapped as well, prior to passing it on to the CGI script. 

Now the third issue; what if the server is setup to allow CGI scripts to
do proxying on behalf of the user. Now the only Auth header it can get
(and possibly needs to, to do its jobs) is that intented for its role as a
proxy; Proxy-Auth.. i.e. outside mod_auth.c uses.

So the user gives the CGI script a proxy username/password pair which is
only of relevance to the CGI script and cannot be used outside that
context; the CGI script has to do the checking itself (mod_*_auth.c is not
going to do that) and the uid/pwd pair has no relevance to any of the
realms the server itself is responsible for.

The only reason I could see is that it allows easier construction of
troyan horses; i.e. the user might be tempted to enter the wrong uid/pwd
in the wrong place. But so does the usual HTML trickery like 

	<form action="mailto:..">
	Login:  <input><br>
	Passwd: <inputtype="password"><br>
	<input type=submitvalue="login">
	</form>

?? or am I still not understanding the exact point ??

Dw.


Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:

>  
> I understand that; and I think that the current behavour (or am I wrong
> in understanding mod-proxy and its interaction with cgi ?) is that when
> apache is acting as a proxy; it will remove those lines, (i.e. it does
> not pass them on to the origin server) but when it is somehow configured
> 'as a normalish server' to have some CGI acting as a proxy (we do that
> here for example for ldap and urn resolution experiments) then this CGI
> should really have access to those headers; in particular because they
> where most likely caused to be supplied by the same script.

You miss the point.  You can argue about why you should have the
Authorization: header passed as well.  The point is that it is not secure,
period.  Any possible uses of it does not make it secure.  

> 
> So in short, I would say that this is a very differnt case.
> 
> 
> Dw.
> 
> 


Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Dirk-Willem van Gulik <di...@elect6.jrc.it>.
On Mon, 10 Nov 1997, Marc Slemko wrote:
> On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:
> > On Mon, 10 Nov 1997, Marc Slemko wrote:
> > 
> > > Should we be chopping out the Proxy-Authorization before it is passed to
> > > CGIs as well?
> > 
> > Hmm, the proxy does _not_ pass it on I beleive when carrying it out its
> > duty as a proxy to the final origin server. So this seems correct to me.
> > 
> > Apache in general could of course be set up to have some backend CGI
> > doing some proxying; in which case it is perfectly entitled to see those 
> > strings; it propably provoced them with a 407 anyway.
> 
> I am not talking about proxy, just passing to CGI.  Authorization: is not
> passed to CGI scripts for valid security reasons.  I am suggesting that
> Proxy-Authorization should be treated exactly the same way.  It is not
> secure to pass to CGIs so it should not be allowed.
 
I understand that; and I think that the current behavour (or am I wrong
in understanding mod-proxy and its interaction with cgi ?) is that when
apache is acting as a proxy; it will remove those lines, (i.e. it does
not pass them on to the origin server) but when it is somehow configured
'as a normalish server' to have some CGI acting as a proxy (we do that
here for example for ldap and urn resolution experiments) then this CGI
should really have access to those headers; in particular because they
where most likely caused to be supplied by the same script.

So in short, I would say that this is a very differnt case.


Dw.



Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 10 Nov 1997, Dirk-Willem van Gulik wrote:

> On Mon, 10 Nov 1997, Marc Slemko wrote:
> 
> > Should we be chopping out the Proxy-Authorization before it is passed to
> > CGIs as well?
> 
> Hmm, the proxy does _not_ pass it on I beleive when carrying it out its
> duty as a proxy to the final origin server. So this seems correct to me.
> 
> Apache in general could of course be set up to have some backend CGI
> doing some proxying; in which case it is perfectly entitled to see those 
> strings; it propably provoced them with a 407 anyway.

I am not talking about proxy, just passing to CGI.  Authorization: is not
passed to CGI scripts for valid security reasons.  I am suggesting that
Proxy-Authorization should be treated exactly the same way.  It is not
secure to pass to CGIs so it should not be allowed.


Re: How apache can pass the Authorization: header to a script ? (was: Re: Apache CGI Authentication) (fwd)

Posted by Dirk-Willem van Gulik <di...@elect6.jrc.it>.
On Mon, 10 Nov 1997, Marc Slemko wrote:

> Should we be chopping out the Proxy-Authorization before it is passed to
> CGIs as well?

Hmm, the proxy does _not_ pass it on I beleive when carrying it out its
duty as a proxy to the final origin server. So this seems correct to me.

Apache in general could of course be set up to have some backend CGI
doing some proxying; in which case it is perfectly entitled to see those 
strings; it propably provoced them with a 407 anyway.

Dw.