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.frames. This worked despite the fact that scripting from main to IFRAME 1 was not possible. Now trying to access the frames property of top.frames 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
Could you attach a testcase or give an url that shows the bug?
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 .
This is clearly a bug and a regression, but I'm not sure it rises to the level of 18.104.22.168 blocker.
blocking 22.214.171.124 denied, not a regression, no trunk-baked patch. We can reconsider if a safe patch appears.
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). 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.
jst: Is this something you plan on fixing for 126.96.36.199? Is it something you think we should try to fix? Any suggestion on who might be able to help?
This is easy to fix.
Created attachment 216086 [details] [diff] [review] Fix Compare this code to the code that resolves frame names as opposed to indices.
Comment on attachment 216086 [details] [diff] [review] Fix Yeah, this is what we want. r+sr=jst
Fix checked into trunk.
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!
(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.
Fix checked into the 1.8 branch.
Comment on attachment 216086 [details] [diff] [review] Fix approved for 1.8.0 branch, a=dveditz for drivers
Checked into the 1.8.0 branch. By the way, thanks for the great testcases, Marcus.
verified 1.8 20061010 1.9 20061011 windows/linux on both testcases.