On Thu, Jun 7, 2012 at 1:14 PM, Jeff Trawick <[email protected]> wrote: > On Thu, Jun 7, 2012 at 11:55 AM, Joe Orton <[email protected]> wrote: >> On Wed, Jun 06, 2012 at 09:08:02PM -0400, Jeff Trawick wrote: >>> Here are some valid requests which fail the 4317 checks: >>> >>> CONNECT foo.example.com[:port] >>> GET http://foo.example.com >>> GET proxy:http://foo.example.com/ (rewriting something which was >>> already proxied internally) >>> >>> I am leaning towards the likely minority view that it is problematic >>> to not know what the valid inputs to a ~15 year old module really are, >>> and we should whitelist a few more patterns such as those above and >>> see how far it gets us. Unfortunately this breaks a few users but >>> they are holding the testcases. >> >> Some thoughts: >> >> 1) FUD: if we start relaxing those checks again something else is going >> to break in an unexpected way. > > Certainly a valid fear :) > >> 2) mod_rewrite's behaviour should match mod_rewrite's documentation. If >> mod_rewrite guarantees that the input to the first rule set (in vhost >> contex) is a URL-path, it shouldn't arbitrarily ignore that guarantee >> for "special" URIs. >> >> I like Eric's suggestion of an opt-in RewriteOption. This will avoid >> having to iterate yet again if the whitelist is either too broad or too >> narrow, and can make the security implications (such as they are) >> explicit. > > Doesn't that just mean that the security implications are unknown when > you want mod_rewrite to process a proxied http request or a CONNECT? > I.e., you have to turn off the sanity checks in order to use certain > infrequently used features. > > Eric, what was the opt-in exactly? In what scope would you need to > enable it in order to process a CONNECT request?
e.g. RewriteOptions +"I know I'm running this regex against something that's not guaranteed to look like a URL-path, and I'll write a regex that carefully matches/captures the input"
