WebAPI Security Discussion: Browser API - mozilla.dev.webapps

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
mozilla.dev.webapps
Message from discussion WebAPI Security Discussion: Browser API
Path: r9ni62004pbh.0!nntp.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 16 Apr 2012 02:17:01 -0500
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.212.182 is
	authorized to use 'justin.le...@gmail.com' in 'mfrom' identity
	(mechanism 'ip4:209.85.128.0/17' matched))
	receiver=notorious.mozilla.org; identity=mailfrom;
	envelope-from="justin.le...@gmail.com";
	helo=mail-wi0-f182.google.com; client-ip=209.85.212.182
MIME-Version: 1.0
In-Reply-To: <F14FD991-6B3A-4705-A1A3-2B9181CDCE8B@mozilla.com>
References: <F14FD991-6B3A-4705-A1A3-2B9181CDCE8B@mozilla.com>
From: Justin Lebar <justin.le...@gmail.com>
Date: Mon, 16 Apr 2012 17:15:31 +1000
Subject: Re: WebAPI Security Discussion: Browser API
To: dev-weba...@lists.mozilla.org
Cc: dev-web...@lists.mozilla.org, dev-secur...@lists.mozilla.org,
	dev-b2g mailing list <dev-...@lists.mozilla.org>
Precedence: list
Approved: dev-weba...@lists.mozilla.org
Newsgroups: mozilla.dev.webapps
Message-ID: <mailman.21459.1334560621.31724.dev-weba...@lists.mozilla.org>
Lines: 95
NNTP-Posting-Host: 63.245.208.166
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Potential mitigations: container should not be able to script into browse=
r iframe

In general, you cannot mitigate risk from an untrusted browser.

An untrusted browser can arbitrarily phish you.  You type in
"bank.com", the browser takes you to evil.com and displays "bank.com"
in its URL bar.  It even displays a lock icon.  You type in your
username and password.  Evil.com records it.

I think it is a mistake to talk about things like preventing the
container from injecting script into the iframe.  That is only useful
for preventing a tiny class of attacks out of many, many possible
attacks.

> Use cases for authenticated code: Display remote content (e.g. from devel=
oper's site, or the contents of a tweet), or perform interactions with web-=
based services, including  OAuth, OpenID,
> PayPal, Facebook Connect, etc. etc.

<iframe mozbrowser> is explicitly not for this.  We need to be able to
run the mozbrowser in a separate process, and that precludes any
interaction of this sort between the parent and the child.

> [Given that the browser is built in to b2g, what would a replacement brow=
ser actually be?]

The browser is built in just like the calculator app.  A user could
download another calculator app.  They could also download another
browser app (modulo security constraints).

On Mon, Apr 16, 2012 at 4:14 PM, Lucas Adamski <ladam...@mozilla.com> wrote=
:
> Please reply-to dev-weba...@lists.mozilla.org
>
> Name of API: Browser API
> Reference: https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
>
> Brief purpose of API: Provide an iframe that acts as a web browser
> General Use Cases: None
>
> Inherent threats:
> * browser can see all data from all websites, and perform all actions
>
> Threat severity: moderate (phishing) per https://wiki.mozilla.org/Securit=
y_Severity_Ratings
>
> =3D=3D Regular web content (unauthenticated) =3D=3D
> Use cases for unauthenticated code: None
> Authorization model for normal content: None
> Authorization model for installed content:None
> Potential mitigations:
>
> =3D=3D Trusted (authenticated by publisher) =3D=3D
> Use cases for authenticated code: Display remote content (e.g. from devel=
oper's site, or the contents of a tweet), or perform interactions with web-=
based services, including =C2=A0OAuth, OpenID, PayPal, Facebook Connect, et=
c. etc.
> Authorization model: implicit
> Potential mitigations: container should not be able to script into browse=
r iframe
>
> Google's recommendations about how to do this:
> http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-app=
roval
>
> Consider also the iOS-Twitter authorization flow described here:
> http://code.google.com/p/twitter-api/issues/detail?id=3D1560
> and the threat, described here:
> http://www.zdnet.co.uk/blogs/tech-tech-boom-10017860/ios-url-handler-pose=
s-significant-risk-10021042/
>
> =3D=3D Certified (vouched for by trusted 3rd party) =3D=3D
> Use cases for certified code: Replacement Browser
> Authorization model: Implicit
> Potential mitigations: Explicit process to add a new browser to the syste=
m?
>
> [Given that the browser is built in to b2g, what would a replacement brow=
ser actually be?]
>
> popup windows in b2g:
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D716664
>
> window.open in iframe mozbrowser:
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D742944
>
> window.open in iframe mozapp:
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D744451
>
>
> _______________________________________________
> dev-webapi mailing list
> dev-web...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
