1580607 - Logout from Office365 causes download dialog box

Status: RESOLVED DUPLICATE of bug 1591932

(Core :: DOM: Security, defect, P2)

Description

[Pablo]

Attachment: download.png

Description:
When using office365 tools such as word or excel online, If i logout, i get a dialog download box on screen.

Steps to reproduce:

• Go to https://office.live.com/start/Word.aspx?omkt=en-US&auth=1&nf=1
• Login to office 365
• Open any document you have or create a new one.
• Return to the first tab and Logout from Office365

Actual Result:
the site logs out but it gives a dialog download box on screen. Application/x-unkown-content-type

Expected Result:
No download dialog box should appear.

Tested on:
Windows 10 64bit:
Firefox release 69: Issue is not reproducible
Firefox beta: 70.0b5: Reproducible
firefox Nightly 71.0a1: Reproducible

Mac 10.14 64bit:
Firefox release 69: Issue is not reproducible
Firefox beta: 70.0b5: Reproducible
firefox Nightly 71.0a1: Reproducible

ubuntu 18.04 64bit:
Firefox release 69: Issue is not reproducible
Firefox beta: 70.0b5: Reproducible
firefox Nightly 71.0a1: Reproducible

Regression-Range
Will do mozregression soon since we are still running nightly.

Comment 1

[Pablo]

mozregression:

build_date: 2019-08-01
build_url: https://archive.mozilla.org/pub/firefox/nightly/2019/08/2019-08-01-21-42-27-mozilla-central/firefox-70.0a1.en-US.win64.zip
changeset: 5f8aeb02af2259acfceed9e1abe987849fbb67ca
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0124f06562982dce60b820d95aad23afd5cec90&tochange=5f8aeb02af2259acfceed9e1abe987849fbb67ca

Comment 2

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
Office365 is used widely enough that this probably needs addressing before the release of fx70

From the window in comment #1 and the fact that this is navigation that suddenly pops a download, it seems fairly certain that this was triggered by bug 1428473 (though I don't have an office365 account so can't test myself).

:sstreich, can you coordinate what to do here? I'm not sure what other browsers do, whether we can/should treat x-unknown-content-type separately, or whether we can get MS to fix this in time for 70 release.

Comment 3

[Sebastian Streich [:sstreich]]

Hey! So my guess here is that we're getting Content Send without a MIME Type but with XTCO-NoSniff enabled, which means that we should not assume a MIME. - Thats why we're showing X-Unknown.
Our behavior is currently in line with safari and edge. Chrome always defaults here to text/plain if possible - We could easily switch to chromes behaviour but afaik there still is discussion ongoing on how we should behave.

• Still this would mean at most we would render text/plain, which i assume is not what microsoft intended to do. So anyway we should reach out and ask them if they can provide a mime type for that page load.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Sebastian, maybe you can email the list we have with Microsoft. I'll send you the details to join it.

Comment 5

[Liviu Seplecan]

Issue can be reproduced in Mac OS X 10_14_6 using FF version nightly 71.0a1 from 24th of September.

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

Basti, where you able to get a hold of someone at Microsoft? Can they resolve the issue on their end? Alternatively we should think of other options to get that problem resolved.

Comment 7

[Daniel Veditz [:dveditz]]

Hard to believe Edge users are getting a download prompt on Office365 and no one at MS noticed. Are they serving different content to Edge? If so when you contact them perhaps one option is to send us the Edge content.

Comment 8

[Mike Taylor [:miketaylr]]

We should try outreach for sure, and another option is to write an intervention to add a content type, similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1582848.

Comment 9

[Ksenia Berezina [:ksenia]]

Attachment: Screen Shot 2019-09-26 at 4.48.31 PM.png

Comment 10

[Ksenia Berezina [:ksenia]]

Comment on attachment 9096705 [details]
Screen Shot 2019-09-26 at 4.48.31 PM.png

I can look into adding the intervention, though have trouble reproducing this with my office365 account following the steps from https://bugzilla.mozilla.org/show_bug.cgi?id=1580607#c0. Just want to make sure I follow the steps correctly. After creating a document I click on Word icon box which opens a new page and I logout from there. The download box is not triggered.

Comment 11

[Ksenia Berezina [:ksenia]]

Pablo, could you please provide more details on the last step Return to the first tab and Logout from Office365 ? Do you return to the first tab the same way as I described in comment 10 ?

Comment 12

[Pablo]

Hi Ksenia

The issue i belive is office365 specific, I saw your screenshot and the link says live.com ( https://office.live.com/ )
I used a regular free hotmail account to access and the *.live.com site is shown, and it does not open a brand new tab when i click on a saved document or create a new document.

So i think an office365 account is needed

• I log in here: https://office.live.com/start/Word.aspx?omkt=en-US&auth=1&nf=1
• I use Office365 login and password
• site loads, that is www.office.com (not live.com)
• from there, i can create a brand new document or select one of the previous saved ones from the recommended list.
• When i choose any of those 2 options > A brand new tab is opened (second tab)
• So i return to the first tab, and logout
• Then i get the download box.

I am attaching an image of the site i see when i log into that link using an office365 account

Comment 13

[Pablo]

Attachment: office0.jpg

Comment 14

[Ksenia Berezina [:ksenia]]

Thanks Pablo, I was able to reproduce it with office365 account and added an intervention in https://bugzilla.mozilla.org/show_bug.cgi?id=1584591

Comment 15

[Christoph Kerschbaumer [:ckerschb]]

FWIW, we are not going to ship XCTO for toplevel navigations within FF70, see Bug1585055, but will postpone to ship that security enhancement to FF71.

Assigning this bug to you basti so we don't forget about it - thank you!

Comment 16

[Pascal Chevrel:pascalc (PTO until April 26)]

Christoph, it is a but unclear to me what the status of this bug is with regards to 71. Is it fixed because of the intervention added in bug 1586188? Is it affected since we have dom.security.respect_document_nosniff set to true on beta? Can you shed some light on this please? Thanks!

Comment 17

[Christoph Kerschbaumer [:ckerschb]]

We talked about options and we are going to change things so that XCTO nosniff only blocks if there is an 'incorrect' mime type but not a missing mime type. In turn that change will render this bug as a 'WORKSFORME'.

Additional note when the XCTO will be prefed on:
FF 70 - disabled
FF 71 - currently enabled, but will be disabled
FF 72 - will be enabled with the carveout from above (not blocking for missing mime type)

Comment 18

[Sebastian Streich [:sstreich]]

Disabling Nosniff for 71 has been proposed for Uplift (Bug 1592651). :) Then 71 should not be affected anymore.
The Carveout for FF 72 Christoph mentioned is in Bug 1591932

Comment 19

[Christoph Kerschbaumer [:ckerschb]]

Please note that this security feature lives behind a pref and we are not going to ship in 71 either (see 1592651) - hence adding 'unaffected' for FF71.

Most likely we will ship in 72 with the carveouts added within Bug 1591932.

Comment 20

[Sebastian Streich [:sstreich]]

I'm marking this as a duplicate as we shipped the fix for this problem in Bug 1591932 :)

Comment 21

[Boris Zbarsky [:bzbarsky]]

So what was the Safari/Edge behavior on this particular testcase, and do we know why?