Re: CSP policy for navigation events

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