httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: svn commit: r1554300 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/ap_regex.h include/http_core.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h server/core.c server/request.c server/util_pcre.c
Date Wed, 01 Jan 2014 17:26:21 GMT
Am Mittwoch, 1. Januar 2014, 14:06:17 schrieb Graham Leggett:
> > Maybe making ap_regname() accept an optional prefix string that
> > is 
> > prepended to each name would be a good idea?
> >
> > 
> >
> > Maybe the use in <LocationMatch> and friends should add some
> > prefix to  the names? Like "m_" or "match_" or "m:"? This would
> > make it more difficult to shoot oneself in the foot by allowing a
> > remote attacker to set env variables that have some special
> > meanings elsewhere in httpd (or in an executed cgi script).
> > And/or maybe these values should be filtered out again when
> > exporting them to cgi env variables?
> I wondered about this, on one hand it is nice to be able to set any
> variable, but on the other hand there is a lot of safety in
> preventing someone from being able to shadow an existing variable.
> I had "MATCH_FOO" in mind originally.

I am in favor of adding a prefix. If there are important use cases for 
setting arbitrary variables, one could (later) add a special opt-in 
mechanism, e.g. using "noprefix:foo" in the regex leads to variable 
"foo" without the prefix being set.

Mime
View raw message