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

Re: CSP policy for navigation events

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

This archive was generated by hypermail 2.3.1 : Monday, 15 October 2018 07:36:28 UTC