Re: Remove paths from CSP?

On 26-Feb-14 18:40, Michal Zalewski wrote:
>> 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.

I will agree that a weaker version is already built in, but not a
version as potent as CSP. Many sites can be exploited without CSP, but
even more with it.

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

That CSP violates this principle is one of the reasons I don't like the
current spec. Most sites can already be exploited, but not all. With CSP
more sites can be exploited, so we are making it worse, adding a hole
that wasn't there before.

Consider a site against which timing attacks don't work (or work very
poorly). For whatever reason; flaky connection, protections added by the
site admins, upstream gateway, it only accepts a few connection attempts
before hard failing, protections/noise on client computers... Assume not
logged-in users are redirected to the login subdomain. Without CSP, this
site does not reveal logged-in information, with CSP (as currently
specced), it does, and trivially so.

If CSP instead were to pretend that the redirected resource loaded as
normal, we'd be back to exploiting the same timing attacks as before
(which don't work in this case), and we are not making the problem 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?

Static resources such as images and scripts don't need login protection,
and can be served identically to logged-in and not logged-in users.

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

It is possible to guess the information from side channels, but these
technologies do not explicitly tell the web page. This is the same model
we should adapt for CSP. The point here is that the browser always gives
the same message to the web page, regardless of what actually happened
in the background. What you are describing is a standard principle in
designing cross domain specifications, one which should also be applied
to CSP.

-- 
Sigbjørn Vik
Opera Software

Received on Thursday, 27 February 2014 08:59:35 UTC