mod_rewrite/5973: Possible design flaw in backreference/variable replacements

[Daniel Stephens <da...@cheeseplant.org>]

>Number:         5973
>Category:       mod_rewrite
>Synopsis:       Possible design flaw in backreference/variable replacements
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Sun Apr 09 12:50:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     daniel@cheeseplant.org
>Release:        1.3.12
>Organization:
apache
>Environment:
Linux - Redhat 6.2 (fresh install)
>Description:
Because the backreference/variable substitutions in apply_rewrite_rule() are
applied sequentially, each to the output of the previous one, rather than 
finding all substitution candidates in the FIRST string and then doing the
replacements, some very nasty aliasing problems occur.

Consider this:
RewriteRule  /thumbnail/(.*).jpg	/cgi-bin/genthumb.cgi?id=$1

Now, if the request is for /thumbnail/abc%253Adef.jpg
What i'd EXPECT is  /cgi-bin/genthumb.cgi?id=abc%3Adef
(since mod_rewrite un-escapes the first layer of encoding)
HOWEVER, because that substitution is done in step 2., and step 3. does the %
substitutions, mod_rewrite goes and turns the %3 into nothing, and I actually
get /cgi-bin/genthumb.cgi?id=abcAdef

This is (in my opinion at any rate) just plain wrong behaviour, because
(a) it breaks any URL which happens to decode to have a % in it, and (b)
because users can do things like make a request like:

/thumbnail/%25{SCRIPT_FILENAME}

And it'll happily expand the variable, even though I (the creator of the
rewrite rule) only want it to do a simple substitution.  This could also 
conceivably used to exploit weaknesses in map rules, but that would admittedly
require a lot of knowledge of the server's configuration.
>How-To-Repeat:
Set up something like:

RewriteRule  /thumbnail/(.*).jpg	/cgi-bin/genthumb.cgi?id=$1

Try these requests:

/thumbnail/abc%253Adef.jpg
/thumbnail/%25{SCRIPT_FILENAME}
>Fix:
There's really only one solution, namely the substitution has to be a one-pass
operation, or at least act that way. The ONLY $'s and %'s that it should be
aware of as variable identifiers are those that were in the ORIGINAL REWRITE
RULE, and it MUST NOT trigger off any that are in substitution strings.
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]