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)

defect
Not set
normal

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.
Group: core-security
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?
Whiteboard: A4A?
See https://bugzilla.mozilla.org/show_bug.cgi?id=741526#c18 : I think this is the case here, so we do as expected.
(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.
Going to hold on the tracking-ff flags until Jonas looks at this.
Flags: needinfo?(jonas)
blocking-b2g: tef? → ---
Dare I say that when we'll have multiple apps per origin this issue with disappear?
Keywords: sec-high
Probably too late to fight this one into b2g, but we should push to get this fixed for same origin cases.
What's the regressing bug here? Does this impact Desktop/Mobile?
(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).
Whiteboard: A4A? → A4A
(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)
(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.
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).
Group: core-security
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
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 → ---
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
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.
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.
Fair enough. I'll won't fix then this bug then if bug 821288 will resolve the risk.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Ah mistype-o.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → WONTFIX
Group: core-security
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.