Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Fwd: Untainting an incoming request
References: <59E32A94-4045-457E-B372-6DA44F1692AD@webthing.com>
From: Nick Kew <nick@webthing.com>
Content-Type: text/plain; charset=us-ascii
Message-Id: <003CC6F9-D8A9-4648-B93B-BF1ECB1338F6@webthing.com>
Date: Fri, 6 Aug 2010 09:45:49 +0100
To: dev@httpd.apache.org
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v1081)

This (among others) seems to have got lost in the ether.

Dan, I did reply to your comments :)

Begin forwarded message:

> From: Nick Kew <nick@webthing.com>
> Date: 28 July 2010 23:38:10 GMT+01:00
> To: dev@httpd.apache.org
> Subject: Re: Untainting an incoming request
>=20
>=20
> On 28 Jul 2010, at 13:13, Dan Poirier wrote:
>=20
>> Example usage?
>>=20
>> Just to better understand the scope, can this do things that one
>> couldn't do (however painfully) with mod_rewrite?
>=20
> Very likely not (that's not the purpose of it).  Complexity - and =
hence
> a mod_rewrite-based alternative - is the enemy of security.  Merging
> duplicate request headers is a simplicity feature that would not sit
> so well in mod_rewrite, and without it we have huge complexity in
> devising untainting rules!
>=20
> I did indeed contemplate implementing the function with an "untaint" =
directive=20
> in  mod_rewrite, that would translate to a RewriteCond+RewriteRule =
pair.
> But that's asking for trouble: giving every future tweak to =
mod_rewrite
> potential to impact on or break a security feature.
>=20
> --=20
> Nick Kew