Ignoring "Content-Disposition: attachment" for plugins leads to XSS hazards

NEW
Assigned to

Status

()

defect
P5
normal
12 years ago
a month ago

People

(Reporter: dveditz, Assigned: johns)

Tracking

({sec-moderate})

Trunk
Points:
---
Bug Flags:
wanted1.9.2 +
blocking1.9.1 -
wanted1.9.1 +
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate])

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
security@mozilla.org received the following from Yahoo:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[This note deals with an unpublished security flaw, if not in
Mozilla software then in someone else's software, so thoughtful
handling is appreciated.]

We noticed that FF (and some other browsers) ignore the
Content-Disposition header when making a request for a page
element (as opposed to populating a fresh document or
(i)frame).

For example, given a URL that returns a Flash object with a
Content-Disposition: attachment HTTP header, clicking on this
URL or using this URL as the src attribute of an (i)frame
triggers the download dialog, but using this URL within an
embed segment to load a Flash movie loads the content in the
browser rather than triggering the download dialog.  (Same is
true of images and presumably other content.)

Two questions:

  a) is this intentional and, if so, what is the rationale? [1]

  b) is there any mechanism for the server to tell FF that it
     must not render the response?

Since this behavior isn't unique to FF and user's don't
upgrade that quickly, we're taking a different approach,
but any insight you can provide would be quite helpful.

thanks!
Scott

[1] This behavior differs from IE (not that it's the paragon
    of secure behavior, mind you) and we did not find any
    relevant open or closed bugs discussing this exact topic
    (closest was 355332).

    Consider the case of a website that hosts user-supplied
    files, wants to allow authenticated users to download those
    files, but doesn't want those files rendered within its own
    domain (e.g., because they might introduce XSS flaws).
    We were hoping to use Content-Disposition: attachment for
    this as it allows us to use existing authentication
    mechanisms and is thus much simpler than redirecting to
    another domain (e.g., dotted-quad IP addr) with an alternate
    authentication mechanism (e.g., limited-duration signed
    URLs)
Assignee: cbiesinger → nobody
Component: Networking: HTTP → File Handling
QA Contact: networking.http → file-handling

Comment 1

12 years ago
One correction, after further testing we noticed that IE does indeed behave the same way.


thanks,
Scott

Updated

11 years ago
Flags: blocking1.9?

Comment 2

11 years ago
Given comment 1 taking this off the blocking list for now.  Jesse/DVeditz adjust if that's wrong..
Flags: blocking1.9? → blocking1.9-
Marking sg:high as it can result in XSS for affected sites.  Also might be worth retesting in IE8 as they made some changes to content sniffing.
Whiteboard: [sg:high]

Comment 4

10 years ago
Nominating for blocking1.9.1: likely to be discovered independently, especially once we fix bug 474536 and issue an advisory for it.
Flags: blocking1.9.1?
(Reporter)

Updated

10 years ago
Component: File Handling → Content
QA Contact: file-handling → content
Thing is, I think this behavior is interoperable across all browsers right now.  And changing it might well break sites.  :(

Comment 6

10 years ago
Hmm.  And how bad is it that plugin loads ignore content-disposition: attachment?
Possibly bad, since plug-ins do stuff with the permissions of the site they're loaded from, basically...

I can probably live with adding a check for this for plugin loads specifically.
(Reporter)

Comment 8

10 years ago
lowering to "moderate" on the grounds that it's not a problem particular to Firefox, and would only affect sites not aware of this cross-browser behavior.

It could be useful to treat plugins separately from other content (img, script, etc) since many plugins have complex security models of their own and function as sub-documents, more like iframes than simple components of the encompassing page.

Tangentially, there's discussion amongst plugin folks to add a way to let the plugin itself download its source rather than have the browser do it. Should that happen it could be a way to side-step the enforcement of Content-disposition requested by this bug.
Whiteboard: [sg:high] → [sg:moderate]
Not going to hold the release on this sg:moderate bug, given that it's not specific to firefox, and it's been around for quite a while. Not to say we shouldn't fix it, but not holding the release.
Flags: wanted1.9.2+
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-

Updated

10 years ago
Component: Content → DOM
QA Contact: content → general

Comment 10

7 years ago
Does this still need to be hidden?
(Assignee)

Updated

6 years ago
Assignee: nobody → jschoenick
(Assignee)

Comment 11

6 years ago
This doesn't actually fully work - we switch to type document and pass the channel to the URI loader, but we don't reach the download-dialog handler for some reason.
(Assignee)

Comment 13

6 years ago
Posted patch TestsSplinter Review

Updated

5 years ago
Summary: Ignoring Content-Disposition: attachment leads to XSS hazards → Ignoring "Content-Disposition: attachment" for plugins leads to XSS hazards

Comment 14

5 years ago
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ is a similar problem involving ignoring the MIME type. One of the suggested workarounds is to... use "Content-Disposition: attachment".
(Assignee)

Comment 15

5 years ago
So the WIP version of these patches forced | Content-Disposition: | attachment to be loaded as a document, but unlike an iframe, <object> documents won't trigger a download prompt, so we either need to figure out how to fix that, or just refuse to load attachment disposition entirely. I'll un-bit-rot these and take a look
(Assignee)

Comment 16

5 years ago
(In reply to Jesse Ruderman from comment #14)
> http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ is a similar
> problem involving ignoring the MIME type. One of the suggested workarounds
> is to... use "Content-Disposition: attachment".

Since this is being publicly discussed, should we open up this bug?
Flags: needinfo?(dveditz)
(Reporter)

Updated

5 years ago
Group: core-security
Flags: needinfo?(dveditz)
(In reply to John Schoenick [:johns] from comment #15)
> So the WIP version of these patches forced | Content-Disposition: |
> attachment to be loaded as a document, but unlike an iframe, <object>
> documents won't trigger a download prompt, so we either need to figure out
> how to fix that, or just refuse to load attachment disposition entirely.
> I'll un-bit-rot these and take a look

Boris, do you have an idea about the answer to this?
Flags: needinfo?(bzbarsky)
You could just hand the channel off to nsIURILoader::OpenChannel, as long as you then forward along all the nsIStreamListener calls.  That should get you on the normal codepath used to dispatch content, an the Content-Disposition bits will then drop you into the external helper app service and whatnot.

On the other hand, I can't think of many cases where users would actually want such a dialog here.  So I think dropping things on the floor in the Content-Disposition:attachment case would also be ok.
Flags: needinfo?(bzbarsky)
:overholt, this bug hasn't been touched in 3 years, I'm making it a P5.
Flags: needinfo?(overholt)
Priority: -- → P5
I doubt it. qDot, do you know?
Flags: needinfo?(overholt) → needinfo?(kyle)
Tough to say. This bug comes from a different era when plugins did way more. We're down to flash now, so this /could/ be a problem if a site embedded user uploaded flash in an odd way, but that's gonna be a problem no matter what. I think we could take the "just drop it" choice from Comment 18 now with no real worries, it's just a question of if it's worth the work. I think that might be adaptable from the patches already on this bug.
Flags: needinfo?(kyle)
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.