Re: CSP policy for navigation events

(Instead, the focus of CSP3 is more on preventing script execution in the
first place by allowing developers to deploy safer policies with nonces,
hashes, 'strict-dynamic' and more granular whitelisting
<https://www.chromestatus.com/feature/5141352765456384> of scripts and
styles.)

On Sat, Oct 20, 2018 at 1:52 PM Artur Janc <aaj@google.com> wrote:

> On Sat, Oct 20, 2018 at 1:35 PM José Moyano Gutiérrez <
> jgutierrez.mo@gmail.com> wrote:
>
>> 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?
>>
>
> As far as I know this isn't really a goal of CSP3. It would likely be
> possible to cover some of the mechanisms you mentioned above with new
> directives (AFAIK +Devdatta is interested in restricting postMessage), but
> my guess is that given the fairly broad whitelists most developers use for
> their applications, it would very often be possible to exfiltrate data via
> one of the origins trusted by CSP. For example, if the application stores
> any data that is later visible to other users, the attacker could use their
> injected script to save the data in the victim's public profile so that the
> attacker could access it directly.
>
> Given that new anti-exfiltration features would run into these issues in
> most non-trivial applications, I believe that there isn't a lot of
> implementer interest in this area.
>
> Cheers,
> -Artur
>
>
>> 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*
>>
>