Re: Proposal: A pinning mechanism for CSP?

> 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.

As an attacker, if I can inject content into the site that causes
response splitting, I could inject my own pinning response header and
override or cancel the current pin assuming that the header takes
priority over the current pin.

Again, I'm hesitant to keep up this conversation until I do more
homework and understand these standards better.

But as I think about this, I'm inclined to vote for better security
and make pins irrevocable (which is not true today, max-age drops
existing pins?). As a developer, I'm also inclined to make pinning
max-age •very low• until I'm certain my pinning headers are totally
correct if the long term route is irrevocable pinning.

Brad, if I'm getting terms or technology wrong here, please drop me a
note off-list and I'll stand down. These are my initial efforts to
participate intelligently on this list and I'm certain to stumble at
first.

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

> On Jan 23, 2015, at 21:19, Brad Hill <hillbrad@gmail.com> wrote:
>
> 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:30:50 UTC