- From: Mike West <mkwst@google.com>
- Date: Mon, 15 Oct 2018 09:35:53 +0200
- To: Sergey Shekyan <shekyan@gmail.com>
- Cc: jgutierrez.mo@gmail.com, Web Application Security Working Group <public-webappsec@w3.org>
- Message-ID: <CAKXHy=fun5qUCniBAx8pbtu6n9+5U_PTfgrFY00uiW866Qy7dA@mail.gmail.com>
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 07:36:27 UTC