W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2018

Re: CSP policy for navigation events

From: Artur Janc <aaj@google.com>
Date: Mon, 15 Oct 2018 15:07:37 +0200
Message-ID: <CAPYVjqrWcLxHPvq6JD=_faUSXDoSgrZLEKup7syxgL+4011fNA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Sergey Shekyan <shekyan@gmail.com>, jgutierrez.mo@gmail.com, WebAppSec WG <public-webappsec@w3.org>
Something to keep in mind is that while navigate-to solves the immediate
problem of restricting navigations, it does not prevent attackers from
exfiltrating data once they have achieved script execution with XSS.

For example, an attacker can still use the postMessage API to send
arbitrary data to windows/frames she controls, or use some of the other
techniques outlined here
In practice, most websites also allow requests to URLs of their JS widgets
(e.g. analytics libraries) to which the attacker can send requests to store
exfiltrated data and then retrieve it out of band (e.g. by interacting with
the analytics library's UI).

This is orthogonal to the value of restricting navigations, but I figured
I'd mention it just in case :)


On Mon, Oct 15, 2018 at 9:38 AM Mike West <mkwst@google.com> wrote:

> Indeed. I thought someone had set up auto-publishing on the repository,
> but I was wrong. Sorry about that.
> I uploaded https://www.w3.org/TR/2018/WD-CSP3-20181015/ a minute ago, and
> maybe clever folks can help me get publication more automated at TPAC next
> week.
> -mike
> On Mon, Oct 15, 2018 at 5:27 AM Sergey Shekyan <shekyan@gmail.com> wrote:
>> I believe all your concerns can be addressed by `navigate-to`
>> <https://w3c.github.io/webappsec-csp/#directive-navigate-to> directive.
>> I also believe that confusion is coming from differences between W3C
>> Working Draft last updated on Oct 10, 2016 and current Editor's Draft.
>> <https://w3c.github.io/webappsec-csp/> Not the first time:(
>> On Sun, Oct 14, 2018 at 7:28 PM José Moyano Gutiérrez <
>> jgutierrez.mo@gmail.com> wrote:
>>> Dear webappsec team,
>>> CSP v2 and v3 work great in order to prevent code injection,
>>> restricting the content sources to those that we already trust, but if this
>>> code injections is achieved by an attacker, CSP does not prevent an
>>> attacker to steal information and send it to a controlled HTTP by
>>> document.location redirection, although it does for form-src.
>>> I think document.location and any other navigation event should be
>>> covered by a specific CSP policy.
>>> This policy should not generate additional problems to the systems
>>> administrators because:
>>> A) except for the blogs, content management and specialised e-comerces
>>> or enterprise page do not need to allow navigation to a huge number of 3rd
>>> party page outside its own domain. And those pages would not frequently
>>> change.
>>> B) Administrator configuration effort will be similar as configuring a
>>> current  CSP v2 policy on its servers.
>>> There are no HTTP headers or features that currently protects user's
>>> data once code injection is achieved. CSP should be able to cover this
>>> issue without adding  to much complexity to the current CSP schema.
>>> Do not hesitate to ask for any feedback you need.
>>> Kind Regards,
>>> --
>>> *José Moyano Gutiérrez*
Received on Monday, 15 October 2018 13:08:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:04 UTC