[whatwg] Security risks of persistent background content (Re: Installed Apps)

[Linus Upson]

I intended the "resistant to malice and incompetence" definition of safe,
not the idempotent definition of safe. Thanks for clarifying.
Even in a world of exceptionally sophisticated applications, now and in the
future, I think it is worth preserving the safe and stateless properties of
the web. The challenge is exposing new capabilities in a way that is
compatible with those properties.

Naively bringing over APIs from desktop apps may not always work. For
example, a typical desktop app can, at any time, read all of my files. Web
apps need access to files too, but I don't want every web page see all my
files. The <input type="file"> API and UI were designed to grant access to
only the files I want to make available, and do so in a way that is natural.
Even in this simple case there were subtle security issues that took years
to emerge and address.

We need to take a similar approach with other new capabilities without
adding a new install escape hatch to the web. For capabilities where we
aren't yet clever enough to come up with a safe and stateless solution,
using the existing install mechanism of extensions and their attendant
security features seems like a good way forward.

Linus


On Wed, Jul 29, 2009 at 11:15 AM, Drew Wilson <atwilson at google.com> wrote:

> I'd agree with #1, for some given value of "safe" - we've all heard tales
> of search engines inadvertently deleting data on people's sites by following
> links. Note that web storage violates #2 and #3 (and even cookies could be
> viewed as a violation of #2, depending on how broadly you view "caches").
> But I would agree that what you've mentioned below are characteristics of
> traditional web browsing. If we went back in time several years, we might
> have added in some restrictions about how "data is only posted to the server
> in response to explicit user activity/form submittal". I think we should be
> open to the possibility that the characteristics of web browsing today are
> not necessarily inherent to the web browsing experience, and may change over
> time. Should web browsing in 2020 look like web browsing in 2010? Will web
> pages still be restricted to a sandbox with a close button?
>
> It seems like the tenets below are quite appropriate for the "browser as
> content-delivery platform". But they are already starting to change for
> "browser as application platform". The challenge is to balance the safety of
> a content-delivery platform while still giving applications the power they
> need.
>
> -atw
>
> On Wed, Jul 29, 2009 at 10:48 AM, Linus Upson <linus at google.com> wrote:
>
>> This is a good analysis. I agree that it is important for the web to
>> maintain some important properties that are in conflict with persistent
>> background processing:
>> 1. All links are safe to click
>>
>> 2. When a page is closed, the only artifacts left behind are items in
>> various caches
>>
>> 3. The user agent is free to evict items from its various caches at any
>> time
>>
>> For apps that desire capabilities that are not "safe and stateless" I like
>> your suggestion to use the browser's extension mechanism (or runtimes such
>> as prism or air). Those services usually involve some combination of
>> multiple affirmative steps, vetting, reputation and revocation.
>>
>> Linus
>>
>>
>> On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak <mjs at apple.com>wrote:
>>
>>>
>>> On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote:
>>>
>>>  I've been kicking around some ideas in this area. One thing you could do
>>>> with persistent workers is restrict network access to the domain of that
>>>> worker if you were concerned about botnets. That doesn't address the "I
>>>> installed something in my browser and now it's constantly sucking up my CPU"
>>>> issue, but that makes us no different than Flash :-P
>>>>
>>>
>>> Here's some security risks I've thought about, for persistent workers and
>>> persistent background pages:
>>>
>>> 1) If they have general-purpose network access, they are a tool to build
>>> a DDOS botnet, or a botnet to launch attacks against vulnerable servers.
>>>
>>> 2) If they do not have general-purpose network access, this can be worked
>>> around with DNS rebinding. Note that ordinarily, DNS rebinding is only
>>> considered a risk for content protect by network position. But in the case
>>> of a DDOS or attempt to hunt for server vulnerabilities, this doesn't matter
>>> - the attack doesn't depend on the DDOS node sending credentials.
>>>
>>> 3) If they have notification capabilities, they can be used for
>>> advertising spam.
>>>
>>> 4) If they have general network access only while a page from the same
>>> domain is displayed, then they can use a misleading notification to trick
>>> the user into going to a page on that domain, to gain network general
>>> network access at the moment it's needed.
>>>
>>> 5) Even if they only have same-domain network access, they can be used to
>>> create a botnet for computation - for example for purposes like distributed
>>> password cracking.
>>>
>>> 6) They can be used to greatly extend the window of vulnerability from
>>> visiting a malicious site once. Consider the model where a browser patches a
>>> security vulnerability, and users apply the patch over some period after
>>> it's released. Assuming the vulnerability wasn't already known to attackers,
>>> users are at risk if they visit a malicious site in the period between
>>> release of the patch and install of the patch. But with persistent workers
>>> (or background pages) in the picture, users can be vulnerable if they have
>>> *every* visited a malicious site - because it could have installed a
>>> persistent worker that periodically "phones home" for exploit code to try.
>>> This can greatly increase the number of people who can be affected by a
>>> malicious web page, and therefore greatly increases the incentive to try
>>> such a thing. This works even with just same-doman network access. I think
>>> this risk is really serious because it makes every future browser
>>> vulnerability much more dangerous.
>>>
>>> 7) Even with only same-domain network access, the persistent worker could
>>> periodically "phone home" to allow tracking of the user by IP, which can be
>>> mapped to an approximate physical location. Normally, a page you don't have
>>> open can't do that to you.
>>>
>>> This list isn't necessarily exhaustive, I'm sure there's more risks I
>>> haven't thought of, but note that most of these problems are not resolved by
>>> limiting networking to same-domain.
>>>
>>> I don't think a permissions dialog could possibly adequately explain
>>> these risks, and in any case many users blindly click through alert dialogs.
>>> The risks are subtle but nonetheless outside user expectations for a web
>>> application.
>>>
>>> I do think offering a feature like this in the context of an application
>>> or extension style install experience might be acceptable - specifically an
>>> experience that is explicitly initiated by the user with multiple
>>> affirmative steps. But web features are not usually designed around such an
>>> expectation, usually this is the hallmark of a proprietary platform, at
>>> times also including central vetting and revocation capabilities.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090729/c44f0841/attachment-0002.htm>