Closed
Bug 406740
Opened 17 years ago
Closed 11 years ago
same origin policy is incorrectly applied to connection error page
Categories
(Firefox :: Security, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bart_vanhaute_, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071201 (Debian-1.8.1.11-1) Galeon/2.0.2 (Debian package 2.0.2-4) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071201 (Debian-1.8.1.11-1) Galeon/2.0.2 (Debian package 2.0.2-4) If a http request fails because for instance the web server is down, the user gets to see a "Unable to connect" error page. However I think the "same origin policy" is incorrectly applied to this error page. This page did not come from anywhere, so Javascript should be able to update the document.location.url property (for instance). Reproducible: Always Steps to Reproduce: 1. Create a page with a embedded frame. The main page should update the embedded frame through Javascript. 2. Open the page in the browser, and make sure the embedded frame is also opened. 3. Stop the web server that is server the embedded frame. 4. You now have the "Unable to connect" error page in the embedded frame. 5. Start the web server again. 6. Make sure the javascript again tries to open the embedded frame. Actual Results: Javascript is not allowed to open a page in the embedded frame, you get a "Permission denied to get HTMLDocument.location". Expected Results: Javascript should be allowed to open a page in the embedded frame. The same origin policy for error pages should probably still be restricted to update error pages that have resulted from requests that match the same origin policy. In Internet Explorer 7 a similar error page is shown. In that case however, Javascript is still able to update the document.location.url of the page.
Reporter | ||
Comment 1•17 years ago
|
||
This zip file contains three .html files that can be used to demonstrate the behaviour as described in the bug summary. Note: after testing again with Internet Explorer, it seems it doesn't work either... but it fails in a different way.
Comment 2•17 years ago
|
||
I think it should work if you use iframe.contentDocument.location = ... instead of iframe.contentDocument.location.href = ... Btw, you'll have to switch from contentDocument to contentWindow as well, now that bug 397828 is fixed. (That might fix your problem in IE as well.)
Reporter | ||
Comment 3•17 years ago
|
||
I changed the refresh.html as indicated in Comment #2, but I still get: "uncaught exception: Permission denied to get property HTMLDocument.location" So I can't even read the location property, adding the '.href' does not help.
Reporter | ||
Comment 4•17 years ago
|
||
Comment 5•17 years ago
|
||
My suggestion was to remove ".href", not add it. But it looks like the original testcase didn't use ".href"; I was just going by comment 0. Sorry for the confusion.
Resolving unconfirmed bugs older than a year with no activity as INCOMPLETE. Please reopen or file a new bug if you can still reproduce the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Comment 7•14 years ago
|
||
Please don't INCO security bugs due to lack of activity.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Updated•13 years ago
|
Version: unspecified → 2.0 Branch
Comment 8•11 years ago
|
||
Not able to reproduce on Latest Nightly 26. Marking as WFM
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 11 years ago
Resolution: --- → WORKSFORME
Comment 9•11 years ago
|
||
Matt, can you pound on error-page principals and make sure we have automated tests?
Flags: needinfo?(matt.woodrow)
Updated•11 years ago
|
Flags: needinfo?(matt.woodrow) → needinfo?(mwobensmith)
Comment 10•9 years ago
|
||
I don't see myself ever having an opportunity to fulfill the request in comment 9.
Flags: needinfo?(mwobensmith)
You need to log in
before you can comment on or make changes to this bug.
Description
•