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