Re: Remove paths from CSP?

On 12-Feb-14 15:27, Mike West wrote:
>
> Just for clarity up top, I understand your concrete suggestions to be:
>
> 1. Remove reporting.
> 2. Block resources in such a way as to make the page believe that the
> load was successful (for example, by populating
> 'naturalWidth'/'naturalHeight' for blocked images).

Yes. The page doesn't have to believe the load is successful, just
indistinguishable from a normal load attempt (which might fail for other
reasons).

> * let's say http://service.com/sekritimage.jpg redirects to
> http://service.com/login if you're not logged in. Loading that via an
> <img> element will reveal whether you're logged in or not, as the former
> URL is an image, and the latter isn't. It will do so regardless of CSP,
> for that matter. This is not uncommon.
>
> * style's "interaction" with the page are trivially detectable by
> querying the CSSOM to get element style details.
>
> * script's "interaction" with the page changes the environment in ways
> that are generally detectable (globals, event handlers, effects on DOM,
> etc).

These kind of resources are already detectable on vulnerable websites,
without CSP. Websites which care, may fix this. That many websites have
such holes, is not an argument that we should build this hole into
browsers. What CSP does is to automate this attack, and make it
impossible for web sites to fix this. However, these kind of resources
are not important.

> You agree at the bottom of the email that some effects will be
> detectable, but claim that detection will be heuristics-based and flaky.
> I think you're underestimating sites' ability to query their own state.

Data resources, such as HTML documents and JSON do need login
protection. These are harder to detect if they have loaded, and
detection of these is flaky, and relying on side channels. CSP as
currently specced would change this. Sites need to protect such
documents, and cannot avoid the problem introduced by CSP.

Even if positive detection (site loaded) might be possible, negative
detection (site not loaded) is a much harder problem to solve. Timeouts
increase the attack time manyfold, and there may be other reasons for
loading failure than CSP. By giving direct access to negative detection,
CSP makes this much easier.

I stand by my statement that detecting meaningful (i.e. data) cross
domain loads is flaky and heuristics based.

> Additionally, I think you're incorrect to claim that anything we're
> discussing here "prevent[s] great security". The worst-case scenario
> we're discussing is reading redirection target paths cross-origin. The
> bad-case scenario we're discussing is reading redirection target origins
> cross-origin. I agree that these are bad things.

If they are bad, then they must surely prevent greatness? (For suitable
definitions of bad and great.)

> We should fix them.
> That said, even if we end up with both of these, fully exploitable,
> forever, I'd still claim mitigation of XSS to be more important. :)

Facts first:
XSS prevention is important. CSP will not prevent XSS, but will make XSS
prevention easier. XSS prevention is possible without CSP. CSP (as
specced today) will open a new hole in the same domain policy, which
cannot be closed by web sites. Many web sites have this hole already.
CSP can be made without this hole, although with less error reporting
functionality. Forever is a long time.

Phishing is bigger problem than XSS, according to experts[1][2][3].
Knowing where a user is logged in aids phishing. CSP as currently
specced makes this possible. We don't know which direction the web will
involve in, new attack forms may (will) be developed.

My conclusion:
Opening up the new hole is not worth it. What we lose is error reporting
functionality and implementation simplicity.


[1]
http://www.scmagazine.com/phishing-remains-most-reliable-cyber-fraud-mechanism/article/248998/
[1] http://www.proofpoint.com/uk/topten/index-roi.php
[2]
http://www.invincea.com/wp-content/uploads/Invincea-spear-phishing-watering-hole-drive-by-whitepaper-5.17.13.pdf

-- 
Sigbjørn Vik
Opera Software

Received on Thursday, 13 February 2014 08:51:18 UTC