Re: Proposal: A pinning mechanism for CSP?

>> Also, includeSubdomains crosses the origin security boundary.
>
> Indeed. But owning `example.com` is a pretty good indication that you
> have control over `*.example.com`. This is especially true if we take
> the PSL into account.

I don't think that's the case, and the PSL (and other initiatives,
like DBOUND) seem to speak otherwise.

I don't disagree that many domains hold the administrative
relationship you desire. But there seems to be some exceptions for
high traffic sites that make the risk non-trivial. A site like
blooger. com is one domain with 100's of thousands to millions of
separate administrative domains. That's quite a multiplier.

And if a site like blogger.com is a subordinate CA that can issue
certificates, then that's 100's of thousands to millions of things
that can go wrong to undermine the flow of trust.

(And in reality, it only takes 1 of those 100's of thousands to
millions. The trust model is only as strong as the weakest link; cf.,
Trust Extortion on the Internet,
http://folk.uio.no/josang/papers/Jos2011-STM.pdf).

> I'd justify crossing the origin boundary here by noting that
> subdomains can act as their parent domains via `document.domain`, and
> cookies cross the origin/host boundary with abandon. Given that we
> wish to protect against abuse of both, allowing explicitly pinned
> policies to take effect over that boundary seems reasonable.

For service workers, I imagine when things go wrong, they are likely
to do so in a some sort of (semi-)privileged context. That means it
won't be the browser that's pwn'd - it will probably be something of
higher value like a service account or device that is pwn'd.

I'm aware they are described as "A service worker is a script that is
run by your browser in the background". I think its a good logical
description, but I imagine the implementation is going to be a bit
different. For example, I could image a browser instance started under
the `shell` account on Android to ensure the service worker could read
and write files it otherwise would not have access to. Or I could
imagine a whole new implementation without the GUI bells and whistles
supplied by the platform or operating system.

I don't think its wise to forgo the security controls built for the
model. The model leaves something to be desired at times and the
controls leaves something to be desired at times. But at least they
provide some containment when coupled with other measures, like
isolation and unprivileged contexts.

Or will there be changes to the model and policies, like executing
non-local Javascript code in a (semi-)privileged context is forbidden
unless explicitly allowed? (And none of that authentication =
reputation or authentication = authorization funny business).

So I think it would help if the model were explained in more detail -
like how exactly are service workers going to be implemented by a
platform or operating system, and what are the controls that are going
to be used. But I don't think those questions can be answered yet.

Received on Thursday, 16 April 2015 04:12:35 UTC