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

NEW
Unassigned

Status

()

a year ago
a year ago

People

(Reporter: atoll, Unassigned)

Tracking

Production

Details

Attachments

(1 attachment)

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.
Created attachment 8892235 [details]
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.
See Also: → bug 1386090
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"')
You need to log in before you can comment on or make changes to this bug.