email@example.com 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?  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  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)
12 years ago
Assignee: cbiesinger → nobody
Component: Networking: HTTP → File Handling
QA Contact: networking.http → file-handling
One correction, after further testing we noticed that IE does indeed behave the same way. thanks, Scott
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.
Nominating for blocking1.9.1: likely to be discovered independently, especially once we fix bug 474536 and issue an advisory for it.
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. :(
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.
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.
Does this still need to be hidden?
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.
Summary: Ignoring Content-Disposition: attachment leads to XSS hazards → Ignoring "Content-Disposition: attachment" for plugins leads to XSS hazards
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".
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
(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?
(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?
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.
:overholt, this bug hasn't been touched in 3 years, I'm making it a 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.
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.