Bug#436520: There is no policy on HTTP_PROXY variable, can we create one?
On Fri, 17 Aug 2007, Mike Hommey wrote:
> On Thu, Aug 16, 2007 at 07:34:51PM -0700, Don Armstrong <firstname.lastname@example.org> wrote:
> > On Fri, 17 Aug 2007, Junichi Uekawa wrote:
> > > HTTP_PROXY, or http_proxy (and ftp_proxy) is used in many
> > > applications within Debian.
> > >
> > > There is a well-known remote attack using HTTP_* variables can be
> > > set to arbitrary values for CGI scripts, and thus there is a need
> > > for protection against that.
> > Is there any reason why programs which use HTTP_PROXY can't check
> > GATEWAY_INTERFACE, SERVER_NAME, REQUEST_METHOD or similar and ignore
> > the capitalized env variable in such a case?
> > [For reference, LWP ignores HTTP_PROXY for CGI_HTTP_PROXY in the
> > presence of REQUEST_METHOD.]
> > The alternative is just to require CGIs to unset HTTP_PROXY (though
> > CGI writers sometimes aren't terribly aware of these things.)
> I'm not sure this would also be a terribly good idea... How about CGIs
> that need to get data from external HTTP servers which they can't access
> if not through a proxy ? (such case *do* exist)
Then they sanitize their ENV before calling the external proxying
program. The real issue is CGI programs accidentally passing
HTTP_PROXY to children.
What about the following:
Programs which do proxying should all accept http_proxy without the
need for further env. variables being set.
Programs which accept HTTP_PROXY for compatibility reasons should
deprecate such usage, and ignore HTTP_PROXY when REQUEST_METHOD or
GATEWAY_INTERFACE is set, ideally with an informative warning.
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behaviour, I have not yet achieved a state of
-- Manoj Srivastava in email@example.com