1157127 - XML prettyprint displays blank page when using document.domain

Status: RESOLVED FIXED

(Core :: DOM: Security, defect)

Description

[Raghavendra]

Attachment: 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

Comment 1

[Raghavendra]

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

Comment 2

[Raghavendra]

Attachment: PermissionError-1.PNG

Comment 3

[Raghavendra]

Also, the same works in all other browsers like IE, Chrome.

Comment 4

[:Gijs (he/him)]

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.

Comment 5

[Simona Badau, Desktop QA]

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.

Comment 6

[Raghavendra]

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

Comment 7

[Raghavendra]

Attachment: Issue.jpg

Issue setting style to display:none

Comment 8

[:Gijs (he/him)]

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.

Comment 9

[Raghavendra]

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.

Comment 10

[:Gijs (he/him)]

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

Comment 11

[Raghavendra]

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.

Comment 12

[:Gijs (he/him)]

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

Comment 13

[Raghavendra]

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','','');

Comment 14

[:Gijs (he/him)]

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

Comment 15

[Raghavendra]

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!!!

Comment 16

[:Gijs (he/him)]

(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?

Comment 17

[TONY YANG]

Attachment: small test environment

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

Comment 18

[:Gijs (he/him)]

(In reply to TONY YANG from comment #17)
> Created attachment 8772813 [details]
> small test environment
> 
> 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

I don't understand. When I try to use this, all of the buttons in iframes open the XML file fine for me. I changed the us.oracle.com references to "foo.somedomain.com" and edited my hosts file to make that domain point to localhost.

Can you try to reproduce on Firefox 47, the current release? Can you host a testcase yourself that we can access directly over the internet?

Comment 19

[TONY YANG]

No, You have to use client->server mode. Do NOT use browser file mode to open html files. And also you MUST use hostname.domain mode to access the XML file.

Yes, this is tested with latest FireFox 47.x version. It has this issue but FireFox 47 on iOS do not have this issue.

Comment 20

[TONY YANG]

as this issue is relate  to docment.domain settings in html file. You can see

Comment 21

[TONY YANG]

It is easy to set it up at your side and I do not have an Internet ip.

Comment 22

[:Gijs (he/him)]

(In reply to TONY YANG from comment #19)
> No, You have to use client->server mode. Do NOT use browser file mode to
> open html files. And also you MUST use hostname.domain mode to access the
> XML file.

Yes, I already explained that I did this.

> Yes, this is tested with latest FireFox 47.x version. It has this issue but
> FireFox 47 on iOS do not have this issue.

But I can't reproduce the issue with your testcase, so I don't see how we can move forward.

Comment 23

[TONY YANG]

Please zip the files you changed and send to my email account.

Comment 24

[TONY YANG]

Any update?

Comment 25

[TONY YANG]

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"

Comment 26

[TONY YANG]

No I think you can see the problem :-)

Comment 27

[TONY YANG]

Now I think you can see the problem.

Comment 28

[TONY YANG]

Right?

Comment 29

[TONY YANG]

BTW, I have mentioned, Apple OS the issue can not repeat. Using Windows!

Comment 30

[:Gijs (he/him)]

(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?

Comment 31

[TONY YANG]

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!

Comment 32

[:Gijs (he/him)]

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? :-\

Comment 33

[Boris Zbarsky [: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...

Comment 34

[:Gijs (he/him)]

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

Comment 35

[:Gijs (he/him)]

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

Comment 36

[Boris Zbarsky [:bzbarsky]]

> 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.  :(

Comment 37

[Bobby Holley (:bholley)]

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.

Comment 38

[Boris Zbarsky [:bzbarsky]]

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!

Comment 39

[TONY YANG]

I'm glad the whole process is on track now.

Comment 40

[Bobby Holley (:bholley)]

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.

Comment 41

[Boris Zbarsky [:bzbarsky]]

Attachment: 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

Comment 42

[Bobby Holley (:bholley)]

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.

Comment 43

[Boris Zbarsky [:bzbarsky]]

Unhiding; Bobby and I don't think this is actually a security issue in practice.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
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

Comment 45

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fcfd05dd7d14