The default bug view has changed. See this FAQ.

Cross frame scripting to nested iframe from same domain fails. Was working in earlier versions

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
DOM
P3
major
VERIFIED FIXED
12 years ago
11 years ago

People

(Reporter: Marcus Doemling, Assigned: mrbkap)

Tracking

(4 keywords)

Trunk
mozilla1.9alpha1
fixed1.8.0.4, regression, testcase, verified1.8.1
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.1 -
blocking1.8.0.2 -
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch], URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

There is a nested IFRAME with the following setup:

   Main page (domain A)
      -> IFRAME 1 (domain B)
          -> IFRAME 2 (domain A)

Cross frame scripting from the main page to IFRAME 2 should be possible but fails. In past Firefox versions this was possible and IFRAME 2 could be accessed e.g. via top.frames[0].frames[0]. This worked despite the fact that scripting from main to IFRAME 1 was not possible. Now trying to access the frames[0] property of top.frames[0] causes an exception. The exception caused is "Permission denied to set property Window.0". Note that it says "set" not "get".

Since both the main page and FRAME 2 are from the same domain they should be allowed to do cross scripting!

Reproducible: Always
(Reporter)

Updated

12 years ago
Version: unspecified → 1.5 Branch

Updated

12 years ago
Assignee: nobody → dveditz
Component: General → Security
Keywords: regression
Product: Firefox → Core
QA Contact: general → toolkit
Version: 1.5 Branch → 1.8 Branch
Could you attach a testcase or give an url that shows the bug?
(Reporter)

Comment 2

12 years ago
http://adinterax.com/test/firefox1.5_crossframe_main.phtml

Updated

12 years ago
Keywords: testcase

Comment 3

12 years ago
Similar problem with cross frame scripting with FF 1.5

Frameset set hosted on client's machine, content frames from our server.

FRAMESET (domain A)
 - FRAME 1 (domain B)
 - FRAME 2 (domain B)

Communication between FRAME 1 and FRAME 2 now reports "Permission denied to set property Window.0" , worked in previous firefox versions where frame 1 and frame 2 had same document.domain .

Comment 4

12 years ago
Hello All

We have found this problem in FireFox 1.5 (rather our customers have submitted it).

Same problem (as described earlier) appears in frameset:
If the frameset is in domain.one and frames are in domain.two an attempt to access frame1 from frame2 (and any other combination) will generate - Error: uncaught exception: Permission denied to set property Window.X. (You can test it at http://www.spellchecker.net/files/constantcontact/ - just click any "try" button and open JavaScript console to review the error – only in FireFox 1.5 – no exception in any previous versions)

It looks like the problem is in frames collection of window. It seems that in IE, Safari and all previous versions of Mozilla this collection is some kind of "public": attempt to access to other properties of the parent window generate an "access denied", but access to frames collocation always success.

It seems that the same problem was already happens when Netscape released version 4.5 of their browser – that version have same problem as described above and this problem was fixed very soon in version 4.51.

The bug was reproduced on Windows/Linux/Macintosh, - I assume it exists on all platforms.

So I have some questions to developers: is this bug has enough importance? Is there plans to fix it soon or we need update our application to separately support this version of FireFox browser (not a good idea, IMHO)? What are the plans for further versions of FireFox browser  - do these versions will have a cross-domain/cross-frame navigation ability or it will be disabled as in version 1.5?

Sincerely
---
Andrew Zhuravok
SpellChecker.net
AOL: azhuravok
ICQ: 18688386

Updated

12 years ago
Flags: blocking1.8.0.1?
This is clearly a bug and a regression, but I'm not sure it rises to the level of 1.8.0.1 blocker.
Assignee: dveditz → jst
Status: UNCONFIRMED → NEW
Component: Security → DOM
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.8.1+
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
blocking 1.8.0.2 denied, not a regression, no trunk-baked patch.

We can reconsider if a safe patch appears.
Flags: blocking1.8.0.2? → blocking1.8.0.2-
Flags: blocking1.8.0.3?
(Reporter)

Comment 7

11 years ago
I found another clue for this bug. When accessing the nested iframe using the iframe name instead of the index the access works! With the following setup:

   Main page (domain A)
      -> IFRAME 1 (domain B)
         -> IFRAME 2 (domain A)

The access from IFrame 1 to IFrame 2 works when using the name of IFrame2,
the exception occurs when using the IFrame index (window.frames[0]). The access from the main page to IFrame 1 can be done either way.

Here is another test page showing both IFrame access versions:

http://adinterax.com/test/firefox1.5_crossframe_main_v2.phtml

Hope this will help somebody to find the cause and fix it.

Comment 8

11 years ago
jst: Is this something you plan on fixing for 1.8.0.3?  Is it something you think we should try to fix?  Any suggestion on who might be able to help?
(Assignee)

Comment 9

11 years ago
This is easy to fix.
Priority: -- → P3
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
Version: 1.8 Branch → Trunk
(Assignee)

Comment 10

11 years ago
Created attachment 216086 [details] [diff] [review]
Fix

Compare this code to the code that resolves frame names as opposed to indices.
Assignee: jst → mrbkap
Status: NEW → ASSIGNED
Attachment #216086 - Flags: superreview?(jst)
Attachment #216086 - Flags: review?(jst)
Comment on attachment 216086 [details] [diff] [review]
Fix

Yeah, this is what we want. r+sr=jst
Attachment #216086 - Flags: superreview?(jst)
Attachment #216086 - Flags: superreview+
Attachment #216086 - Flags: review?(jst)
Attachment #216086 - Flags: review+
(Assignee)

Comment 12

11 years ago
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Flags: blocking1.8.0.3? → blocking1.8.0.3+
(Assignee)

Updated

11 years ago
Attachment #216086 - Flags: approval1.8.0.3?

Comment 13

11 years ago
mrbkap, jst: Can you guys comment on the risk associated with this patch?  Also, it'd be good to land this on the MOZILLA_1_8_BRANCH to maximize bake time before we take this on the MOZILLA_1_8_0_BRANCH.  Thanks!
(Assignee)

Updated

11 years ago
Attachment #216086 - Flags: approval-branch-1.8.1?(jst)
(Assignee)

Comment 14

11 years ago
(In reply to comment #13)
> mrbkap, jst: Can you guys comment on the risk associated with this patch? 

This patch should be extremely safe. It uses pre-existing code to disable overly cautious security checks during a call into the JS engine. There is similar code a couple of lines down (that also can act as a workaround for this bug). This doesn't open any security holes, since the call into the JS engine will not run any user code, and we're defining a known property with a known value.

Updated

11 years ago
Attachment #216086 - Flags: approval-branch-1.8.1?(jst) → approval-branch-1.8.1+
(Assignee)

Comment 15

11 years ago
Fix checked into the 1.8 branch.
Keywords: fixed1.8.1
Comment on attachment 216086 [details] [diff] [review]
Fix

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #216086 - Flags: approval1.8.0.3? → approval1.8.0.3+
(Assignee)

Comment 17

11 years ago
Checked into the 1.8.0 branch.

By the way, thanks for the great testcases, Marcus.
Keywords: fixed1.8.0.3

Comment 18

11 years ago
verified 1.8 20061010 1.9 20061011 windows/linux on both testcases.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
You need to log in before you can comment on or make changes to this bug.