248402 - https/ssl scripts cannot access DOM nodes in 'document' of same-domain non-ssl pages

Status: RESOLVED INCOMPLETE

(Core :: Security, defect)

Description

[Ken Johanson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616

If a non=SSL page opens a child window in the same host, but with https, the
child window cannot call opener.document.location.reload():

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
https://www.foo.com/user/login/index.jsp :: f :: line 19"  data: no]

It seems permissable that the ssl window should be able to make calls to the
http window, but not the other way around.

Reproducible: Always
Steps to Reproduce:
1. in a non-ssl page (on a https server), open a window in the same domain but
using SSL.
2. in the child window call javascript:opener.document.location.reload()
3. open the Javascript console to see the logged exception




In my use-case, a site design requires typically non-ssl access, but that the
login must be ssl based, and after login success the child window (a login
dialog) needs to cause the parent window url to reload, before closing,
mimicking the the built-in www-authenticate dialog.

Comment 1

[Ken Johanson]

Narrowed this down to calling reload() against window.document.location --
window.location does not exhibit problem.

Demo URL (https cert on this url is self-signed; accept):
http://www.breezeway.tv/public/mozilla248402.htm

Comment 2

[Ken Johanson]

This bug is more serious than my last summary of "narrowed this down to..."...
It is also true that the child-https window cannot submit form data in the
parent, non https window (even though the belong to the same http-host)

`opener.document.savedForm.submit()` throws: Error: uncaught exception:
Permission denied to get property HTMLDocument.savedForm

Where this is really biting me this that my attempt to build a window-based
login-form fails to call(submit) the form on the parent window which is saving
the users form data... the parent window is http, the child (login) window is
https...

Comment 3

[Ken Johanson]

Renaming summary and adding keywords

Comment 4

[timeless]

i believe we intentionally treat each port as distinct. because they easily can 
be.

Comment 5

[Ken Johanson]

That sounds rational, but too strict:
-Trust is considered to be domain-based (not port) in other sandbox/trust
technologies; e.g. java, and in x509-dns cert validation.
-Other browsers do allow https scripts to access http scripts in the same domain.
-Generally if a privileged (80) port can be compromised, then so could another
(443); and generally they are served by the same server-process anyway.

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Ken Johanson]

Problem still occurs on FF 1.0.7 and Deerpark 1.5

Comment 8

[Serge Gautherie (:sgautherie)]

Demo URL is now HTTP 404.

Comment 9

[Ken Johanson]

Updated URL: http://www.breezeway.tv/sys/public/mozilla248402.htm

Comment 10

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