712045 - find a secure way to relax the restriction on webapp manifest MIME type

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Bill Walker [:bwalker] [@wfwalker]]

We need to find a secure way to relax the restriction on webapp manifest MIME type. For example, the good folks doing marblesoccer.com could publish the game directly from github but for the MIME type restriction.

Comment 1

[Ian Bicking (:ianbicking)]

The restriction was put in place to guard against people publishing malicious manifests on behalf of some site.  For instance, you should not be able to publish a page from github.com, but only from github pages.  And just being able to inject a text file and a little HTML into a site shouldn't allow you to publish an app for the site.  Requiring a specific mimetype protects some in this case.

Another approach we considered was a specific required URL (e.g., /.well-known/app-manifest.json).  This would protect against some XSS bugs, and there could only be one fake per site -- you couldn't hide something deep in a hard-to-notice location.

We could consider using the well-known URL as an alternative check.  (Though I have noticed some problems with files that start with a dot on github pages, maybe as a security check on their part; but we can't work around everything.)

Comment 2

[Michael Hanson]

For purposes of this bug, let's explore the boundaries of the "well-known URL" fix.

Specifically, let's assume that we use "/.well-known/moz-app-manifest.json" for now.  Assume that, if the manifest registered for the application is at this path, we do NOT require the MIME type.  (ignore the questions of moz-prefixing for now, please, we'll deal with that in a bit)

Assume that .well-known is expected to follow all the conventions of RFC 5785.

Questions to address:
1. What does limiting the manifest to this path do the attack surface?  What class of attacks would allow an attacker to change this file?
2. Is this path settable using standard hosting tools, especially github?
3. Do we have any comment on the extension, or MIME type, that we expect in this case?  Or do we ignore it completely?
4. Suppose we relax our check to include anything in .well-known.  Is that too loose?

Let's also consider one alternative fix, which is:

If the launch_path of the application resolves to an HTML document which contains a LINK tag with a REL of application-manifest, and the VALUE of this LINK is identical to the claimed manifest URL, ignore the MIME type.

Same set of questions apply.

Comment 3

[Ian Bicking (:ianbicking)]

(In reply to Michael Hanson from comment #2)
> Questions to address:
> 1. What does limiting the manifest to this path do the attack surface?  What
> class of attacks would allow an attacker to change this file?

In the case where a site is already an application the most basic protections would probably prevent someone from overwriting this file (e.g., user-uploaded content seldom takes priority over core site content, and if it does then the site is badly broken in many ways).

In the case where a site has no application data, it may still be possible to publish at this URL (assuming it's currently 404), but it is probably more difficult.  E.g., Wordpress hacks along these lines generally leave your content in /wp-content/uploads/*

It is much easier to determine that your site has a published application manifest.  With the manifest just identified by <link> you might have to scan your entire site to see if anything has been published.  So I think attacks would be identified much more quickly.

> 2. Is this path settable using standard hosting tools, especially github?

It's just a path, so yes - you create a folder named ".well-known" and put the file in there.  Only in cases where leading dots are filtered out would it be a problem, but in those cases we might already infer that the site manager or host doesn't want to allow sites to post metadata.

> 3. Do we have any comment on the extension, or MIME type, that we expect in
> this case?  Or do we ignore it completely?

Not sure I understand the question.  Like... allow application/octet-stream, application/json, or text/plain (or a subset of these three), but not allow text/html?

> 4. Suppose we relax our check to include anything in .well-known.  Is that
> too loose?

In order to be forward-compatible with a non-prefixed name?  Allowing other files would make it possible for someone to slip in a manifest under an unexpected name, and it would be harder to detect.

> 
> Let's also consider one alternative fix, which is:
> 
> If the launch_path of the application resolves to an HTML document which
> contains a LINK tag with a REL of application-manifest, and the VALUE of
> this LINK is identical to the claimed manifest URL, ignore the MIME type.
> 
> Same set of questions apply.

I don't think this would add much protection, as the mostly likely use of a malicious manifest would be to publish a page with the bad <link>, point it at your bad manifest, and then you could satisfy this requirement by pointing your manifest back at the page with the bad <link>.  To make the malicious manifest useful you need people to install it (or maybe try to redirect them to your store of the attacker's choice, where they can pay the attacker for the application), so I expect a <link> to be useful.  Though I guess you could claim someone else's page with only a manifest.

Probably the most interesting attack is to get people to pay for a free application, and such an application probably has no manifest.  An example of an attack that would be protected against is this lame attempt to claim pastebin.mozilla.org: http://pastebin.mozilla.org/?dl=1412628 - similarly github could be claimed easily enough without the mimetype check, but you'd need to find another XSS attack to claim it with this check in place.

Comment 4

[Rob Hawkes [:rob]]

For the record, GitHub now serve .webapp manifest files hosted on GitHub Pages with the correct content-type.

Comment 5

[Ian Bicking (:ianbicking)]

We should also suggest to people that they can just upload a dynamic file.  E.g., in PHP:

  <? header('Content-Type', 'application/x-web-app-manifest+json'); ?>{
    "name": "my app"}

Comment 6

[Jason Smith [:jsmith]]

Is this a mozapps API bug? If so, migrate the bug to Core --> DOM/Mozilla Extensions.

Comment 7

[Bill Walker [:bwalker] [@wfwalker]]

(In reply to Jason Smith from comment #6)
> Is this a mozapps API bug? If so, migrate the bug to Core --> DOM/Mozilla
> Extensions.

I'd say this is a feature request that cuts across Marketplace, WebRT, etc.

Comment 8

[[:fabrice] Fabrice Desré]

For now, the mime type check is not enforced by the m-c implementation.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #8)
> For now, the mime type check is not enforced by the m-c implementation.

Should we file a bug for that? I can confirm that this definitely does happen.

Comment 10

[[:fabrice] Fabrice Desré]

(In reply to Jason Smith from comment #9)
> (In reply to Fabrice Desré [:fabrice] from comment #8)
> > For now, the mime type check is not enforced by the m-c implementation.
> 
> Should we file a bug for that? I can confirm that this definitely does
> happen.

What happens?

Comment 11

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #10)
> (In reply to Jason Smith from comment #9)
> > (In reply to Fabrice Desré [:fabrice] from comment #8)
> > > For now, the mime type check is not enforced by the m-c implementation.
> > 
> > Should we file a bug for that? I can confirm that this definitely does
> > happen.
> 
> What happens?

On FF 13 or higher, I will get a door-hanger prompt to install the app, even if the MIME type of the manifest is incorrect. Hitting install will install the app. On FF 12 or earlier, I will never get any install prompt, given that the mime type of the manifest is not being served in the acceptable mime type format for manifests (web application json format).

Comment 12

[Wil Clouser [:clouserw]]

The marketplace _is_ enforcing the restriction in order to list the app which is the origin of this bug.  We should at least be consistent.  This bug is either to add that enforcement in Fx or to adjust the spec accordingly.

Comment 13

[Ian Bicking (:ianbicking)]

This bug is about a design question: can we safely remove the content-type restriction?  Bug 741526 refers to whether Firefox is implementing the currently specified restriction.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.