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)

Product:
Core
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
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.