Re: Proposal: A pinning mechanism for CSP?

So far our threat model has always been that CSP is a defense in
depth, and that the ability to set headers wins.  Even the policy
combination logic was designed more with the idea of friendly
processes unwittingly adding multiple policies, not really so much
malicious policy injection.  Only meta policy injection is intended to
be hardened against injection.

We also know that CSP currently is not a full confinement solution.
Deian's work on COWL as it applies to CSP can help us get there, but
again, without and before that, a compromise of the same-origin script
capability is still a TCB-equivalent compromise that CSP can't really
stop.

So I don't meant to sound pejorative when I say I am dubious about the
threat model - just consider it my own failure of imagination to
understand the precise nature of the threats it would mitigate.
Examples would help me out here.

e.g., Attacker can set X header but not Y header, and this is a likely
attacker capability set because of failure pattern Z.  With an
irrevokable CSP pin, we can prevent this class of attacker from
achieving goal G.


On Fri, Jan 23, 2015 at 7:40 PM, Jim Manico <jim.manico@owasp.org> wrote:
> Brad,
>
> I think your comment "somewhat dubious threat model" insinuates where
> you stand on this and that's cool. I think the risk of response header
> splitting and similar is also "dubious" and feel the need for a
> response header pin over-riding a manifest-like pin to be important
> for developer ease of use, at least.
>
> How can we take these ideas and build a more formal and publishable
> threat model? I am the noob around here, at best, but I'd like to help
> somehow.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>
>> On Jan 23, 2015, at 13:54, Brad Hill <hillbrad@gmail.com> wrote:
>>
>> somewhat dubious threat model

Received on Saturday, 24 January 2015 05:20:04 UTC