206990 - URL: "/../.." is removed in relative referencees above home dir

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[hans.albertsson]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4b) Gecko/20030510
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4b) Gecko/20030510

It seems Mozilla doesn't accept URLs containing the "/../../" construct.
The .. parts are simply removed before the url is used or presented.

I can find no indication in the specs that this is correct behaviour.

Furthermore, IE6 and Opera on W98 and W2K accept this construct fine.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
Mozilla looked in user admins homedir for directory/filen.ame

Expected Results:  
looked in dir two levels above useradmins homedir for directory/filen.ame

Comment 1

[Jo Hermans]

When I go to ftp://ftp.mozilla.org/../../pub/mozilla/nightly/latest/ I get the
same page as ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/ .

Do you really expect that you would be able to see the directories 'above' the
root-directory ? Wouldn't that be a security risk ?

Comment 2

[Jo Hermans]

It seems to be done at this location in the code :
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsURLHelper.cpp#242

Comment 3

[hans.albertsson]

Maybe one shouldn't ordinarily be allowed, by the FTP server, to go above one's
ftp-server-assigned  root dir, but the BROWSER shouldn't interfere by editing my
URL...

Comment 4

[benc]

WFM, Firebird 0.6 & mozilla 1.4b

Please give steps (typed in URL bar, HREF, etc.)

There might be some entry point or URL usage that I have not been testing where
this does not work.

To clarify the confusion in several comments below:
1- The URL should be parsed as described by the reporter.
2- The FTP client can attempt to use a higher level directory, but the server
can reject the request if the session is rooted.

Most anonyous servers are this way, so the ftp.mozilla.org example works as
expected, but the reported bug may still be valid.

Comment 5

[hans.albertsson]

The bug occurs when there's a link in a page that contains the "/../..".
So the steps are:

On an OK page, place a link ftp://[e-mail]/../../file.name
When you click on or place your mouse over this link, Mozilla removes the /../..
bit before displaying or using the link.

Comment 6

[benc]

-> NEW
This is related to bug 187868, which is about URL parsing in general. In most
cases, we normalize URLs, but not in URL bar. That bug is about URL parsing, so
I'd like to keep this bug FTP specific.

The RFC spec says that ".." should only have special meaning in a relative URL.

ftp://user@server/../file should tell the FTP module to get "../file". However,
normalization parses the "../file, and because "/.." is higher than the top
level, the ".." is discarded. 

This occurs because treating relative URL's like this is acceptable:

http://www.ics.uci.edu/%7Efielding/url/test1.html

"Parsers must be careful in handling the case where there are more relative path
".." segments than there are hierarchical levels in the base URL's path. Note
that the ".." syntax cannot be used to change the site component of a URL."

There are several examples below this comment in that page.

This bug inspired the research that created bug 207298, where you can get a
better understanding how the general behavior works this way for a reason (not
to say this does not need to be fixed).

Comment 7

[tenthumbs]

I have to ask which rfc you're referring to? This is a ftp URI so it has 
different rules.

Comment 8

[Andreas Otte]

Making dependend on bug 122133 which aims at handling directory coalesing the
same way in relative urls as it is done in absolute urls. The patch on that bug
should fix this bug too.

Comment 9

[Andreas Otte]

This should be fixed with the checkin for bug 207298

Comment 10

[benc]

V/fixed.
Mac OS X, 1.6b, 20040111