I have had reports of this being a problem as well (last week in fact :-) here is Ken
Coar's analysis:
<ken>
The analysis:
Apache will accept a %2f in a URI it receives under two conditions
only: when it appears in the query string, and/or when the request
is for a proxy document. In all other cases it returns a 404.
You should find that there is no corresponding message in the error_log
file; that is because the 404 is manufactured rather than being a
translation of a filesystem ENOENT error.
This check is performed by function ap_unescape_uri() in
src/main/util.c. It has been there since the beginning of
Apache 1.2, so it is not a regression. I believe its intention
is to intercept potential 'sneak-attacks' on the URI space.
If possible, it would be nice if this check were deferred until
the determination of the path, path-info, and query-string was
made, and then applied only to the path. However, I think that
may be a significant undertaking, and may not even be possible
in Apache 1.3. I will look into it next week, however.
In the meantime, the workaround is to pass the escaped string as
part of the query-string rather than the path-info, and have
the script (or whatever is currently expecting the info to be in the
path-info) change how it parses its input.
</ken>
My first take is that this is a reasonable request. We'll probably look at doing a
custom
build for Apache 1.3 for our internal customer if it does not significantly risk
breaking
other parts of the server. We'll post whatever we come up with.
Bill
> From: "Robin Thellend" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 13, 2001 10:20 PM
>
>
> > The following reply was made to PR general/7865; it has been noted by GNATS.
> >
> > From: Robin Thellend <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > Subject: Re: general/7865: %2F in PATH_INFO
> > Date: Wed, 13 Jun 2001 22:15:45 -0500 (CDT)
> >
> > No where in RFC 2396 does it mention that %2F is illegal in a URI. Like
> > you say, %2F is a '/' that's not a path seperator.
> >
> > In my particular example:
> >
> > http://pfft.net/robin/foo.php/foo%2Fbar
> >
> > %2F should be passed to script 'foo.php' unaltered and it is up to the
> > script the interpret the meaning of it.
> >
> > The security concerns should be limited to accessing the filesystem. Then
> > and only then should you make sure there is no %2F in the path. However,
> > in my example, the filesystem access ends at foo.php. Everything else
> > after it has nothing to do with accessing a file and should be passed to
> > the script.
>
> It may actually become possible to address this in 2.0, it is far from reasonable
> to consider this for 1.3. The question remains, should it be addressed?
>
> The truly is _no_ standard for the contents of the path_info cgi variable.
> That said, perhaps there is a call to do so (I have to admit, I've never noticed
> another bug report about this, out of 10's of millions of sites.)
>
> So, I'm passing on your comment to new-httpd, for consideration by the rest of
> the coding community.
>
> Yours,
>
> Bill
>
>
> > On 14 Jun 2001 [EMAIL PROTECTED] wrote:
> >
> > > Synopsis: %2F in PATH_INFO
> > >
> > > State-Changed-From-To: open-closed
> > > State-Changed-By: wrowe
> > > State-Changed-When: Wed Jun 13 17:38:40 PDT 2001
> > > State-Changed-Why:
> > > Please read this section of RFC2616 _very_ carefully.
> > >
> > > Characters other than those in the "reserved" and "unsafe" sets (see
> > > RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
> > >
> > > For example, the following three URIs are equivalent:
> > >
> > > http://abc.com:80/~smith/home.html
> > > http://ABC.com/%7Esmith/home.html
> > > http://ABC.com:/%7esmith/home.html
> > >
> > > According to this standard, %2F is _not_ equivilant to '/'.
> > > In fact, the '/' is defined a uri resource segment seperator
> > > while %2F remains entirely undefined. It's a '/' that is
> > > defined as 'not a path seperator'.
> > >
> > > That meaning is bogus to httpd, so it is disallowed.
> > >
> > > This behavior, for security reasons, is by design.
>
>
