Mailing List Archive: Yet another URL-encoding bug

Yet another URL-encoding bug

Oct 13, 1995, 5:45 PM

Post #1 of 4 (284 views)

Yet another URL-encoding bug:
Redirect /wibble/ http://aserver/dir/

accessing http://myserver/wibble/heelo%25.html
generates a redirect to the Location: http://aserver/dir/heelo%.html

mod_alias.c was not re-escaping the incoming URL for the redirect.

I've uploaded 26_redirect2.0.8.14.patch to hyperreal.com in the
for_Apache_0.8.14 directory (for the lack of a better place).
This patch calls escape_uri to fix the problem.

I would rather use os_escape_path() to escape the URI, but unfortunately, that
would break on requests with a ':' - e.g.
http://myserver/wibble/hello:.html would return a Location: of
http://aserver/dir/./hello:.html

My preferred solution would be to change os_escape_path() so that it escapes
':' - that way it can be called on both relative and absolute paths.
I think that is much neater than having two routines.

I've also copied across the QNX port patch.

David.

26_redirect2.0.8.14.patch:
From: drtr@ast.cam.ac.uk (David Robinson)
Subject: Fix handling of % in Redirect command
Affects: mod_alias.c
ChangeLog: Escape the URI before generating the redirect.

27_qnx.0.8.14.patch:
Subject: QNX Port
Affects: alloc.c conf.h http_main.c rfc931.c util.c Configuration
Changelog: QNX Port
Comments: This patch also removes some redundant headers (not gratuitously,
they had to go on QNX anyway, and were already included in some other
local header). It also adds a debugging convenience; SIGSEGV and
SIGBUS are not caught when in debug mode (-X flag). This makes
running under some debuggers better.

Re: Yet another URL-encoding bug [ In reply to ]

ben at gonzo

Oct 13, 1995, 9:49 AM

Post #2 of 4 (282 views)

Permalink

>
> Yet another URL-encoding bug:
> Redirect /wibble/ http://aserver/dir/
>
> accessing http://myserver/wibble/heelo%25.html
> generates a redirect to the Location: http://aserver/dir/heelo%.html
>
> mod_alias.c was not re-escaping the incoming URL for the redirect.
>
> I've uploaded 26_redirect2.0.8.14.patch to hyperreal.com in the
> for_Apache_0.8.14 directory (for the lack of a better place).
> This patch calls escape_uri to fix the problem.
>
> I would rather use os_escape_path() to escape the URI, but unfortunately, that
> would break on requests with a ':' - e.g.
> http://myserver/wibble/hello:.html would return a Location: of
> http://aserver/dir/./hello:.html
>
> My preferred solution would be to change os_escape_path() so that it escapes
> ':' - that way it can be called on both relative and absolute paths.
> I think that is much neater than having two routines.

Well, there are (at least) two answers to this. Answer one is to escape the
new path _after_ you have assembled the parts (not strictly correct, I'll
agree). Answer two is that a ./ is _removed_ anyway (see RFC 1808), so
can't affect the path. Answer three (probably the best) is to tell
os_escape_path whether the path is absolute or relative, by prepending a '/',
i.e. you pass it "/hello:.html" to escape, then it doesn't put the ./ in.

BTW, the relevant bit of RFC 1808 is:

Step 6: The last segment of the base URL's path (anything
following the rightmost slash "/", or the entire path if no
slash is present) is removed and the embedded URL's path is
appended in its place. The following operations are
then applied, in order, to the new path:

a) All occurrences of "./", where "." is a complete path
segment, are removed.

>
> I've also copied across the QNX port patch.
>
> David.
>
> 26_redirect2.0.8.14.patch:
> From: drtr@ast.cam.ac.uk (David Robinson)
> Subject: Fix handling of % in Redirect command
> Affects: mod_alias.c
> ChangeLog: Escape the URI before generating the redirect.
>
> 27_qnx.0.8.14.patch:
> Subject: QNX Port
> Affects: alloc.c conf.h http_main.c rfc931.c util.c Configuration
> Changelog: QNX Port
> Comments: This patch also removes some redundant headers (not gratuitously,
> they had to go on QNX anyway, and were already included in some other
> local header). It also adds a debugging convenience; SIGSEGV and
> SIGBUS are not caught when in debug mode (-X flag). This makes
> running under some debuggers better.
>

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Re: Yet another URL-encoding bug [ In reply to ]

ben at gonzo

Oct 20, 1995, 9:45 AM

Post #3 of 4 (269 views)

Permalink

>
> Date: Fri, 13 Oct 1995 17:49:01 +0100 (BST)
> From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
> >> Yet another URL-encoding bug:
> >> Redirect /wibble/ http://aserver/dir/
> >>
> >> accessing http://myserver/wibble/heelo%25.html
> >> generates a redirect to the Location: http://aserver/dir/heelo%.html
> >>
> >> mod_alias.c was not re-escaping the incoming URL for the redirect.
> >>
> >> I've uploaded 26_redirect2.0.8.14.patch to hyperreal.com in the
> >> for_Apache_0.8.14 directory (for the lack of a better place).
> >> This patch calls escape_uri to fix the problem.
> >>
> >> I would rather use os_escape_path() to escape the URI, but unfortunately,
> >> would break on requests with a ':' - e.g.
> >> http://myserver/wibble/hello:.html would return a Location: of
> >> http://aserver/dir/./hello:.html
> >>
> >> My preferred solution would be to change os_escape_path() so that it escapes
> >> ':' - that way it can be called on both relative and absolute paths.
> >> I think that is much neater than having two routines.
> >
> >Well, there are (at least) two answers to this. Answer one is to escape the
> >new path _after_ you have assembled the parts (not strictly correct, I'll
> >agree).
>
> Then I'd have to decode the part the user provided so that it could be
> re-escaped properly...
>
> >Answer two is that a ./ is _removed_ anyway (see RFC 1808), so
> >can't affect the path.
>
> Actually not in this context; the client gets a complete URL, so it shouldn't
> do any ./removal.
>
> >Answer three (probably the best) is to tell
> >os_escape_path whether the path is absolute or relative, by prepending a '/',
> >i.e. you pass it "/hello:.html" to escape, then it doesn't put the ./ in.
>
> Yuk yuk yuk. 'alloc new copy of string with leading /; call routine,
> remove leading /'
>
> Encoding ':' would break nothing.

Its just that it offends my parsimonious nature; it adds characters where none
are needed. I'd rather add a flag to os_escape_path which switches off the
./ behaviour.

>
> David.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Re: Yet another URL-encoding bug [ In reply to ]

drtr at ast

Oct 20, 1995, 5:17 PM

Post #4 of 4 (273 views)

Permalink

Date: Fri, 13 Oct 1995 17:49:01 +0100 (BST)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
>> Yet another URL-encoding bug:
>> Redirect /wibble/ http://aserver/dir/
>>
>> accessing http://myserver/wibble/heelo%25.html
>> generates a redirect to the Location: http://aserver/dir/heelo%.html
>>
>> mod_alias.c was not re-escaping the incoming URL for the redirect.
>>
>> I've uploaded 26_redirect2.0.8.14.patch to hyperreal.com in the
>> for_Apache_0.8.14 directory (for the lack of a better place).
>> This patch calls escape_uri to fix the problem.
>>
>> I would rather use os_escape_path() to escape the URI, but unfortunately,
>> would break on requests with a ':' - e.g.
>> http://myserver/wibble/hello:.html would return a Location: of
>> http://aserver/dir/./hello:.html
>>
>> My preferred solution would be to change os_escape_path() so that it escapes
>> ':' - that way it can be called on both relative and absolute paths.
>> I think that is much neater than having two routines.
>
>Well, there are (at least) two answers to this. Answer one is to escape the
>new path _after_ you have assembled the parts (not strictly correct, I'll
>agree).

Then I'd have to decode the part the user provided so that it could be
re-escaped properly...

>Answer two is that a ./ is _removed_ anyway (see RFC 1808), so
>can't affect the path.

Actually not in this context; the client gets a complete URL, so it shouldn't
do any ./removal.

>Answer three (probably the best) is to tell
>os_escape_path whether the path is absolute or relative, by prepending a '/',
>i.e. you pass it "/hello:.html" to escape, then it doesn't put the ./ in.

Yuk yuk yuk. 'alloc new copy of string with leading /; call routine,
remove leading /'

Encoding ':' would break nothing.

David.