39386 - nsCodebasePrincipal::SameOrigin too strict?

Status: VERIFIED WONTFIX

(Core :: Security, defect, P3)

Description

[Eric Pollmann]

I ran across this after finding a fix for bug 18501.  When the top frame of 
http://maps tries to update the location of the bottom frame, it is denied 
access to the bottom frame (self.parent.output_window).  It appears that access 
is denied on the basis that the two frames don't come from the same origin.

I traced this all the way down to:
nsCodebasePrincipal::SameOrigin
otherURI->GetHost returns "maps"
mURI->GetHost returns "maps.mcom.com"

The two hosts are PL_strcmp'd, then SameOrigin returns false saying these two 
frames aren't from the same host.  The error propagates all the way back up, and 
we get this non-informative error message on the console:

JavaScript error:
http://maps.mcom.com/topframe.html?r_loc=rtp line 37:

Script execution promptly terminates and the bottom frame is not updated.

Visiting http://maps.mcom.com works fine.

Comment 1

[John G. Myers]

Perhaps this could be considered a problem with the site's using absolute URL's?

Comment 2

[Mitchell Stoltz (not reading bugmail)]

This might be a problem with the way the caps code parses URL's for their 
"codebase." I'll check it out.

Comment 3

[Eric Pollmann]

Just to clarify, maps does use relative urls.  It seems to be getting the full 
domain from this:

 <BASE HREF="http://maps.mcom.com/">

At any rate, both top and bottom frames do come from the same machine, and the 
site works in both Nav and IE, so we should try to make it work in Seamonkey 
too!

Comment 4

[Jesse Ruderman]

It seems to me that mozilla is handling this correctly.  See bug 38862 for 
why.  What are ns4x and ie doing that allow the site to work?

Comment 5

[Mitchell Stoltz (not reading bugmail)]

SameOrigin checks to see if the protocol and host parts of an URL are the same. 
"maps" and "maps.mcom.com" don't compare as equal. This is a rare case - I can't 
think of anywhere outside a corporate intranet where you can refer to a server as 
simply "maps". If I type "yahoo," it gets extended to www.yahoo.com 
automatically, and this problem doesn't happen. To fix this, we'd have to 
establish that "maps" and "maps.mcom.com" are the same server, and I don't know 
of an efficient way to do that. Unless someone tells me otherwise, I don't think 
this problem is worth fixing. Marking WONTFIX.

Comment 6

[John Unruh]

Verified wontfix.