Re: CSP policy for navigation events

Mike, Artur,

thanks a lot again for your answers.
Artur, very interesting. I was aware of postMessage and that there were
other ones that still let the attacker exfiltrate data, but for sure I did
not think that we could use analytics to do it also. Neither noticed DNS
queries or other techniques mentioned were also a possible exfiltration
vectors.

I need to review all possible techniques you mentioned. You released a
whole world of possibilities/headaches to me xD
But, even taking into account how difficult is it to block all know
scenarios, I understand that CSP v3 will be made in order to also prevent
data exfiltration(as far as it is possible, of course), right?

Regards and thanks a lot for your work and your time,



El lun., 15 oct. 2018 a las 15:07, Artur Janc (<aaj@google.com>) escribió:

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

-- 
*José Moyano Gutiérrez*