Closed Bug 442015 Opened 12 years ago Closed 11 years ago

"Permission denied to get property Location.href" when accessing parent.location

Categories

(Core :: General, defect)

x86
Windows 2000
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: thg2, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

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

Given a frameset, which references a subframe that is located in the parent directory. The subframe file accesses parent.location by javascript.

It the frameset file is openen locally ("file:///") an error is thrown:
"Permission denied to get property Location.href"

Reproducible: Always

Steps to Reproduce:
1. Unzip attached testcase e.g. to C:\testcase
2. Open frameset.htm locally (e.g. file:///C:/testcase/dir/frameset.htm)
3. Open Error Console

Actual Results:  
"Permission denied to get property Location.href" is shown in Error Console


See also bug 440572
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → general
Depends on: 434522
This is by design, as things stand...
The bug only manifests if the files are loaded from the local filesystem.

To replicate, open the browser on the  MainDir/index.html  file.

For convenience, an  index.html  file in the top directory will redirect to the one that demos the bug.
This bug appears to be a manifestation of a more general problem concerning retrieving a property from a frame-parent if the source-file needs to be accessed by climbing upwards through the directory-tree.

The more elaborate testcase I attached shows that this bug and the phenomenon I originally reported as an extension to Bug 422120 both follow the same pattern.  It also clearly demonstrates the conditions that do and don't exercise the bug.
Some additional observations:
(1)  When the file is loaded via a redirect from the  index.html  file in the top directory (the one I included "for convenience"), the bug does not appear.  But if the  MainDir/index.html  file is loaded directly -- even in a neighboring tab in the same browser-window -- the bug does appear.

(2)  The Error Console message refers to  "Window.<nameOfVariable>" but the source of the subordinate IFRAME module refers to the variable as "parent.<etc...>"  I don't know what, if any, significance the transformation from "parent" to "Window" has, but this might be worth investigating...
(In reply to comment #2)
> Regression range is ... bug 402983.

bug 230606 actually. As Boris said, this is by design. It's unfortunate that there are legitimate cases that this interferes with, but there's no way to distinguish those from attack scenarios.

Load the files through a local web server and you won't hit these problems. Or if you start your app from the topmost directory then you should be able to access files beneath it, but you can't reach "up". If this is for your own personal use then you can change the value of security.fileuri.strict_origin_policy and revert to the older vulnerable behavior. Just becareful what other things you download and then load from your local filesystem.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Okay, thanks for the clarification and the pointer to the more detailed discussion.

Indeed, I hit this problem while developing and locally testing my site, which uses frames that communicate via scripts.

Now that I understand, then as long as the scripts work in the actual web-site and I know how to work around this "problem" while testing, I'm happy.
You need to log in before you can comment on or make changes to this bug.