httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <>
Subject RE: "RewriteRule ... /$1" considered harmful
Date Fri, 15 Apr 2011 09:34:58 GMT

> -----Original Message-----
> From: Stefan Fritsch 
> Sent: Freitag, 15. April 2011 11:08
> To:
> Subject: "RewriteRule ... /$1" considered harmful
> Hi,
> a client used
> RewriteRule ^/some/old/path/(.*)$ /$1
> in his httpd config, in order to redirect some paths that are now
> available directly under the document root. This has the problem that
> mod_rewrite guesses if the substituted path is an URL or an 
> absoulte local
> path by looking at the first component of the substitution 
> result. With
> the above rule, this first component is controlled by the client which
> causes security issues. For example,
> http://servername/some/old/path/etc/passwd
> does actually result in /etc/passwd being delivered to the client.

I doubt that this would work with the recommended

<Directory />
deny from all


> While this works as documented and secure behaviour can be obtained by
> appending [PT] or [R], I think this behaviour makes it far too easy to
> shoot onself in the foot.
> My first idea for saner semantics would be:
> - Don't try to guess what the user meant. Instead, treat the 
> substitution
> as URI unless some new option ([LOCALPATH]?) is given for the rule. In
> this case, look for file system paths only.
> - Add a new option for RewriteOptions to restore the old 
> guessing behaviour.
> What do you think?

IMHO that would be a dramatic change in behaviour. mod_rewrite was always
a map to storage (or uri to file) provider and mapping to different URL's was only an additional
OTOH I admit that I mostly use mod_rewrite this way.



View raw message