1386088 - Attachment view <iframe> doesn't always inherit the parent page's cookies.

Status: NEW

(bugzilla.mozilla.org :: General, defect)

Description

[:Atoll]

I encountered a bug a long time ago (in Chrome) that required me to logout and log back in to BMO to get attachments to display correctly (see attached).

It turns out that the <iframe> used to display attachments explicitly prohibits cookie-sharing, which means that the current model of framing attachments is invalid:

<iframe id="viewFrame" src="attachment.cgi?id=8892229" sandbox>

The 'sandbox' attribute has no values, which means that (among other restrictions) the attachment is loaded in a subprocess with no access to the auth cookies of the parent process.

This eventually results in not being able to view private attachments sometimes. I'm not sure why it's inconsistent, but maybe I just don't view enough attachments, or maybe Chrome is doing A/B testing.

Comment 1

[:Atoll]

Attachment: Screen Shot 2017-07-31 at 17.03.16.png

The yellow arrow notes that the iframe isn't logged in, even though the parent is.

The network inspector confirms that auth cookies were not sent with the <iframe>'s request.

The 'allow-scripts' (and fonts) recommendation is incorrect: BMO's 401-unauth page includes scripts and fonts, but the problem *for this bug* is that we served the 401-unauth page, not that it's invalid with the sandbox.

Comment 2

[:Atoll]

I confirmed that sandbox="allow-same-origin" fixes the auth-inheritance issue using mitmproxy -s mitm_bz.py:

def response(flow):
    if "bugzilla.mozilla.org" in flow.request.host:
        flow.response.content = flow.response.content.replace(b'sandbox', b'sandbox="allow-same-origin"')