93120 - Default port and unspecified port should both be JavaScript accessible

Status: VERIFIED DUPLICATE of bug 125382

(Core :: Security, defect, P1)

Description

[Tim Powell]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010725
BuildID:    2001072503

When JavaScript attempts to access information from a page at another domain, it
is blocked with a security warning "Error: uncaught exception: Permission denied
to access property" This is expected and a Good Thing. However, minor
differences in a URL can cause this to fail and it shouldn't. For example,
JavaScript at http://mydomain.com/ is not allowed to access
http://mydomain.com:80/ Since 80 is the default http port, it can optionally be
included. In both cases, the page is loaded over port 80, so I don't see any
reason that JavaScript should restrict access between them--they are the same
domain. There is a similar problem with https://mydomain.com/ and
https://mydomain.com:443/ 443 is the default HTTPS port.

Reproducible: Always
Steps to Reproduce:
1. Create a frameset on an SSL site with 2 frames: topframe and bottomframe.
2. For the top frame, use a reference to a page like https://mydomain.com/
without the port.
3. For the bottom frame, use a reference to a page like http://mydomain.com:443/
with the port.
4. Include JavaScript in the bottom frame to try to get the
topframe.location.href or otherwise access code in the top frame. (or do the
reverse and put the code in the top frame and try to access the bottom frame.)

Actual Results:  The bottom frame JavaScript will not be able to get the
location of the top frame, even though they use the same domain and port (just
that it wasn't specified in the URL).

Expected Results:  The bottom frame's JavaScript should be able to determine the
top frame's location.

This same problem affects Netscape 4.x. IE 5 does not have this problem.

Note that I am only suggesting that this be changed when the domain matches and
the port is either the default port or unspecified. I am not suggesting that
Mozilla should otherwise loosen the security. I also realize that
http://mydomain.com/ and http://mydomain.com:81/ are entirely different and I
understand the logic of blocking access between them. It's just with unspecified
port and the default port that this needs to change.

I wasn't sure whether this should be in the DOM Level 0 or Security component. I
think it would work except for security blocking it, so I picked Security.

Comment 1

[Tim Powell]

Added keywords. I'll make a testcase, proposing for Mozilla 1.0, and marking
nsenterprise because this blocks a web app that works with IE.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Will do.

Comment 3

[Tim Powell]

See the URL for a testcase with HTTP on port 80 and with an unspecified port. 
Unfortunately I don't have a convenient server to host a testcase for HTTPS and 
port 443, but it's basically the same problem. 

Interestingly, I noticed that IE5 does not display the :80 for frame2 and 
frame3 in the testcase, even though those frames were loaded explicitly with 
the port.

Comment 4

[Tim Powell]

I should perhaps mention that when this bug is fixed, frame1, frame2, and 
frame3 should be able to access the URLs of each other. frame4 at a different 
domain should not be able to access the others, nor should they be able to 
access it.

In testing you should also verify that pages at the same domain name but using 
a different port are still denied access.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

The current behavior is incorrect, but fixing it would involve a performance hit
and would be pretty complicated. So, I'm marking it Future.

Comment 6

[Tim Powell]

A performance hit? Can't port 80 just always be added (or always be removed) 
before any comparisons are done? Does seem like that'd be a big deal, but I 
don't know the code enough to even know whereto begin. 

Also, in bug 95350 and bug 84776 there had to be code written to do the 
comparisons and handle the port correctly. Perhaps something similar needs to be 
done here?

Comment 7

[Jussi-Pekka Mantere]

Removing nsenterprise nomination.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

*** Bug 100859 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 105793 has been marked as a duplicate of this bug. ***

Comment 10

[Mitchell Stoltz (not reading bugmail)]

*** Bug 105694 has been marked as a duplicate of this bug. ***

Comment 11

[Mitchell Stoltz (not reading bugmail)]

*** Bug 113839 has been marked as a duplicate of this bug. ***

Comment 12

[Mitchell Stoltz (not reading bugmail)]

I just fixed this bug in the guise of bug 125382 - marking dup.

*** This bug has been marked as a duplicate of 125382 ***

Comment 13

[benc]

V/dupe.

btw, that bug has no patch, which I find really annoying.