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

Re: CSP policy for navigation events

From: Artur Janc <aaj@google.com>
Date: Sat, 20 Oct 2018 13:56:51 +0200
Message-ID: <CAPYVjqpF00GQ5ujN-uEF0DXOV2cP8gQZVD-esP1OUDjT0uH8fw@mail.gmail.com>
To: José Moyano Gutiérrez <jgutierrez.mo@gmail.com>
Cc: Mike West <mkwst@google.com>, Sergey Shekyan <shekyan@gmail.com>, WebAppSec WG <public-webappsec@w3.org>, Devdatta Akhawe <dev.akhawe@gmail.com>
(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*
>>
>
Received on Saturday, 20 October 2018 11:57:25 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 20 October 2018 11:57:25 UTC