406740 - same origin policy is incorrectly applied to connection error page

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect)

Description

[Bart Vanhaute]

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.

Comment 1

[Bart Vanhaute]

Attachment: test case with three pages: refresh.html main page, and two embedded frame pages

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

[Jesse Ruderman]

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.)

Comment 3

[Bart Vanhaute]

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.

Comment 4

[Bart Vanhaute]

Attachment: updated refresh.html with the suggested change of comment #2; to be used with the original embedded frame pages

Comment 5

[Jesse Ruderman]

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.

Comment 6

[u279076]

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.

Comment 7

[Jesse Ruderman]

Please don't INCO security bugs due to lack of activity.

Comment 8

[Mihai Morar, (:MihaiMorar)]

Not able to reproduce on Latest Nightly 26. Marking as WFM

Comment 9

[Jesse Ruderman]

Matt, can you pound on error-page principals and make sure we have automated tests?

Comment 10

[Matt Wobensmith [:mwobensmith][:matt:]]

I don't see myself ever having an opportunity to fulfill the request in comment 9.