Re: Signed CSP

I've also thought about "signed CSP" for developers who wish to sign files with an offline key and talked to Mike West about it previously, but I am now convinced this is a better fit for the packaging spec than CSP. For one, I don't see much use in signing javascript files unless the entire application is signed; an attacker who can manipulate the HTML of the page embedding the javascript is usually as powerful as an attacker who can manipulate the javascript.

Installable web apps today (Firefox extensions, Chrome apps, etc.) often have offline signatures anyway, so it's not a far stretch to say that we should standardize this in a way that works for generic web packages.

See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0371.html for the thread about this on the packaging list.

On Sunday, February 15, 2015 9:49 PM, Crispin Cowan <crispin@microsoft.com> wrote:



I don’t see how CSP helps as a place to start. Suppose you create a perfect PKI that lets clients recognize sever CSPs that are “in the club” (no easy feat in itself). That only prevents the attacker who p0wns the server from changing the CSP, it does not stop them from changing all the rest of the content, which can have quite bad effects on the user.
 
Even if it prevents the attacker from *changing* the CSP, it does not prevent them from *deleting* it. If the CSP is an obstacle for the attacker, they will just remove it.
 
So instead of delving into mechanism just yet, what semantics are you trying to achieve? A threat model that assumes a compromised server is very challenging to get right.
 
From:Scott Arciszewski [mailto:kobrasrealm@gmail.com] 
Sent: Sunday, February 15, 2015 6:15 PM
To: Michal Zalewski
Cc: Crispin Cowan; public-webappsec@w3.org
Subject: Re: Signed CSP
 
> CSP is probably not the right place to solve it.
Fair point. I was using this as a starting point because it seemed like a logical place to begin.

> You'd probably just want a signature attached as an extra HTTP header or so, with a browser add-on plugging into the HTTP stack and taking care of the validation steps.
By this, I assume you mean the whole meta idea of verifying the script hashes and whitelisting redirects (an idea I hadn't considered)?
What would we even call this then, if it's not to be tied in with CSPs?
 
On Sun, Feb 15, 2015 at 9:10 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
So your model is to have a manually curated whitelist of trusted keys;
>and then use a browser that refuses to load any Internet content at
>all unless it is signed with one of these (hopefully offline) keys?
>
>The "can't navigate anywhere else" seems like a prerequisite, because
>otherwise, what stops pwn3d.com from just a 30x redirect to evil.com,
>and letting evil.com do any fingerprinting / decloaking it wants? (In
>fact, for optimal safety, you'd probably want a whitelist of keys
>*and* of navigable origins).
>
>This seems like an incredibly narrow / impractical use case, with a
>whole lot of new browser logic to tackle on, and even then, CSP is
>probably not the right place to solve it. You'd probably just want a
>signature attached as an extra HTTP header or so, with a browser
>add-on plugging into the HTTP stack and taking care of the validation
>steps.
>
>/mz

Received on Tuesday, 17 February 2015 20:39:47 UTC