Closed
Bug 831246
Opened 12 years ago
Closed 12 years ago
Enforce the mime type check for webapp manifests same and cross origin, not just cross-origin
Categories
(Core Graveyard :: DOM: Apps, defect)
Core Graveyard
DOM: Apps
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jsmith, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-needed, sec-high, Whiteboard: A4A)
Spinoff of https://bugzilla.mozilla.org/show_bug.cgi?id=819037#c6
Background - webapp manifests need to have the following mime type:
application/x-web-app-manifest+json
If they don't, you won't be able to install the app. We implemented this for all platforms as a basecamp blocker.
However, Wes has figured out a way to get past this mime type check on dropbox:
http://dl.dropbox.com/u/72157/Apps/testApp.manifest
If you install his app through http://dl.dropbox.com/u/72157/Apps/testApp.html, it works. curl shows the following:
HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Wed, 16 Jan 2013 13:34:45 GMT
Content-Type: text/cache-manifest; charset=ascii
Content-Length: 303
Connection: keep-alive
x-robots-tag: noindex,nofollow
accept-ranges: bytes
x-server-response-time: 235
etag: 1266828555n
pragma: public
cache-control: max-age=0
This is the wrong mime type - we're allowing installation of a hosted app with a wrong mime type. Right now, an app developer can then claim ownership of anything in the dl.dropbox.com area as a result as there own without dropbox's knowledge of this.
Therefore, I argue this is a security bug - an evil app developer can claim ownership of dl.dropbox.com for their own purposes as an app without dropbox knowing due to an incorrect mime type check.
Reporter | ||
Updated•12 years ago
|
Group: core-security
Reporter | ||
Comment 1•12 years ago
|
||
I think FF 19, 20, 21, contain the mime type check patch, so I'm assuming this needs to be tracked at all levels. If I'm wrong, feel free to change flags.
blocking-b2g: --- → tef?
tracking-firefox19:
--- → ?
tracking-firefox20:
--- → ?
tracking-firefox21:
--- → ?
Reporter | ||
Updated•12 years ago
|
Whiteboard: A4A?
Comment 2•12 years ago
|
||
See https://bugzilla.mozilla.org/show_bug.cgi?id=741526#c18 : I think this is the case here, so we do as expected.
Reporter | ||
Comment 3•12 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #2)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=741526#c18 : I think this
> is the case here, so we do as expected.
But isn't that approach going to fail in this exact example I presented in this bug? The case where you have servers that multiple users make use of?
dl.dropbox.com would be example of a "multi-user" server that is affected. people.mozilla.org is another.
Reporter | ||
Comment 4•12 years ago
|
||
Going to hold on the tracking-ff flags until Jonas looks at this.
tracking-firefox19:
? → ---
tracking-firefox20:
? → ---
tracking-firefox21:
? → ---
Flags: needinfo?(jonas)
Reporter | ||
Updated•12 years ago
|
blocking-b2g: tef? → ---
Comment 5•12 years ago
|
||
Dare I say that when we'll have multiple apps per origin this issue with disappear?
Reporter | ||
Comment 6•12 years ago
|
||
Probably too late to fight this one into b2g, but we should push to get this fixed for same origin cases.
tracking-b2g18:
--- → ?
tracking-firefox19:
--- → ?
tracking-firefox20:
--- → ?
tracking-firefox21:
--- → ?
Comment 7•12 years ago
|
||
What's the regressing bug here? Does this impact Desktop/Mobile?
Reporter | ||
Comment 8•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #7)
> What's the regressing bug here? Does this impact Desktop/Mobile?
Don't think it was a regression - basically we made an assumption in bug 741526 that not doing same origin checks for the mime type was okay, but now we realize that's not a good idea due to the security risk posed in this bug.
It impacts all platforms (Desktop Firefox, FF Android, and B2G).
Updated•12 years ago
|
Whiteboard: A4A? → A4A
Comment 9•12 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #5)
> Dare I say that when we'll have multiple apps per origin this issue with
> disappear?
Fabrice,
:) It's true, we're heading toward multiple apps per origin, but enforcing this restriction is orthogonal to that issue. IMHO, the content-type restriction means that the domain owners know and approve of the idea that apps are hosted at that domain.
Yeah, the short-term solution here is "don't put your app on a server where others can also put an app".
The v2 solution is multiple-apps-per-origin.
I think this bug is INVALID and should be opened.
I agree it's not a great state, but it's simply an effect of one-app-per-origin. Even if you set the mimetype correctly the same problem would be there.
Flags: needinfo?(jonas)
Reporter | ||
Comment 11•12 years ago
|
||
(In reply to Jonas Sicking (:sicking) from comment #10)
> Yeah, the short-term solution here is "don't put your app on a server where
> others can also put an app".
>
> The v2 solution is multiple-apps-per-origin.
>
> I think this bug is INVALID and should be opened.
>
> I agree it's not a great state, but it's simply an effect of
> one-app-per-origin. Even if you set the mimetype correctly the same problem
> would be there.
The problem would be reduced in severity though if the mimetype restriction was in place for same origin though. That would stop the dropbox scenario described in this bug *unless* dropbox decides to enable the webapp mime type on their server. Then, yes, your right, we're stuck with the problem we have for v1.
But I don't see why we couldn't at least reduce the severity of the problem by enforcing the mime type restriction same origin.
Reporter | ||
Comment 12•12 years ago
|
||
In other words:
We can easily add dev docs giving warnings about how webapp manifests are used, especially on a multi-user server. The *hole* only opens up if the mime type restriction is put in place on the server. So it becomes the responsibility of the server owner who allowed that mime type to follow our guidelines.
But I don't think we should allow unintentional usage of a site that didn't even be planned to be an app to allow it to become a hosted app controlled by someone else. That's the source of the problem I'm talking about this bug - dl.dropbox.com had no intentions of being a hosted app, yet someone managed to make it an app without their consent and intentions to have some part of dl.dropbox.com become a hosted webapp (i.e. wasn't ever intended to be a hosted web app).
Reporter | ||
Updated•12 years ago
|
tracking-b2g18:
? → ---
tracking-firefox19:
? → ---
tracking-firefox20:
? → ---
tracking-firefox21:
? → ---
Group: core-security
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 13•12 years ago
|
||
Sorry, I don't agree it's invalid. See my comment above explaining why.
And I don't think this should be opened up.
Group: core-security
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 14•12 years ago
|
||
I modified the title to explain exactly what I'm proposing could be done reduce the severity. It cuts off dl.dropbox.com scenario described in the bug.
Summary: The mime type check for app manifests is allowing installation of apps off of Dropbox with text/cache-manifest; charset=ascii, even though that's an invalid mime type for a webapp manifest → Enforce the mime type check for webapp manifests same and cross origin, not just cross-origin
Reporter | ||
Comment 15•12 years ago
|
||
Oh for not opening piece - because this right now would expose exactly how I could turn an existing multi-user server that didn't intend to be a webapp into a webapp outside of the control of the server admin who controls the mime type.
Comment 16•12 years ago
|
||
The patch I'm about to write for bug 821288 will protect users (which is much more important to me that server admins) from installing multiple apps from the same origin. That's good enough IMHO.
Reporter | ||
Comment 17•12 years ago
|
||
Fair enough. I'll won't fix then this bug then if bug 821288 will resolve the risk.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
Many hosting services allow cofiguring the mimetype of resources, so I don't think adding a mimetype check would change anything.
And I don't think that keeping this bug helps at all. If anything we should scream from the roof tops that people shouldn't be hosting apps on hosting services where others could be hosting apps too.
Reporter | ||
Updated•12 years ago
|
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reporter | ||
Comment 19•12 years ago
|
||
Ah mistype-o.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
Reporter | ||
Updated•12 years ago
|
Group: core-security
Reporter | ||
Updated•12 years ago
|
Blocks: Apps-Dev-Doc-Needed
Keywords: dev-doc-needed
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•