> 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
