Re: CSP policy for navigation events

Something to keep in mind is that while navigate-to solves the immediate
problem of restricting navigations, it does not prevent attackers from
exfiltrating data once they have achieved script execution with XSS.

For example, an attacker can still use the postMessage API to send
arbitrary data to windows/frames she controls, or use some of the other
techniques outlined here
<https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0012.html>.
In practice, most websites also allow requests to URLs of their JS widgets
(e.g. analytics libraries) to which the attacker can send requests to store
exfiltrated data and then retrieve it out of band (e.g. by interacting with
the analytics library's UI).

This is orthogonal to the value of restricting navigations, but I figured
I'd mention it just in case :)

Cheers,
-Artur

On Mon, Oct 15, 2018 at 9:38 AM Mike West <mkwst@google.com> wrote:

> 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*
>>>
>>