Closed Bug 836352 Opened 7 years ago Closed 4 years ago

Differentiating active vs passive mixed content for requests made by plugins

Categories

(Firefox :: Security, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: tanvi, Unassigned)

References

(Blocks 1 open bug)

Details

Plugins make requests for resources; these resources are given a content type TYPE_OBJECT_SUBREQUEST.

The Mixed Content Blocker can't tell if these requests are for active content or passive content.  For non-plugin requests, the content type is determined by the context of the request.  Since the browser doesn't know why the plugin is requesting the content, we can't tell if its requesting a script or an image or a video.

Mixed content caused by plugins isn't an issue that will go away (For example, we cannot expect that video files on https pages are all encrypted.  This would slow down the performance of the site and negatively effective user experience, especially for users with low bandwidth connections).

There are a few ways to deal with this.  None of them are ideal and many are not easy:
* Treat all plugin requests as passive content
* Check the file type that is returned (is it .js, is it .swf?) and make a best guess for the content type and active/passive classification.
* Sniff the content that is returned to see what content type it looks like.
* Ask plugin creators to honor the mixed content settings of the browser.  If mixed active content is turned off, do not allow mixed active content requests.
* Ask plugin creators to provide API options that tell the browser whether a request/response is passive or active, and then let the browser decide how to handle the request/response.

I first discovered this issue when testing the Mixed Content Blocker on https://youtube.com.  In the current implementation of nsMixedContentBlocker, the video content is blocked because it is retrieved over http and nsMixedContentBlocker takes the conservative approach by treating all TYPE_OBJECT_SUBREQUEST as active content.

Other suggestion and thoughts are welcome!
Depends on: 836359
I'm guessing https://www.pandora.com/station/play/638787934726685368 is broken for the same reason.  (Without bug 837351, it's hard to be sure.)  It's possible that I was only connected using https because I had just renewed my Pandora One subscription.
We could look at the responses' content-type and sniff their contents to either blacklist certain types (*.swf, *.jar, *.class, *.js, etc.) and/or whitelist certain types (e.g. images, video). Note that trusting the Content-Type is not a great idea because presumably a MitM has changed the Content-Type and the plugin might be ignoring the Content-Type and just sniffing the content or assuming a particular type.
The patch in bug 836359 makes Firefox treat all plugin loads as "passive content" for now.  This fixes Pandora for me :)
See Also: → 1190623
I think we've established that it's not really feasible to distinguish by type, so we're on to the question of whether we can block object requests altogether, in Bug 1190623.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.