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

[Maciej Stachowiak]

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