You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2011/04/15 11:08:26 UTC
"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.
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?
Cheers,
Stefan
Re: "RewriteRule ... /$1" considered harmful
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 02 May 2011, Eric Covener wrote:
> On Sun, May 1, 2011 at 10:40 PM, Eric Covener <co...@gmail.com>
wrote:
> >> - Create new directives RewriteToPath, RewriteToURL that don't
> >> do guessing. - Document clearly the problems that may be caused
> >> by the guessing behaviour of RewriteRule. Maybe even mark
> >> RewriteRule as deprecated in 2.4.
> >
> > another one on users@, +1 to this approach and strong advice in
> > the manual to use one of the other flavors.
> >
> > Rewriterule in per-server context could emit a once-per-restart
> > warning if it interprets a substitution as a filesystem path. If
> > it triggers a 403 from <Directory /> inadvertently, it will
> > precede the "permission denied by server configuration" in the
> > error log.
>
> I took a pass at the doc to make the stuff we're discussing a bit
> more explicit which might help the discussion/deprecation too.
>
> http://people.apache.org/~covener/patches/rewrite-substitution_clar
> ity.diff
>
> I think the DocumentRoot-relative substitution should not be
> preserved in the RewriteToURL -- seems like an unnecessary
> complication. IMO RewriteToURL implies PT just like
> per-directory, however this comes with some baggage -- exposing
> yourself to loops and losing the intuitive use of the L flag.
Because Eric asked on IRC: I am currently preferring to do this after
2.4.0 for the following reason:
I also wanted mod_rewrite to be smarter about what prefix to prepend
in directory context, now that we have the context prefix / context
document root info available from mod_alias/mod_userdir. But since
this will not be quite backward compatible, I thought it would be a
good idea to bundle this change with RewriteToURL/RewriteToFile.
RewriteRule would then keep behaving exactly as it does now, and the
new directives would behave somewhat differently. This should make
inclusion in a 2.4.1+ release painless.
Getting the behaviour in directory context right will need some
thought and a lot of testing. Therefore I don't want to rush this into
2.4.0.
Re: "RewriteRule ... /$1" considered harmful
Posted by Rich Bowen <rb...@rcbowen.com>.
On May 2, 2011, at 12:04 AM, Eric Covener wrote:
> I took a pass at the doc to make the stuff we're discussing a bit more
> explicit which might help the discussion/deprecation too.
>
> http://people.apache.org/~covener/patches/rewrite-substitution_clarity.diff
+1 to changes.
--
Rich Bowen
rbowen@rcbowen.com
rbowen@apache.org
Re: "RewriteRule ... /$1" considered harmful
Posted by Rich Bowen <rb...@rcbowen.com>.
On May 2, 2011, at 12:04 AM, Eric Covener wrote:
> I took a pass at the doc to make the stuff we're discussing a bit more
> explicit which might help the discussion/deprecation too.
>
> http://people.apache.org/~covener/patches/rewrite-substitution_clarity.diff
+1 to changes.
--
Rich Bowen
rbowen@rcbowen.com
rbowen@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: "RewriteRule ... /$1" considered harmful
Posted by Eric Covener <co...@gmail.com>.
On Sun, May 1, 2011 at 10:40 PM, Eric Covener <co...@gmail.com> wrote:
>> - Create new directives RewriteToPath, RewriteToURL that don't do guessing.
>> - Document clearly the problems that may be caused by the guessing
>> behaviour of RewriteRule. Maybe even mark RewriteRule as deprecated in
>> 2.4.
>>
>
> another one on users@, +1 to this approach and strong advice in the
> manual to use one of the other flavors.
>
> Rewriterule in per-server context could emit a once-per-restart
> warning if it interprets a substitution as a filesystem path. If it
> triggers a 403 from <Directory /> inadvertently, it will precede the
> "permission denied by server configuration" in the error log.
>
I took a pass at the doc to make the stuff we're discussing a bit more
explicit which might help the discussion/deprecation too.
http://people.apache.org/~covener/patches/rewrite-substitution_clarity.diff
I think the DocumentRoot-relative substitution should not be preserved
in the RewriteToURL -- seems like an unnecessary complication. IMO
RewriteToURL implies PT just like per-directory, however this comes
with some baggage -- exposing yourself to loops and losing the
intuitive use of the L flag.
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: "RewriteRule ... /$1" considered harmful
Posted by Eric Covener <co...@gmail.com>.
On Sun, May 1, 2011 at 10:40 PM, Eric Covener <co...@gmail.com> wrote:
>> - Create new directives RewriteToPath, RewriteToURL that don't do guessing.
>> - Document clearly the problems that may be caused by the guessing
>> behaviour of RewriteRule. Maybe even mark RewriteRule as deprecated in
>> 2.4.
>>
>
> another one on users@, +1 to this approach and strong advice in the
> manual to use one of the other flavors.
>
> Rewriterule in per-server context could emit a once-per-restart
> warning if it interprets a substitution as a filesystem path. If it
> triggers a 403 from <Directory /> inadvertently, it will precede the
> "permission denied by server configuration" in the error log.
>
I took a pass at the doc to make the stuff we're discussing a bit more
explicit which might help the discussion/deprecation too.
http://people.apache.org/~covener/patches/rewrite-substitution_clarity.diff
I think the DocumentRoot-relative substitution should not be preserved
in the RewriteToURL -- seems like an unnecessary complication. IMO
RewriteToURL implies PT just like per-directory, however this comes
with some baggage -- exposing yourself to loops and losing the
intuitive use of the L flag.
--
Eric Covener
covener@gmail.com
Re: "RewriteRule ... /$1" considered harmful
Posted by Eric Covener <co...@gmail.com>.
> - Create new directives RewriteToPath, RewriteToURL that don't do guessing.
> - Document clearly the problems that may be caused by the guessing
> behaviour of RewriteRule. Maybe even mark RewriteRule as deprecated in
> 2.4.
>
another one on users@, +1 to this approach and strong advice in the
manual to use one of the other flavors.
Rewriterule in per-server context could emit a once-per-restart
warning if it interprets a substitution as a filesystem path. If it
triggers a 403 from <Directory /> inadvertently, it will precede the
"permission denied by server configuration" in the error log.
Re: "RewriteRule ... /$1" considered harmful
Posted by André Malo <nd...@perlig.de>.
* Stefan Fritsch wrote:
> My impression is that mapping to different URLs is by far the more
> frequent use case, but I may be wrong. A different idea would be
>
> - Create new directives RewriteToPath, RewriteToURL that don't do
> guessing. - Document clearly the problems that may be caused by the
> guessing behaviour of RewriteRule. Maybe even mark RewriteRule as
> deprecated in 2.4.
Why not flags to RewriteRule? like
RewriteRule ... /$1 [abs]
(or [rel]).
For compat reasons I'd keep the current behaviour without such a flag.
nd
--
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"
Im Westen was neues: <http://pub.perlig.de/books.html#apache2>
RE: "RewriteRule ... /$1" considered harmful
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Fri, April 15, 2011 11:34, "Plüm, Rüdiger, VF-Group" wrote:
>> 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
> </Directory>
>
> setting.
True, but this is often a PITA to use with complex auth configs. This will
improve with the new authz merging in 2.4, but I still think mod_rewrite
should behave more predictable. After all, some RewriteRule that works
perfectly well can stop working just because of a new directory being
created in /. Even if access to the new directory is forbidden, this is
still disruptive.
>> 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
> feature.
> OTOH I admit that I mostly use mod_rewrite this way.
My impression is that mapping to different URLs is by far the more
frequent use case, but I may be wrong. A different idea would be
- Create new directives RewriteToPath, RewriteToURL that don't do guessing.
- Document clearly the problems that may be caused by the guessing
behaviour of RewriteRule. Maybe even mark RewriteRule as deprecated in
2.4.
Cheers,
Stefan
RE: "RewriteRule ... /$1" considered harmful
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Stefan Fritsch
> Sent: Freitag, 15. April 2011 11:08
> To: dev@httpd.apache.org
> 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
</Directory>
setting.
>
> 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
feature.
OTOH I admit that I mostly use mod_rewrite this way.
Regards
Rüdiger