frame can't access sibling if parent frame is in another domain

VERIFIED FIXED in mozilla0.9.7

Status

()

defect
P1
normal
VERIFIED FIXED
19 years ago
13 years ago

People

(Reporter: bwp6, Assigned: security-bugs)

Tracking

Trunk
mozilla0.9.7
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

19 years ago
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

19 years ago
Confirmed on Linux 2000-09-16-06.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

19 years ago
Confirmed on Windows 98 M18 2000091308

Comment 3

19 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
Taking a look...
The site is probably attempting to use cross-domain frame access.
Status: NEW → ASSIGNED
I'm marking this Future. If anyone believes this is an rtm candidate, please
re-nominate.
Target Milestone: --- → Future

Updated

19 years ago
QA Contact: czhang → junruh

Comment 6

19 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 8

19 years ago
QA > ckritzer
QA Contact: junruh → ckritzer

Comment 9

18 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
Agreed. WONTFIX.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 13

18 years ago
Yep.  I concur.
Marking VERIFIED WONTFIX.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 14

18 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

18 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.
bwp6@netscape.net, the reason such accesses are blocked is that they can easily
lead to security holes.
*** Bug 82344 has been marked as a duplicate of this bug. ***

Comment 18

18 years ago
*** Bug 92847 has been marked as a duplicate of this bug. ***
*** Bug 92578 has been marked as a duplicate of this bug. ***
*** Bug 93829 has been marked as a duplicate of this bug. ***

Comment 21

18 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.
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.
Status: VERIFIED → REOPENED
Depends on: 91215
Resolution: WONTFIX → ---

Comment 23

18 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.
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

Comment 25

18 years ago
*** Bug 93179 has been marked as a duplicate of this bug. ***
Moving to 0.9.5.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
*** Bug 100859 has been marked as a duplicate of this bug. ***
Upping priority - I've seen 4 or 5 sites which are broken because of this bug.
Priority: P2 → P1
time marches on. Retargeting to 0.9.6.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Moving the most time-critical bugs and minor security fixes to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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).
Attachment #58753 - Attachment is obsolete: true
Attachment #59657 - Attachment is obsolete: true
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 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+
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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 38

18 years ago
I tried the site using the url above and works properly.  Thanks.

Comment 39

18 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.