Closed Bug 440572 Opened 16 years ago Closed 16 years ago

"Permission denied to get property Window.content" when referencing frame top.content from another website

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows Server 2003
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: alex, Assigned: jst)

References

()

Details

(4 keywords)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

If a child frame is loaded from a different server than the parent frame, and the child frame's name is "content", any attempt to access the frame top.content using JavaScript inside the child throws a security exception.  The specific error is "Permission denied to get property Window.content"

This problem is new to Firefox 3.0.  Previous versions do not exhibit this behaviour.


Reproducible: Always

Steps to Reproduce:
1. On web host 1, create a page containing a frameset with a frame named "content".  The source for this frame should be a page on web host 2.
2. On web host 2, create the page referred to by #1.  This page should contain JavaScript which accesses the variable top.content
3. Execute the JavaScript.

Actual Results:  
Security exception thrown: "Permission denied to get property Window.content"

Expected Results:  
Frame name is successfully resolved, and access granted.


I have set up a pair of web hosts to demonstrate this problem.  The following page creates a child frame called "content" and then proceeds to load a child frame from a different server.  The child frame attempts to reference the frame called top.content, and hits a security exception:

  http://www.varju.ca/ff3/broken.html

This exact same HTML works when the parent and child frames are on the same server:

  http://www.tnmc.ca/ff3/broken.html

Changing the HTML slightly to use the frame name "content1", while still loading the child frame from a remote server also works:

  http://www.varju.ca/ff3/works.html
Version: unspecified → 3.0 Branch
Regression range is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196739660&maxdate=1196740679
with two bugs in it, bug 406671 and bug 406692.
Blocks: 406671
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → general
Version: 3.0 Branch → Trunk
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
Similar issue if a frameset references an html file of the parent directory:
Open attached frameset.htm *locally* (not from a web server).
Error Console shows: "Error: Permission denied to get property Location.href"
Hi,

We'd like to know if the FF team considers this a bug or not as soon as possible so that we can take the necessary actions on our end to deal with this issue if it is not considered a bug and won't be fixed.

Thanks.
After reviewing this with jst and sicking, current behavior in Firefox 3 is the desired behavior.  Invalid.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
On more discussion, there's actually an issue specific to content here.  Reopening, and stay tuned.  
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Attached patch Fix.Splinter Review
This turned out to be a problem with the interaction between XOWs and a performance optimization that I landed for the nsWindowSH::GetProperty() hook. The reason this code works w/o this fix for names that are not also defined in our IDL interfaces for our window objects is that the XOW's resolve code ends up defining frames by their name on the XOWs and when the getProperty() hook call does nothing we simply use the values defined in the resolve hook, which is generally correct, but in the case where the name is also defined in our IDL, the IDL property ends up shadowing the already defined frame, which leads to security checks failing down the road.
Assignee: nobody → jst
Status: REOPENED → ASSIGNED
Attachment #326402 - Flags: superreview?(mrbkap)
Attachment #326402 - Flags: review?(mrbkap)
Johnny, is this something that should go in 1.9.0.1?
IMO it should indeed go into 1.9.0.1.
Flags: blocking1.9.0.1? → blocking1.9.0.1+
Wow.  Thanks for the snappy turn around!  
Comment on attachment 326402 [details] [diff] [review]
Fix.

Yeah, makes sense.
Attachment #326402 - Flags: superreview?(mrbkap)
Attachment #326402 - Flags: superreview+
Attachment #326402 - Flags: review?(mrbkap)
Attachment #326402 - Flags: review+
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1-
Flags: blocking1.9.0.1+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Attachment #326402 - Flags: approval1.9.0.1? → approval1.9.0.2?
Comment on attachment 326402 [details] [diff] [review]
Fix.

Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #326402 - Flags: approval1.9.0.2? → approval1.9.0.2+
Fix landed in CVS.
Keywords: fixed1.9.0.2
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008082105 GranParadiso/3.0.2pre. I verified using the test sites in Comment 0.
Landed before 1.9.1 branched
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.