Closed
Bug 52920
Opened 24 years ago
Closed 23 years ago
frame can't access sibling if parent frame is in another domain
Categories
(Core :: Security, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: bwp6, Assigned: security-bugs)
References
()
Details
Attachments
(3 files, 2 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
security-bugs
:
review+
brendan
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i586; en-US; m18) Gecko/20000915 BuildID: 2000091521 when I select the province from the first drop down list, the second drop down list is supposed to change to reflect the cities in the selected province. The problem is the list for cities does not change. Reproducible: Always Steps to Reproduce: 1.go to the URL 2.select a different provice 3.Notice that the city list does not change Actual Results: The list of cities did not chage according to the province selected Expected Results: A different list of cities should have appeared when the province was selected From what I noticed the page has frames eventhough it is not visible.
Comment 1•24 years ago
|
||
Confirmed on Linux 2000-09-16-06.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
Confirmed using Mozilla tip builds 2000-09-21 on WinNT, Linux. Changing OS to "All". On each platform, I get this error in the console: JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "http://cantire2.canadiantire.ca/cgi-bin/storeloc/provfind2.pl Line: 22"] Is this a Security issue? Definitely not a JS Engine bug. Changing component to Security for further triage -
Assignee: rogerl → mstoltz
Component: Javascript Engine → Security: General
OS: Linux → All
QA Contact: pschwartau → czhang
Assignee | ||
Comment 4•24 years ago
|
||
Taking a look... The site is probably attempting to use cross-domain frame access.
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•24 years ago
|
||
I'm marking this Future. If anyone believes this is an rtm candidate, please re-nominate.
Target Milestone: --- → Future
Updated•24 years ago
|
QA Contact: czhang → junruh
Comment 6•24 years ago
|
||
If you wade through a few levels of frames, you get to http://www.canadiantire.ca/eflyer/e/store_search/topprovset2.html. topprovset2.html has three frames: - provcopy2.html, which is just some text, as "topright". - http://cantire2.canadiantire.ca/cgi-bin/storeloc/cityfind3.pl as "topleft" - http://cantire2.canadiantire.ca/cgi-bin/storeloc/provfind2.pl as "provs" ("provs" most likely stands for provinces.) If you select "BC" in the "provs" frame, JavaScript in that frame tries to do parent.topleft.location = 'http://cantire2.canadiantire.ca/cgi-bin/storeloc/cityfind3.pl?province=BC'; Mozilla isn't letting the frame access "parent.topleft" because the frameset's hostname isn't the same as the frame's hostname. IE and NS4x allow access to parent.topleft for setting parent.topleft.location, but not for looking at it. IE even gives full access to parent.topleft if parent.topleft and the "provs" frame are at the same hostname. (NS4x might too, I didn't try.) I think Mozilla's behavior is correct. It doesn't make sense to me that a frame would be able to futz with other frames, especially since the user is likely to trust at least one of the frames to have come from the original site. -> evangelism?
Comment 7•24 years ago
|
||
Comment 9•24 years ago
|
||
Changing summary from "page does not change according option selected" to "frame can't access sibling if parent frame is in another domain". Again, I don't think this is a bug.
Summary: page does not change according option selected → frame can't access sibling if parent frame is in another domain
Assignee | ||
Comment 11•24 years ago
|
||
Agreed. WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Comment 12•24 years ago
|
||
I sent an e-mail to feedback@canadiantire.ca describing the problem on http://www2.canadiantire.ca/eflyer/e/store_search/strsrch.html.
Reporter | ||
Comment 14•24 years ago
|
||
Great job on the research. From the comments written on 2000-11-02 11:31, I accessed the same page from a different location and it seemed to work. http://cantire2.canadiantire.ca/eflyer/e/store_search/strsrch.html My question is why does it matter if a frameset's hostname is different from the frame's hostname? Shouldn't it work regardless?
Comment 15•24 years ago
|
||
Bug 45099 (also wontfix) appears to be the same problem: a frame trying to access a sibling frame in the same domain where the frameset is in another domain.
![]() |
||
Comment 16•24 years ago
|
||
bwp6@netscape.net, the reason such accesses are blocked is that they can easily lead to security holes.
Comment 21•23 years ago
|
||
i agree that bug 93829 is a duplicate of this bug. still, it addresses a problem not reported so far: cross domain frame access should not be regarded as a security issue if domain A is a subdomain of domain B (or vice versa). mozilla's current behaviour makes it impossible for clubs.domain.org to access secure.domain.org. there are numerous reasons why clubs.domain.org may need to do so, and there are no easy workarounds for websites that rely on frames and subdomains. please be aware that msie 5.x and opera 5.x support cross (sub)domain frame access. most users will not percieve mozilla's behaviour as a fix for a security flaw in any other major browser, but as a javascript bug -- so they'll rather return to msie. asking to reopen, to allow cross subdomain frame access and to include a security pref for cross domain frame access.
Assignee | ||
Comment 22•23 years ago
|
||
Reopening. I think we should reconsider this. Fixing 91215 would make this possible, and I've seen a few sites that are broken by this. There may be some spoofing concerns, but let's reopen this and discuss them.
Comment 23•23 years ago
|
||
the proposed workaround (Bug 93829 Additional Comments From Mitchell Stoltz 2001-08-06 16:42) fixes the problem with subdomains. still, i wouldn't overestimate the willingness of webmasters to change their code to comply with mozilla in order to fix a security hole that is wide open in any other browser. i have changed my mind though, and i'm now arguing that mozilla's javascript behaviour on this point is NOT FIXING ANY SECURITY ISSUE AT ALL. your concern (Bug 45099 Additional Comments From Boris Zbarsky 2001-05-02 11:53) is that allowing a frameset in domain A having a frame in it that loads a page in domain B (B like in Bank account login) would be an open door to spoofing. preventing "parent.frames.whatever.location.href=" from loading anything outside the parent domain DOES NOT fix this. to fix this, you would have to block: - framesets that *initially* load frames from different domains - any "<a href=... target=...>" within a frameset - any "<meta http-equiv="refresh" content="0; ..."> within a frameset - *any* use of php: <? $file = file("http://bugzilla.mozilla.org"); for ($i = 0; $i < count($file); $i++) echo $file[$i]; ?> displays the bugzilla site on my site. absolutely trivial to parse for "<form action=" and send all input to my site. my argument is that loading pages from other sites in a frameset on my site is a CORE HTML/JAVASCRIPT FUNCTIONALITY that should not be restricted in any way. there are thousands of reasons why site A may want to present a part of site B in their own frameset, there are thousands of non-annoying examples of this on the net. wanting to break this functionality (again: mozilla only breaks a tiny part of it) because domain A "can pretend to be domain B to the casual user" is a microsoft-style exploit of the whole debate about online security. mozilla will never be able to protect a user who doesn't look at the *location bar*. finally, there is an easy workaround if you don't wan't your page being framed: <script language=javascript> if (top.frames.length > 0) top.location.href=self.location; </script> please reconsider. this is not only a technical issue, but also a political one. blocking a functionality like this for security reasons is affecting the SOCIAL REALITY of the net (which is based on cross domain content accessibility). if, for the very same security concern, cross domain "file()" was banned from php, almost all of my websites (rolux.org, textz.com etc.) would be instantly dead.
Assignee | ||
Comment 24•23 years ago
|
||
Well, that's why I reopened it, to hear comment on potential vulnerability. Sebastian, I tend to agree with you that there's no loss of security in allowing cross-domain access to parent.frames. So as soon as I've got the technical issues worked out, I'll make the change.
Status: REOPENED → ASSIGNED
Priority: P3 → P2
Target Milestone: Future → mozilla0.9.4
Assignee | ||
Comment 28•23 years ago
|
||
Upping priority - I've seen 4 or 5 sites which are broken because of this bug.
Priority: P2 → P1
Assignee | ||
Comment 29•23 years ago
|
||
time marches on. Retargeting to 0.9.6.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Assignee | ||
Comment 30•23 years ago
|
||
Moving the most time-critical bugs and minor security fixes to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Assignee | ||
Comment 31•23 years ago
|
||
This patch allows access to top.frames[1], for example. Accessing sibling frames by name is still broken, however. To allow that, we may have to give the type of the property as input to the security check (eg. allow access to all properties of the window object of type Window).
Comment 32•23 years ago
|
||
Comment 33•23 years ago
|
||
Assignee | ||
Comment 34•23 years ago
|
||
Attachment #58753 -
Attachment is obsolete: true
Attachment #59657 -
Attachment is obsolete: true
Assignee | ||
Comment 35•23 years ago
|
||
Comment on attachment 60285 [details] [diff] [review] Fix that actually has a chance of working. r=mstoltz on jst's patch.
Attachment #60285 -
Flags: review+
Comment 36•23 years ago
|
||
Comment on attachment 60285 [details] [diff] [review] Fix that actually has a chance of working. One uber-nit: use window.frames[n] instead of window.frames.n in comments and pseudo-code for best JS effect. The prefs changes look ok too. /be
Attachment #60285 -
Flags: superreview+
Assignee | ||
Comment 37•23 years ago
|
||
Fixed. Bindu, use warp/u/mstoltz/bugs/52920.html as your testcase rather than the one attached to the bug. Try the URL in the URL field above as well.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 39•23 years ago
|
||
Verified on 2001-01-29-03 build on WinNT Above URL loads and functions properly.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•