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

Status: VERIFIED FIXED

(Core :: Security, defect, P1)

Description

[Theblueman]

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

[Cyril Bortolato]

Confirmed on Linux 2000-09-16-06.

Comment 2

[Ronald Tilby]

Confirmed on Windows 98 M18 2000091308

Comment 3

[Phil Schwartau]

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 -

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Taking a look...
The site is probably attempting to use cross-domain frame access.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

I'm marking this Future. If anyone believes this is an rtm candidate, please
re-nominate.

Comment 6

[Jesse Ruderman]

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

[Jesse Ruderman]

Attachment: testcase, sorta (requires a local webserver) (zipped)

Comment 8

[John Unruh]

QA > ckritzer

Comment 9

[Jesse Ruderman]

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.

Comment 10

[Jesse Ruderman]

Updating url.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Agreed. WONTFIX.

Comment 12

[Jesse Ruderman]

I sent an e-mail to [e-mail] describing the problem on 
http://www2.canadiantire.ca/eflyer/e/store_search/strsrch.html.

Comment 13

[ckritzer (gone)]

Yep.  I concur.
Marking VERIFIED WONTFIX.

Comment 14

[Theblueman]

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

[Jesse Ruderman]

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

[Boris Zbarsky [:bzbarsky]]

[e-mail], the reason such accesses are blocked is that they can easily
lead to security holes.

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 82344 has been marked as a duplicate of this bug. ***

Comment 18

[Jesse Ruderman]

*** Bug 92847 has been marked as a duplicate of this bug. ***

Comment 19

[Mitchell Stoltz (not reading bugmail)]

*** Bug 92578 has been marked as a duplicate of this bug. ***

Comment 20

[Boris Zbarsky [:bzbarsky]]

*** Bug 93829 has been marked as a duplicate of this bug. ***

Comment 21

[rolux]

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.

Comment 22

[Mitchell Stoltz (not reading bugmail)]

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

[rolux]

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.

Comment 24

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 25

[Colin Phillips]

*** Bug 93179 has been marked as a duplicate of this bug. ***

Comment 26

[Mitchell Stoltz (not reading bugmail)]

Moving to 0.9.5.

Comment 27

[Mitchell Stoltz (not reading bugmail)]

*** Bug 100859 has been marked as a duplicate of this bug. ***

Comment 28

[Mitchell Stoltz (not reading bugmail)]

Upping priority - I've seen 4 or 5 sites which are broken because of this bug.

Comment 29

[Mitchell Stoltz (not reading bugmail)]

time marches on. Retargeting to 0.9.6.

Comment 30

[Mitchell Stoltz (not reading bugmail)]

Moving the most time-critical bugs and minor security fixes to 0.9.7

Comment 31

[Mitchell Stoltz (not reading bugmail)]

Attachment: Patch - allow access to window.frames and window.<a numeric property>

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

[Johnny Stenback (:jst)]

Attachment: Complete fix that allows access to window.frames, window,<framename> and window.<frameindex>

Comment 33

[Johnny Stenback (:jst)]

Attachment: Fix that actually has a chance of working.

Comment 34

[Mitchell Stoltz (not reading bugmail)]

Attachment: Prefs changes necessary to make this fix work

Comment 35

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 60285 [details] [diff] [review]
Fix that actually has a chance of working.

r=mstoltz on jst's patch.

Comment 36

[Brendan Eich [:brendan]]

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

Comment 37

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 38

[Theblueman]

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

Comment 39

[bsharma]

Verified on 2001-01-29-03 build on WinNT

Above URL loads and functions properly.