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

Re: CSP policy for navigation events

From: Sergey Shekyan <shekyan@gmail.com>
Date: Sun, 14 Oct 2018 20:25:19 -0700
Message-ID: <CAPkvmc_vV9waYGHbxKbMH0hPjx8JTMT5hcNF=KXaU70xq6qR6A@mail.gmail.com>
To: jgutierrez.mo@gmail.com
Cc: public-webappsec@w3.org
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 03:25:54 UTC

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