headers
Paul Theriault | 4 Jun 2012 07:51
Gravatar

Re: WebAPI Security Discussion: Browser API

(Final proposal, please reply to dev-webapps <at> lists.mozilla.org by COB 
Jun 04)

Only change here was to change trusted apps from explicit to implicit, 
acknowledging that trusted and certified apps will now have separate 
profile based resources (cookie jars, localstorage, app-cache etc)

Name of API: Browser API
References:
https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
popup windows in b2g: https://bugzilla.mozilla.org/show_bug.cgi?id=716664
window.open in iframe mozbrowser: 
https://bugzilla.mozilla.org/show_bug.cgi?id=742944
window.open in iframe mozapp: 
https://bugzilla.mozilla.org/show_bug.cgi?id=744451

Brief purpose of API: Provide an iframe that acts as a web browser
General Use Cases: A browser app.

Inherent threats:
* browser can see all data from all websites, and perform all actions
* can steal passwords (user-entered; enumerate all saved passwords)
* can steal cookies (by enumerating websites)
* NOT a use case: OAuth or other app-content or content-content interactions

Threat severity: high per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: None
Authorization model for normal content: None
(Continue reading)

Permalink | Reply | 0 comments |
headers
ptheriault@mozilla.com | 4 Jun 2012 07:55
Gravatar

Re: WebAPI Security Discussion: Permission API

Final call for comments. Please reply to dev-webapps <at> lists.mozilla.org by COB Jun 04.

On Wednesday, 9 May 2012 09:47:47 UTC+10, Lucas Adamski  wrote:
> Please reply-to dev-webapps <at> lists.mozilla.org
> 
> Name of API: Permission API
> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=707625
> 
> Brief purpose of API: Allow an app to manage app permissions in a centralized location
> General Use Cases: None
> 
> Inherent threats: Change security and privacy permissions, potentially leading to device compromise
> 
> Threat severity: Critical
> 
> == Regular web content (unauthenticated) ==
> Use  cases for unauthenticated code:None
> Authorization model for normal content:  None
> Authorization model for installed content: None
> Potential mitigations: 
> 
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: None
> Use cases for trusted code: None
> Potential mitigations:
> 
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code:  Centralized permissions management app; modify per-app settings
> Authorization model: Implicit
> Potential mitigations: None
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Treese | 4 Jun 2012 17:09

Re: [b2g] WebAPI Security Discussion: Device Storage API

comments inline below

Michael

----- Original Message -----
From: ptheriault <at> mozilla.com
To: "mozilla dev webapps" <mozilla.dev.webapps <at> googlegroups.com>
Cc: dev-webapi <at> lists.mozilla.org, dev-security <at> lists.mozilla.org, "Mozilla B2G mailing list" <dev-b2g <at> lists.mozilla.org>
Sent: Sunday, June 3, 2012 6:53:05 PM
Subject: Re: [b2g] WebAPI Security Discussion: Device Storage API

(Final call for feedback - Please reply-to dev-webapps <at> lists.mozilla.org.)

I'd like to finalize the permissions model for this API, but there hasn't been any feedback here, and I am not
confident original proposal is effective or accurate. The problem I see with the proposal below is that it
doesn't address the threat of existing files being deleted/modified (see
https://wiki.mozilla.org/WebAPI/DeviceStorageAPI for more discussion).

Does anyone have thoughts on the following questions:
- Will there be separate shared file stores (e.g Photos, music, videos I assume yes, maybe this is a b2g
specific thing though?)
> separate file storesmay be needed to support different security requirements, e.g., DRM on music files,
but not for photos
- Will access in some cases be only granted to one specific file store (I am thinking here to support a prompt
like "Do you want to grant access to this app to read your photos"
>> I would favor letting the use control which apps have access to specific file stores. This will help with
privacy issues which are likely to get more attention in the coming years

- Will create/read be a separate permission to edit/delete (I think it should be, or there should be some way
to prevent untrusted or even trusted apps from deleting all your media)
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Nagle | 4 Jun 2012 20:10
Favicon

Implications of new TLDs

    Many new TLDs appear to be coming.  This may affect how Mozilla
interprets input in the URL bar, and has security implications.
Single-word domain names are about to become a common form of
URL.  Now the browser has to decide whether "example" is looked
up in DNS or a search engine.

    Is DNS always preferred over search?  Does this introduce any
security risks?  Will other browsers from search engine vendors
(Microsoft and Google) make the same choice?  Is adding
".com" to single words and retrying still appropriate behavior?
Should command completion/"suggest" use DNS information?

				John Nagle
Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 4 Jun 2012 21:11
Picon
Favicon

Re: Implications of new TLDs

On 6/4/12 2:10 PM, John Nagle wrote:
> Is DNS always preferred over search?

At the moment, yes.  Otherwise lots of intranet stuff that uses search 
domains would fail too.

> Does this introduce any security risks?

Could be.

> Will other browsers from search engine vendors
> (Microsoft and Google) make the same choice?

I bet they already do; see intranets.

> Is adding ".com" to single words and retrying still appropriate behavior?

On DNS fail, you mean?

-Boris
Permalink | Reply | 0 comments |
headers
John Nagle | 4 Jun 2012 21:29
Favicon

Re: Implications of new TLDs

On 6/4/2012 12:11 PM, Boris Zbarsky wrote:
> On 6/4/12 2:10 PM, John Nagle wrote:
>> Is DNS always preferred over search?
>
> At the moment, yes. Otherwise lots of intranet stuff that uses search
> domains would fail too.

     OK, that's good enough for now.

     The main change is that, for today's TLDs, few bare TLDs resolve
to an IP address.  Corporate TLDs ("facebook", "pepsi", etc.)
probably will resolve to an IP address.
>
>> Does this introduce any security risks?
>
> Could be.

     I can see problems appearing with firewalls, caching servers,
and other stuff in the middle with too much state.  But that's
not the browser's problem.

				John Nagle
Permalink | Reply | 0 comments |
headers
Zack Weinberg | 4 Jun 2012 21:34
Picon
Favicon
Gravatar

Re: Implications of new TLDs

On 2012-06-04 12:29 PM, John Nagle wrote:
> The main change is that, for today's TLDs, few bare TLDs resolve
> to an IP address. Corporate TLDs ("facebook", "pepsi", etc.)
> probably will resolve to an IP address.

Are you aware of actual plans to allow A records for TLDs?  I don't have 
links to earlier discussion offhand, but I recall the consensus being 
that that shouldn't be allowed at all.

zw
Permalink | Reply | 1 comment |
headers
John Nagle | 4 Jun 2012 22:29
Favicon

Re: Implications of new TLDs

On 6/4/2012 12:34 PM, Zack Weinberg wrote:
> On 2012-06-04 12:29 PM, John Nagle wrote:
>> The main change is that, for today's TLDs, few bare TLDs resolve
>> to an IP address. Corporate TLDs ("facebook", "pepsi", etc.)
>> probably will resolve to an IP address.
>
> Are you aware of actual plans to allow A records for TLDs? I don't have
> links to earlier discussion offhand, but I recall the consensus being
> that that shouldn't be allowed at all.

    Interesting point.  I'm not clear on how delegation of new TLDs
will work.  Do the root servers host all their TLD-level DNS records,
or are they somehow delegated to a server under the control of the
TLD owner?

				John Nagle
Permalink | Reply | 0 comments |
headers
Gervase Markham | 5 Jun 2012 18:34
Picon
Favicon
Gravatar

Re: Implications of new TLDs

On 04/06/12 19:10, John Nagle wrote:
>    Many new TLDs appear to be coming.  This may affect how Mozilla
> interprets input in the URL bar, and has security implications.

But to a lesser degree than for Chrome. They use the PSL to determine
what is a URL and what is a search; that may not be scalable going forward.

> Single-word domain names are about to become a common form of
> URL.

IMO, Mozilla should not be in favour of this type of word hijacking.
"www.nike", fine. Bare "nike", no. But then, maybe it's up to the user's
DNS configuration rather than us...

>    Is DNS always preferred over search?  Does this introduce any
> security risks?  Will other browsers from search engine vendors
> (Microsoft and Google) make the same choice?  

You'd need to ask them.

> Is adding
> ".com" to single words and retrying still appropriate behavior?

Do we actually do that, without explicit user command?

Gerv
Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 5 Jun 2012 18:44
Picon
Favicon

Re: Implications of new TLDs

On 6/5/12 12:34 PM, Gervase Markham wrote:
>> Is adding
>> ".com" to single words and retrying still appropriate behavior?
>
> Do we actually do that, without explicit user command?

Yes, on DNS lookup fail.  We'll try adding ".com" and "www." (or 
equivalent's it's a preference which is localized per-locale iirc).

-Boris
Permalink | Reply | 0 comments |

Gmane