XML prettyprint displays blank page when using document.domain

RESOLVED FIXED in Firefox 50

Status

()

defect
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: raggonline1983, Assigned: bzbarsky)

Tracking

({regression, testcase})

30 Branch
mozilla50
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox50 fixed)

Details

()

Attachments

(5 attachments)

Posted file query.xml
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36

Steps to reproduce:

Preview XML is working fine in FF(FireFox) version 27 but does not work in
FF 30+

We have Preview XML link that display the XML and was working in version 27 and renders blank page in FF 30+ version. 


Actual results:

Blank XML page is rendered, but works in version FF 27 and below. Also, we get error in the console of the Firefox debugger, but Firebug doesn't report any issue:
Error : Permission denied to access property 'documentElement' - resizer.xml:19




Expected results:

XML page need to be rendered
Top of XML file:

HTTP/1.1 200 OK
Cache-Control: no-cache
Cache-Control: no-store
Date: Tue, 21 Apr 2015 12:24:21 GMT
Content-Length: 2690
Content-Type: text/xml; CHARSET=UTF-8
Expires: Thu, 01 Dec 1994 16:00:00 GMT
IgnorePortalRegisteredURL: 1
Also, the same works in all other browsers like IE, Chrome.
Group: core-security
Severity: normal → critical
Priority: -- → P1
Please provide a complete testcase. The query.xml file that you attached renders fine in Firefox 37 / 38, as an XML tree. Please do not change the priority and severity fields.
Severity: critical → normal
Flags: needinfo?(raggonline1983)
Priority: P1 → --
Summary: FIREFOX 30+ PREVIEW XML FROM QUERY SEARCH PAGE DISPLAYS NOTHING → Preview XML from query search page displays blank page
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151217072309

Works fine for me on the latest Nightly 46 - .xml file renders as an XML tree.

Closing this as incomplete due to inactivity. Feel free to reopen the bug if there's an updated testcase that still reproduces the issue.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(raggonline1983)
When we preview the XML it will be rendered in the next tab, even the Content Type is set to 'text/xml' browser is rendering it as html, but the style is set to 'display:none' causing the issue to display blank page. Hence, can you let us know what need to added that the browser display the xml as tree document nor plain text other setting it to display:none.

Thanks,
Raghavendra
Posted image Issue.jpg
Issue setting style to display:none
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
This bug won't be actionable without a concrete testcase that shows Firefox is doing something wrong. Please provide such a testcase. Screenshots don't really help.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → INCOMPLETE
Could you let me know the display:none is set when we are previewing the xml file that have attached, as blank page is getting displayed will help.
(In reply to Raghavendra from comment #9)
> Could you let me know the display:none is set when we are previewing the xml
> file that have attached, as blank page is getting displayed will help.

I don't know how/where you're displaying the XML file and so I don't know who/what is setting display:none. I'm fairly sure it's not Firefox. Again, we need a testcase in order to be able to help.
So, to tell below is the respone we receieve from the fiddler and not sure setting this display:none and html tag as shown in the image had uploaded at last:

HTTP/1.1 200 OK
Connection: close
Date: Wed, 23 Mar 2016 17:49:11 GMT
Content-Type: text/xml
Content-Disposition: inline; charset=utf-8; filename*=""
Content-Description: 
Set-Cookie: PS_TOKENEXPIRE=23_Mar_2016_17:49:11_GMT; domain=.us.oracle.com; path=/
Content-Length: 815

<?xml version="1.0" encoding="utf-8"?><ConnectedQuery name="QE_CON_QRY_LOCALE" preview="True" query_rows_limit="6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=""><QE_LOCALE_CON_QRY><A.QE_DATE>1978-02-17</A.QE_DATE><A.QE_DTTM>1993-02-14T19:11:30</A.QE_DTTM><A.QE_NUMBER>12345</A.QE_NUMBER></QE_LOCALE_CON_QRY><QE_LOCALE_CON_QRY><A.QE_DATE>1978-02-17</A.QE_DATE><A.QE_DTTM>1993-02-14T19:11:30</A.QE_DTTM><A.QE_NUMBER>12345</A.QE_NUMBER></QE_LOCALE_CON_QRY><QE_LOCALE_CON_QRY><A.QE_DATE>1987-11-11</A.QE_DATE><A.QE_DTTM>1993-02-14T13:10:30</A.QE_DTTM><A.QE_NUMBER>1234567890</A.QE_NUMBER></QE_LOCALE_CON_QRY><QE_LOCALE_CON_QRY><A.QE_DATE>1987-11-11</A.QE_DATE><A.QE_DTTM>1993-02-14T13:10:30</A.QE_DTTM><A.QE_NUMBER>1234567890</A.QE_NUMBER></QE_LOCALE_CON_QRY></ConnectedQuery>


And, we cannot provide the test case as its our internal application, hence uploaded the image. So, from the response we can see we are not setting any style and html tag as in the image uploaded. Hence, could you please check and let us know the html tag getting wrapped and setting dsiplay:none style, as its just plain xml file.
(In reply to Raghavendra from comment #11)
> So, to tell below is the respone we receieve from the fiddler and not sure
> setting this display:none and html tag as shown in the image had uploaded at
> last:
> 
> HTTP/1.1 200 OK
> Connection: close
> Date: Wed, 23 Mar 2016 17:49:11 GMT
> Content-Type: text/xml
> Content-Disposition: inline; charset=utf-8; filename*=""
> Content-Description: 
> Set-Cookie: PS_TOKENEXPIRE=23_Mar_2016_17:49:11_GMT; domain=.us.oracle.com;
> path=/
> Content-Length: 815
> 
> <?xml version="1.0" encoding="utf-8"?><ConnectedQuery
> name="QE_CON_QRY_LOCALE" preview="True" query_rows_limit="6"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:noNamespaceSchemaLocation=""><QE_LOCALE_CON_QRY><A.QE_DATE>1978-02-17</A.
> QE_DATE><A.QE_DTTM>1993-02-14T19:11:30</A.QE_DTTM><A.QE_NUMBER>12345</A.
> QE_NUMBER></QE_LOCALE_CON_QRY><QE_LOCALE_CON_QRY><A.QE_DATE>1978-02-17</A.
> QE_DATE><A.QE_DTTM>1993-02-14T19:11:30</A.QE_DTTM><A.QE_NUMBER>12345</A.
> QE_NUMBER></QE_LOCALE_CON_QRY><QE_LOCALE_CON_QRY><A.QE_DATE>1987-11-11</A.
> QE_DATE><A.QE_DTTM>1993-02-14T13:10:30</A.QE_DTTM><A.QE_NUMBER>1234567890</A.
> QE_NUMBER></QE_LOCALE_CON_QRY><QE_LOCALE_CON_QRY><A.QE_DATE>1987-11-11</A.
> QE_DATE><A.QE_DTTM>1993-02-14T13:10:30</A.QE_DTTM><A.QE_NUMBER>1234567890</A.
> QE_NUMBER></QE_LOCALE_CON_QRY></ConnectedQuery>

Here's a php file that produces almost identical output:

http://gijsk.com/mozilla/testcases/test-xml.php

It does not end up with display: none in it or any other messing about, and seems to work fine.

> And, we cannot provide the test case as its our internal application, hence
> uploaded the image. So, from the response we can see we are not setting any
> style and html tag as in the image uploaded. Hence, could you please check
> and let us know the html tag getting wrapped and setting dsiplay:none style,
> as its just plain xml file.

Well, you'll need to either provide access to the application using restricted/test credentials, or extract a workable testcase that reproduces the problem outside of the application. I have already said I cannot see any code in Firefox's XML preview code that would manipulate the XML like this under any circumstances. Without a way to reproduce, I have to assume that your application or an add-on you have installed manipulates the result of the request in some way.
I debugged it further and could see we are using window.open() to preview this xml file as below and is seems to be having problem:

window.open('http://test.com:8000/psc/ps/view/pQzUdYlA8vB_vXBC8LpvqS_GUlVs26VpgLFv9u1vkgio+bojP8M0Zg748D+ZuKnQ+XNGnomncILZP408Thsm5u5aDybWYUSyFg==/query.xml','','');
(In reply to Raghavendra from comment #13)
> I debugged it further and could see we are using window.open() to preview
> this xml file as below and is seems to be having problem:
> 
> window.open('http://test.com:8000/psc/ps/view/
> pQzUdYlA8vB_vXBC8LpvqS_GUlVs26VpgLFv9u1vkgio+bojP8M0Zg748D+ZuKnQ+XNGnomncILZP
> 408Thsm5u5aDybWYUSyFg==/query.xml','','');

Opening http://gijsk.com/

and then running

window.open('http://gijsk.com/mozilla/testcases/test-xml.php', '', '');

(turn off the popup blocker as well, of course)

still doesn't reproduce this problem. It sounds like your web application might be using the return value of window.open() and manipulating it somehow.
We got confirmation from our development team that CQ generated XML via authentication domain .us.oracle.com then this issue occurs as shown below i.e Set-Cookie and this may be some access issue, when inspected the error occurs as in the attachment- PermissionError1.png in resize.xml. So, if we remove the token .us.oracle.com then there seems no issue and xml gets rendered properly.  

HTTP/1.1 200 OK
 Connection: close
 Date: Wed, 23 Mar 2016 17:49:11 GMT
 Content-Type: text/xml
 Content-Disposition: inline; charset=utf-8; filename*=""
 Content-Description: 
 Set-Cookie: PS_TOKENEXPIRE=23_Mar_2016_17:49:11_GMT; domain=.us.oracle.com;
 path=/
 Content-Length: 815

Hence, could you please let us know if any security issue when we try to open with window.open() and domain set .us.oracle.com, or we need to enable any to get this error rectified to get it worked.

Thanks for your support!!!
(In reply to Raghavendra from comment #15)
> We got confirmation from our development team that CQ generated XML via
> authentication domain .us.oracle.com then this issue occurs as shown below
> i.e Set-Cookie and this may be some access issue, when inspected the error
> occurs as in the attachment- PermissionError1.png in resize.xml. So, if we
> remove the token .us.oracle.com then there seems no issue and xml gets
> rendered properly.  
> 
> HTTP/1.1 200 OK
>  Connection: close
>  Date: Wed, 23 Mar 2016 17:49:11 GMT
>  Content-Type: text/xml
>  Content-Disposition: inline; charset=utf-8; filename*=""
>  Content-Description: 
>  Set-Cookie: PS_TOKENEXPIRE=23_Mar_2016_17:49:11_GMT; domain=.us.oracle.com;
>  path=/
>  Content-Length: 815
> 
> Hence, could you please let us know if any security issue when we try to
> open with window.open() and domain set .us.oracle.com, or we need to enable
> any to get this error rectified to get it worked.

I don't know. Can't your development team create a simplified testcase that is publicly accessible?
Flags: needinfo?(raggonline1983)
1) modify hostname,domain,port in html files to match your environment.
2) Test class files are compiled using jdk1.7.
3) Run test server: java Test 8080
4) Using browser to access http://hostname.domainname:8080/1.html

BTW, this bug can not be repeated in FireFox 30+/iOS
BTW, I have mentioned, Apple OS the issue can not repeat. Using Windows!
(In reply to TONY YANG from comment #25)
> Your changes are not correct!
> You are using hostname.domain (foo.example.com) as domain name. Please
> change:
> 
> document.domain = "foo.somedomain.com"  TO:
> 
> document.domain = "somedomain.com"

The original code you sent uses "us.oracle.com", why would the subdomain or lack thereof make any difference?
yes, we use us.oracle.com as domainname and hostname is slc09ztw. For your case, the hostname is foo and domainname is somedomain.com. That's the correct way to reproduce the bug!
Blocks: 956382
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(yangj3848)
Flags: needinfo?(raggonline1983)
Resolution: INCOMPLETE → ---
Summary: Preview XML from query search page displays blank page → XML prettyprint displays blank page when using document.domain
Component: Untriaged → DOM: Security
Keywords: testcase
Product: Firefox → Core
Testcase in the URL field.

Boris, I don't suppose you have any idea why this is behaving differently on Windows compared with OS X? :-\
Flags: needinfo?(bzbarsky)
Not offhand...  That's quite surprising.

I assume that the document.domain sets in both the parent and the subframe there are in fact needed to reproduce the issue?  Is the eval() call as opposed to direct call of window.open() needed?  Is the open() call happening in a subframe needed?

Do you see any errors in the browser console?

I did check and the bug is not at first glance reproducible on Linux using that testcase either (in Firefox 47).  I do see the problem in Firefox 47 on Windows using browserstack...
Flags: needinfo?(bzbarsky)
(In reply to Boris Zbarsky [:bz] from comment #33)
> Not offhand...  That's quite surprising.
> 
> I assume that the document.domain sets in both the parent and the subframe
> there are in fact needed to reproduce the issue?  Is the eval() call as
> opposed to direct call of window.open() needed?  Is the open() call
> happening in a subframe needed?

No, I got confused when I reproduced with the convoluted java setup and then tried to get a live testcase on my own domain to make it easier for others to test, and initially couldn't reproduce on my mac. None of this is necessary.

I updated the testcase on my domain (same URL).

> Do you see any errors in the browser console?

Error: Permission denied to access property "document" XMLPrettyPrint.xml:36:11
Error: Permission denied to access property "documentElement" resizer.xml:19:1

Also reproduces on nightly on windows.
In case it matters, regression from bug 956382, I think, based on https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d275eebfae04&tochange=b80f7eece913 (no inbound/fx-team log because way too old, of course).
> None of this is necessary

Including the document.domain sets?  I have a hard time reconciling that with comment 35....

> Error: Permission denied to access property "document" XMLPrettyPrint.xml:36:11

So that indicates the XBL scope is not subsuming the content scope for some reason; the resizer thing is similar.  That is ... very odd.  Bobby, any idea what's going on here?

The windows-only bit makes me worry about this being an uninitialized variable somewhere or something bad like that.  :(
Flags: needinfo?(bobbyholley)
In general those kinds of permission errors indicate that the failure is at property access time, which should be the _only_ thing that considers document.domain. So not sure offhand.
Flags: needinfo?(bobbyholley)
OK, I think I understand what's going on here now; many thanks to Ryan for stepping through this stuff with me on Windows.

The sequence of events on Windows is as follows:

1)  The testcase sets document.domain.
2)  The testcase does a window.open.  This creates a new window, creates
    an about:blank document in it that inherits the testcase's principal
    (with document.domain set).
3)  nsGlobalWindow::SetInitialPrincipalToSubject calls shell->Initialize on the
    presshell, which kicks off frame construction.  We construct a scrollframe
    for the root element.  In ScrollFrameHelper::CreateAnonymousContent
    isResizable comes out true, so we create a <xul:resizer> element.
4)  The resizer binding has an <xbl:implementation>, so we go to install it
    and create an XBL scope for the new window's global.  This new scope gets
    an expanded principal for the principal that window has right now.
5)  The new document comes in and we land in nsGlobalWindow::WouldReuseInnerWindow. 
    This does an Equals() check, not an EqualsConsideringDomain() check (behavior
    change from bug 956382 here!) and hence decides we can reuse the inner.
6)  We change the principal on the inner window to the new document's principal
    but do NOT update the principal of the XBL scope as far as I can tell.

The status of those statements is: #1 and #2 are directly observed in the testcase, #2-5 are directly observed in a debugger.  #6 is source code observation, but I believe it's true.

I _think_ the upshot of all that is that the XBL principal ends up not subsuming the window's principal and property accesses in the XBL bindings fail.

On Mac/Linux, in step 3 isResizable comes out _false_ so we don't create a resizer, and don't end up creating the XBL scope until after step 6.  And at that point we have the right principal already.  The difference in behavior is because of the %XP_WIN bit at <https://hg.mozilla.org/mozilla-central/file/tip/layout/style/res/ua.css#l205>.

Bobby, It seems to me that step 5 above is possibly-wrong (should maybe use EqualsConsideringDomain) and step 6 is _definitely_ wrong.  For example, if the parent page didn't set domain but the child _did_ after loading, assuming the XBL scope got created before step 6 we would still end up with problems, right?

Flagging security-sensitive, because having the wrong principal (even if only differing in document.domain) in the XBL scope seems bad.

Raghavendra, thank you very much for sticking with this bug!
Group: dom-core-security
Flags: needinfo?(bobbyholley)
I'm glad the whole process is on track now.
Discussed with bz on IRC. I'm in favor of resetting the XBL scope when we reset the document, and not considering document.domain in WouldReuseInnerWindow.
Flags: needinfo?(bobbyholley)
Assignee: nobody → bzbarsky
Status: REOPENED → ASSIGNED
Comment on attachment 8773914 [details] [diff] [review]
When reusing the global of an initial about:blank for a new document, clear out its XBL scope when we change the global's principal

Review of attachment 8773914 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks.
Attachment #8773914 - Flags: review?(bobbyholley) → review+
Unhiding; Bobby and I don't think this is actually a security issue in practice.
Group: dom-core-security
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fcfd05dd7d14
When reusing the global of an initial about:blank for a new document, clear out its XBL scope when we change the global's principal.  r=bholley
https://hg.mozilla.org/mozilla-central/rev/fcfd05dd7d14
Status: ASSIGNED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.