httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: workaround for encoded slashes (%2f)
Date Wed, 30 Oct 2002 22:43:12 GMT

> At 02:52 PM 10/30/2002, Roy T. Fielding wrote:
> >Your patch will simply let the %2F through, but then a later section
> >of code will translate them to / and we've opened a security hole
> >in the main server.  I'd rather move the rejection code to the
> >place where a decision has to be made (like the directory walk),
> >but I have no time to do it myself.  I think it is reasonable to
> >allow %2F under some circumstances, but only in content handlers
> >and only as part of path-info and not within the real directory
> >structure.
>
> That's the right idea... however it doesn't work.
>
> %2f is distinct from '/' - the rfc defines it as another character altogether.
You've lost me.

>
> Because loc_walk, dir_walk and family all deal in parsed URIs, and
> we have a 256 character code page, there is no way to disambiguate
> the %2f from a '/'.  If those families handled the unparsed URI we could
> do this with no problem, because they would be able to distinguish
> %2f from '/'.
>
> As long as we unparse first, we lose the distinction, and that's what
> opens up this flaw.
What exactly is the flaw with equating %2f with /?  Assume we equate %2f with /,
show me an attack that would otherwise fail.

>
> Of course we should find a way to accept %2f in the query string, but
> never in the path (including path_info.)

I think the last paragraph is a matter of opinion. There is nothing in RFC1616
preventing %2f in path_info. Some folks want it and I have no problem handing
them the rope so long as it does not compromise the security of the server in
the default case :-).

Bill


Mime
View raw message