Closed Bug 1580607 Opened 6 months ago Closed 3 months ago

Logout from Office365 causes download dialog box

Categories

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

Desktop
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 1591932
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox69 --- unaffected
firefox70 + disabled
firefox71 + disabled
firefox72 --- fixed

People

(Reporter: pablo.muir, Assigned: sstreich, NeedInfo)

References

Details

(Keywords: regression, Whiteboard: [domsecurity-active])

Attachments

(3 files)

Attached image 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:

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.

Has Regression Range: --- → yes
Keywords: regression

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

Component: General → DOM: Security
Flags: needinfo?(sstreich)
Product: Firefox → Core

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.
Flags: needinfo?(sstreich)

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

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

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.

Flags: needinfo?(sstreich)

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.

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

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 ?

Flags: needinfo?(pablo.muir)

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

Flags: needinfo?(pablo.muir)
Attached image office0.jpg
See Also: → 1584591

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

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!

Assignee: nobody → sstreich
Status: NEW → ASSIGNED
See Also: → 1585055
Whiteboard: [domsecurity-active]
Priority: -- → P2

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!

Flags: needinfo?(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)

Flags: needinfo?(ckerschb)

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

Depends on: 1591932
Flags: needinfo?(sstreich)

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.

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

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1591932

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

Flags: needinfo?(sstreich)
You need to log in before you can comment on or make changes to this bug.