Re: Remove paths from CSP?

> Let me repeat myself: That an exploit works against many sites, is not a
> valid argument to build that security hole into browsers by default.

It's already built in. In the same way, we designed CORS to
essentially not add new holes, but arguably preserve the existing ones
(which lead to XSRF bugs), since preventing them within CORS alone
would be counterproductive, and fixing them elsewhere would require
fundamental changes to how the web operates.

I think it's a common theme in the design of web security mechanisms,
and while arguably "it's already broken, so we're not making it worse"
is a pretty poor argument, it's often the only viable way to go. On
balance, there is little doubt in my mind that CORS, postMessage,
sandboxed frames, CSP, subresource integrity, per-page suborigins, and
many other similar mechanisms offer net security benefits - even
though they all make substantial trade-offs that carefully tread the
line of "not making it worse".

> Protecting against side channels from image and script loads is trivial
> for web sites which care.

I'm not sure I agree with this?

> My suggestion is that browsers pretend the resource loaded. E.g. CORS
> and XHR have lots of behaviour just like this, where the real state of
> the load attempt is never revealed to the document. Copying such
> features across to CSP hardly seems impossible.

All of them reveal this information; XHR can fail synchronously or
near-instantly, can take few ms indicating cache read, or dozens to
hundreds ms to indicate network load. Timing aside, the fact that a
request is being made can be also inferred by measuring how many
(intentionally slow) requests can be performed in parallel, because
most browsers have per-host request caps to prevent DoS. And that's
just a tip of an iceberg, I think...

/mz

Received on Wednesday, 26 February 2014 17:41:11 UTC