document.domain becomes "null" when a data: URI page is returned to after using the back button




13 years ago
13 years ago


(Reporter: futurama, Assigned: dveditz)


1.8 Branch
Windows Server 2003

Firefox Tracking Flags

(Not tracked)





13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20060508 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20060508 Firefox/

(see this bug report's URL affected)

Returning to a data: URI page by pressing the back button causes the value of document.domain to become "null" for scripts running inside of the data: URI page.

I was unable to find a way to use this bug for cross-domain scripting or to read local directory structures and files. I'm not an expert on the browser security model however so I am going to restrict this bug to the security group for now. If it's not a security issue then the bug can be made public...

Reproducible: Always

Steps to Reproduce:

1) load an html page from a data URI. (display the value of document.domain)
2) navigate away from the page (the testcase page will do this automatically)
3) press back (the testcase page will do this automatically)
now the value of document.domain is "null".
Actual Results:  
document.domain is "null"

Expected Results:  
document.domain should be "" (on the test page at least)

testcase @
Assignee: nobody → dveditz
Component: General → Security: CAPS
Product: Firefox → Core
QA Contact: general → caps
Version: unspecified → 1.8 Branch

Comment 1

13 years ago
This sounds like what we intended, as the fix for an earlier security bug. data: urls are supposed to inherit the domain of the site that loaded them, but currently that's accomplished (in some cases) simply by using the previously loaded domain. That worked OK going forward in time, but when you went backwards in history you got the wrong permission.

In the short term we simply clear the domain and let data: have a null domain. Many data: pages will work fine. Those that need to communicate with other windows or sites won't, but they've been kind of divorced from their context anyway so that was an acceptable cost. This is a fail-safe overly restrictive stance for a fairly rare case in the real world.

In the longer term (moz1.9 -- Firefox 3) Boris fixed this by storing the correct domain along with the data: url in history. WFM on trunk. It was part of a larger re-vamping of how we handle data: urls that will not appear in Firefox 2.
Group: security
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.