Closed Bug 825388 Opened 12 years ago Closed 12 years ago

[Reviewer Task] Some existing hosted apps on marketplace are doing immediate redirects to off-origin sites to claim ownership of apps the developer does not own

Categories

(Marketplace Graveyard :: Reviewer Tools, defect)

Product:
Marketplace Graveyard
Component:
Reviewer Tools
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jsmith, Unassigned)

Details

The marketplace appears to be listing right now hosted apps that do immediate off-origin redirects to another site. For minor examples such as the Pulse Web App, this isn't terribly bad (although technically incorrect by how hosted apps are supposed to be built), as you end up on the same site owned by the developer (that one in particular just changed http:// to https://). However, more severe cases exist in marketplace, such as the facebook web app: https://marketplace.firefox.com/app/facebook-web/?src=mkt-search This app does an immediate redirect to facebook's website to allow users to install an app that's facebook but off-origin. This violates a proof of ownership facebook has over their site, as a different app developer has essentially created a hosted app for a site they do not own. In the client-side, we provide UI to indicate when the app is off the origin, but it won't give enough context to indicate to the user whether the app developer owns the app content or not. This is a security problem - we're letting hosted apps go through the review process right now that allow an app developer to claim ownership of a site that they do not have ownership over. Facebook Web being an excellent example of this. The mitigation of this should be handled at least in the review process, by making sure that the hosted apps active on marketplace are actually owned by the app developer and not doing off-origin redirects to claim ownership of sites they do not own. Some immediate actions to do here: 1. Hosted apps that do not immediate off-origin redirects should be rejected - this violates our security model for hosted apps. This bug should fix this problem. 2. The validator probably should be doing some check of the launch_path to ensure it doesn't do an immediate off-origin redirect to help automate the process. That could be taken care in a separate bug if people think that's a good idea. cc-ing Lucas, Jonas, and Raymond for input
Raymond - Any thoughts on this? See the facebook web app (https://marketplace.firefox.com/app/facebook-web) for an example of the concept of the problem I'm talking about.
Flags: needinfo?(rforbes)
Is the website redirecting the manifest request? Or are they hosting the manifest, but once the launch is loaded, they are redirecting that to a 3rd party?
(In reply to Jonas Sicking (:sicking) from comment #2) > Is the website redirecting the manifest request? Or are they hosting the > manifest, but once the launch is loaded, they are redirecting that to a 3rd > party? The second thing. For example: The facebook web app's origin is: http://facebook.dynamis.jp The manifest's launch_path launches the hosted app at http://facebook.dynamis.jp. When you launch that web app, the content does an immediate redirect to https://facebook.com. $ curl -i http://facebook.dynamis.jp HTTP/1.1 200 OK Date: Mon, 31 Dec 2012 00:56:41 GMT Server: Apache Last-Modified: Wed, 26 Dec 2012 03:18:58 GMT ETag: "14cb912-108-50da6ca2" Accept-Ranges: bytes Content-Length: 264 Connection: close Content-Type: text/html; charset=utf-8 <!DOCTYPE html> <html> <head> <meta http-equiv="refresh" content="0;URL=https://www.facebook.com/"> <title>Redirect to Facebook</title> <script> document.location = "https://www.facebook.com/"; </script> </head> <body> <h1>Loading Facebook...</h1> </body> </html>
Ugh, yeah, there's not a whole lot we can do on a technical side about this. Even if we had more knobs for controlling off-origin navigations, it will always be possible for an app to say that navigations to a particular origin should be handled in-app. Maybe what we could do is to hook up the x-frame-options feature such that if a website says that it doesn't want to be <iframe>ed, we'd also not allow it to be run as a top-level page in an app! Would you mind filing that as a separate bug? That's certainly not a perfect solution though. And while we can try to catch this behavior in reviews, a hosted app can always change how it redirects once it has passed review.
We had some early discussions about restricting app top level content to the app origin, but it didn't go very far, due to various mechanisms (like authentication) that rely on cross-site redirects.
Yeah. I think that we can add features which prevent apps from accidentally navigating off-origin to pages which doesn't allow navigating back to the app. However I don't think there is any way that we can prevent apps from maliciously redirecting to another website. There are plenty of use-cases for interacting with other websites and I don't think we want to kill them all. x-frame-options integration should help though. That's something that websites that want to prevent being <iframe>d should use anyway.
Is this part of the review checklist? Developers that have a genuinely useful app have relatively little incentive to start bouncing their users to a different site after the review process has taken place (i.e.: why would you build an app that's good enough to make it into the marketplace only to trash it and bounce those users to a different site?). A good start would be to reject the "Facebook Web" app and update the policy for apps submitted in the future. Does B2G provide a visual indication that the app is off-origin? Also CCing eviljeff (marketplace reviewer)
(In reply to Jason Smith [:jsmith] from comment #0) > Some immediate actions to do here: > > 1. Hosted apps that do not immediate off-origin redirects should be rejected > - this violates our security model for hosted apps. This bug should fix this > problem. This is the current review policy (no redirects to sites they don't own) but there may some existing apps that were approved beforehand. If you have any other examples we can address them. > 2. The validator probably should be doing some check of the launch_path to > ensure it doesn't do an immediate off-origin redirect to help automate the > process. That could be taken care in a separate bug if people think that's a > good idea. I don't think its practical to check for this in the validator - there too are many ways a redirect could be implemented. Unless Basta thinks its easy to (effectively) implement.
(In reply to Jonas Sicking (:sicking) from comment #4) > Ugh, yeah, there's not a whole lot we can do on a technical side about this. > Even if we had more knobs for controlling off-origin navigations, it will > always be possible for an app to say that navigations to a particular origin > should be handled in-app. > > Maybe what we could do is to hook up the x-frame-options feature such that > if a website says that it doesn't want to be <iframe>ed, we'd also not allow > it to be run as a top-level page in an app! Would you mind filing that as a > separate bug? > > That's certainly not a perfect solution though. And while we can try to > catch this behavior in reviews, a hosted app can always change how it > redirects once it has passed review. Filed bug 825882 about this. (In reply to Matt Basta [:basta] from comment #7) > Is this part of the review checklist? Developers that have a genuinely > useful app have relatively little incentive to start bouncing their users to > a different site after the review process has taken place (i.e.: why would > you build an app that's good enough to make it into the marketplace only to > trash it and bounce those users to a different site?). > > A good start would be to reject the "Facebook Web" app and update the policy > for apps submitted in the future. Does B2G provide a visual indication that > the app is off-origin? > > Also CCing eviljeff (marketplace reviewer) B2G provides an indication of being off the origin when viewing a hosted app in the card view. (In reply to Andrew Williamson [:eviljeff] from comment #8) > (In reply to Jason Smith [:jsmith] from comment #0) > > Some immediate actions to do here: > > > > 1. Hosted apps that do not immediate off-origin redirects should be rejected > > - this violates our security model for hosted apps. This bug should fix this > > problem. > > This is the current review policy (no redirects to sites they don't own) but > there may some existing apps that were approved beforehand. If you have any > other examples we can address them. Facebook web is the one I know about. I'll keep a look out for others though. > > > 2. The validator probably should be doing some check of the launch_path to > > ensure it doesn't do an immediate off-origin redirect to help automate the > > process. That could be taken care in a separate bug if people think that's a > > good idea. > > I don't think its practical to check for this in the validator - there too > are many ways a redirect could be implemented. Unless Basta thinks its easy > to (effectively) implement. You can go ahead and close this after facebook web is taken down then.
Flags: needinfo?(rforbes)
okay, I'll close then - Facebook web was rejected earlier today. If any notices any more please let me or Lisa know. We'll likely still get a lot of these submitted, at least until 'add to homescreen' is an option in Android/Desktop like it is in b2g.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Does this bug need to remain close? It's making blocking discussions for bug 825882 harder.
(In reply to Jonas Sicking (:sicking) from comment #11) > Does this bug need to remain close? It's making blocking discussions for bug > 825882 harder. Okay, I'll open it up.
Group: client-services-security
You need to log in before you can comment on or make changes to this bug.