Closed Bug 64886 Opened 24 years ago Closed 23 years ago

[RFE] Ability to define friend URL for Same Origin security model

Categories

(Core :: Security, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED WONTFIX
Future

People

(Reporter: netdragon, Assigned: security-bugs)

Details

I guarantee this is already posted in some bug, but I couldn't find one so I
will take a stab.

The current security model doesn't allow pages with a different domain to access
each other through a frame, iframe, etc.

http://www.mozilla.org/projects/security/components/jssec.html#sameorigin

The thing is that there are times when a page is spread across multiple domains.
It would be nice if you could define a friend url - such as:

<friend url="http://www.foo.com/">

This would allow all pages at foo.com to be able to access this page through a
frame element.

<friend url="http://www.foo.com/somedir/">

This would allow all pages at www.foo.com/somedir to access this page through a
frame.

<friend url="http://www.foo.com/somedir/somefile.html">

Well you get the picture.

Alernatively, you could define many pages in the tag by seperating with a semicolon.

Basically, doing so would act as if a page was on the same domain.
Severity: normal → enhancement
How necessary is this? There are several ways around Same Origin. Setting
document.domain fulfills this function. The only sites that can't use
document.domain are sites that don't have a domain element in common. (if a site
really wanted to, it could set document.domain to ".com", and any page in .com
could interact with it) How many sites are there that want to be able to do this
and don't have a domain suffix in common? I think this is rare, and may not
justify adding a new HTML tag. Comments?
Document.domain is too limiting. For instance, if one has pages on both 
geocities.com and angelfire.com for the same site, and want to access one page 
through the frameset of the other, then document.domain wouldn't work. Besides, 
a page on geocities would have access to other people's pages on geocities 
using the current model. I think this defeats the whole purpose of having the 
security. Why someone would want to put a site on geocities or angelfire is 
beyond me, but there are other examples. For instance, company.bizland.com 
would have access to company2.bizland.com if document.domain was set to 
bizland.com.

Basically, I think this security model is severely limited.
As an alternative to using the friend tag, one could set document.friends. 
Document.friends would be an array. Each element of the array would define a 
new friend. You might argue that this is not part of the DOM, but then again is 
security?

document.friend[number].href=

I believe that
document.friend[number].href="somedomain.com/somedir/" should only allow files 
in that dir.
document.friend[number].href="somedomain.com/somedir/*" 
should allow all subdirectories.
document.friend[number].href="somedomain.com/some*" 
should allow all directories in the root dir that start with some, and their 
subdirectories.

If no domain is given then it means relative to the current dir.

I believe this would be much more powerful than document.domain.

Example:

www.geocities.com/~bodiddly/frames.html

Frame 1 = www.angelfire.com/~bodiddly2/a.html

for a.html to access the document containing its frame (_top I think), it would 
have to be declared as a friend. For frames.html to access a.html, a.html would 
have to declare frames.html as a friend.

Asking me why I would rather have this when document.domain works well is like 
asking me why I would want a 2000 Volvo S80 when my 1983 Volvo still works.
I realize that what you propose would be more powerful than document.domain.
What I am trying to determine is
1) How many people actually have a need for this level of flexibility. How many
sites would actually use it? To date, I've only seen one report of a site that
tried to do cross-frame communication between hosts with no common subdomain.
(some bank in Canada)

2) Would the added flexibility you propose be worth the added complexity it
would require? Remember, if we add this feature, it would only work on Netscape
6 browsers. The site will not work for anyone vissiting it with IE, Netscape 4,
etc. You and I know that other browsers don't matter ;) but this is the question
that 98% of website owners will ask. Result - no one will use your "friend" feature.

Sorry to be practical, but that's the case.
As far as I know, IE and Netscape 4 don't have this security model. I might be 
wrong, but I think that cross-frame communication between domains would work on 
IE and Netscape 4. Therefore, the programmer would need to sniff out whether it 
is Netscape 6 or Mozilla, and if so then use the friend javascript function. 
Otherwise they do nothing. Therefore, I don't think that this would stop it 
from working on other browsers. It is the same kind of thing as document.domain

Who would use this feature? I really don't know. We cannot guess about who will 
want this in the future. I can tell you though that if people want to do cross 
domain framing and Netscape 6 doesn't work, then they will be pretty angry all 
their work was for nothing. People have some pretty strange sites out there, so 
I would guess there are a reasonable amount of people doing this.

All I know is that it would be a good feature and definately is not an invalid 
bug. I think that maybe someone might be bored and pick this up in the future. 
As for whether I think it should be implemented right away: definately no - 
there are more important things to do.
See also bug 55137.
Mitchell: To give a real world use of this, in the test case management system
I'm intending to write, I'd like the test cases in one frame to be able to tell
the "controlling" frame what the result of the test was, so that the controlling
frame can manage all the results. This works fine on the current version, where
the driver code and the test cases reside on the same domain, but the version
I'm intending to write is supposed to be able to point to any test case on the
web. My controlling frame would want to make all the testcases be its "friends".

Similarly, the controlling frame will want to be able to hook in to the test
cases to add onload and onunload handlers, or to add a results submission form
using the DOM. For this, the test case needs a way to say that it trusts the
controlling frame.

Or alternatively, the user needs a way of promoting a frame/page to "godlike"
status (maybe after prompting from the webpage, as sometimes occurs in IE).

At the moment I am not sure how to implement all this.
Marking NEW to get off our Unconfirmed radar. You can continue the discussion there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Ability to define friend URL for Same Origin security model → [RFE] Ability to define friend URL for Same Origin security model
Ian,
  The best way to "promote" a page is to sign it. In your example, your testcase
management system could have a signed page. A signed page can be given access to
any page on the Web.

The problem with giving privileges to unsigned pages is that they are relatively
easy to spoof.

Aside from the fact that certificates can be expensive, why are people so
resistant to using signed scripts?
Status: NEW → ASSIGNED
I don't know how to do signed scripts. It sounds like something very 
complicated. When I think of signed scripts, I think of something you have to 
pay for. I bet that feeling is shared. I bet some people haven't even heard of 
them. This is something that would be harder to spoof than document.domain. For 
instance:

Site 1: www.geocities.com/~randym
Site 2: www.geocities.com/~michael
Site 3: florida.geocities.com/~michaelm
Site 3: www.angelfire.com/~blahdedah

With document.domain, randym site would have access to the michael site even 
without document.domain I believe. Easy spoofing there. With document.domain, 
randym would have access to michael even though it was meant for michaelm = 
easy spoofing. With my scheme, even if sites were on the same server, they 
might not have access to the same files because directories can be included in 
the friend url. On spoofing: if a site has a security leak where people can add 
scripts and gain access, that is the site's problem, not the browser's.
BTW: As long as signed scripts cost 1 cent I will not use them.
Also, signed scripts might work for Hixie in his copy of Bugzilla, but what 
about for the people that use his code to make their own Bugzilla?
Mitchell: Well, their cost is the main reason. However, I'm willing to 
investigate further -- there may be other blocking problems. What URI should I
start from if I want to do this?
Note: The only security risk with this is on bulletin. Then the person posting 
could put in the friend javascript or tag. I don't really see what this would 
accomplish since bulletin boards don't really have much to access on the 
document. But, bulletin boards could easily block this from occurring. Note: 
This tag has to be placed on EACH PAGE that wants to allow friends access - so 
one messageboard page having this (or one geocities page) would not give access 
to the rest of the messageboard (or geocities site).
Ian,
  Take a look at
http://www.mozilla.org/projects/security/components/jssec.html
and
http://www.mozilla.org/projects/security/components/signed-script-example.html

I think there are some CA's that sell single-user certificates for as low as $25
or so. The major drawback to signed scripts right now is that you have to sign
the whole HTML page along with the script, and load the page using the
jar:http://... protocol, which isn't compatible with NS4.7 or other browsers.
I'm working on re-enabling the old signed script syntax, where you can write the
html page normally and the signature can live in a separate file.

Brian,
> BTW: As long as signed scripts cost 1 cent I will not use them.
I'm sorry to hear that you don't want to pay for a certificate, but not
everything in life is free. Verifiable proof of your identity is a service which
costs money, just like the fee you pay to get a driver's license.

>It sounds like something very complicated.
It ain't. See the websites above.

>I bet some people haven't even heard of them.
Well, it's more likely they've heard of a feature that's been around since
Netscape 3.0 than one that has never existed.

>With document.domain, randym site would have access to the michael site even
>without document.domain I believe.

Yes, and this will continue to be the case. I'm aware of the Geocities problem,
and I proposed a preliminary idea for a solution in bug 55137. Even if we were
to adopt this friend URL scheme, all pages on GeoCities would continue to have
access to each other, because we couldn't possibly _require_ use of the friend
syntax. That would break about 80% of the pages on the Web. I don't think
Geocities is a big problem: the point of the same origin policy is to keep an
attacker from reading sensitive data out of another browser window that they
couldn't have accessed directly, such as my bank balance or a page behind a
corporate firewall. I don't think there's much limited-access information on
Geocities that an attacker couldn't just visit and see for himself.

> On spoofing: if a site has a security leak where people can add
> scripts and gain access, that is the site's problem, not the browser's.

You misunderstood me. I was talking about spoofing entire sites, with a rogue
DNS server for example, not adding scripts to a site. Without signing (or SSL),
there is no guarantee that the site you're connected to is the site you think it is.

Your "friend URL" scheme can't replace document.domain, because we can't abandon
an API used by many sites on the Web.

Future.
Target Milestone: --- → Future
See also bug 82006
Sorry for two posts. The bug 82006 is about loosening up the security model to 
allow eventlisteners to be added and contentDocument.location to be read on 
other documents.
err scratch the eventlistener, and change contentDocument.location to 
contentDocument.documentElement.URL 

Sorry for the confusion. Thats what happens when you have fried your brain on 
the computer.
I don't think we want to do this, for reasons described above. If we introduce a
new security API like this at this point, few people will use it, and if anyone
does use it, we'll be committed to supporting it indefinitely, and I'm not sure
we want to do that. There are other ways for sites to share data. I'm marking
this wontfix.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
QA Contact: ckritzer → bsharma
Marking verified as per above developer comments.
You need to log in before you can comment on or make changes to this bug.