W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2012

Re: Trigger a DOM event/error when a CSP violation happens.

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Tue, 27 Nov 2012 13:50:28 -0800
Message-ID: <CAPfop_3XJCCCLBU02j14_SpTmHBZXHWQLeMTo0rWXspF_g-YhQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "Eduardo' Vela" <evn@google.com>, Daniel Veditz <dveditz@mozilla.com>, public-webappsec@w3.org, Adam Barth <w3c@adambarth.com>
> Regarding opt-in vs opt-out, I proposed opt-in because I had a good idea
> about the syntax that seemed clear and understandable. I'd agree that the
> general case doesn't seem to be problematic, though, so I'd be interested in
> alternatives. Do you have a suggestion for how opt-out might look?
>

I am not even sure opt-out is needed: you can just not set a handler
if you don't want the events. Only case where opt-out might be needed
seems to be "code running is untrusted, and I want to monitor it using
CSP, but don't tell the code about it" Not sure if thats a useful
use-case, or whether not raising an event can actually prevent the
code from learning the policy. There might be other channels to learn
the policy ("did it load?")

But I am not sure if I am missing some threat.


--dev


> --
> Mike West <mkwst@google.com>, Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
>
> On Tue, Nov 27, 2012 at 10:34 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>>
>> What about triggering a DOM event by default, and
>> (possibly) allowing opt-outs?
>>
>> Am I missing a threat?
>>
>> --dev
>>
>> On 22 November 2012 11:43, Mike West <mkwst@google.com> wrote:
>> > You can add more than one endpoint to the report-uri directive, so yes,
>> > this
>> > suggestion would support that use case as (for instance) `report-uri
>> > 'self'
>> > /report-collection-url.cgi`.
>> >
>> > --
>> > Mike West <mkwst@google.com>, Developer Advocate
>> > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>> >
>> >
>> > On Thu, Nov 22, 2012 at 7:11 PM, Eduardo' Vela <evn@google.com> wrote:
>> >>
>> >> Could it be possible to get both? A report-uri and the DOM errors?
>> >>
>> >> That way we can deploy one policy on a large set of apps and if we need
>> >> to
>> >> debug one in particular we just ask that one to monitor the script.
>> >>
>> >> On Nov 22, 2012 4:36 AM, "Mike West" <mkwst@google.com> wrote:
>> >>>
>> >>> I've talked to a few developers about deploying CSP, and the request
>> >>> for
>> >>> some form of violation DOM event has popped up several times. It's
>> >>> something
>> >>> I'd like to implement if we can find a good way of making it work.
>> >>>
>> >>> What do you think about making such a feature an opt-in portion of the
>> >>> policy by adding a `'self'` keyword to the `report-uri` directive? If
>> >>> the
>> >>> keyword is set, violation events would be fired at the
>> >>> `document.securityPolicy` object; if not, no violation events would
>> >>> fire for
>> >>> that policy.
>> >>>
>> >>> That mechanism might actually also give vendors a mechanism of
>> >>> directing
>> >>> violations of extensions' policies to the extension rather than the
>> >>> page by
>> >>> interpreting 'self' in some reasonable way.
>> >>>
>> >>> --
>> >>> Mike West <mkwst@google.com>, Developer Advocate
>> >>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> >>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>> >>>
>> >>>
>> >>> On Sat, Oct 27, 2012 at 12:53 AM, Dan Veditz <dveditz@mozilla.com>
>> >>> wrote:
>> >>>>>
>> >>>>> On Wed, Oct 24, 2012 at 11:18 PM, Eduardo' Vela <evn@google.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> We have found a lot of challenges triaging reports to the point we
>> >>>>>> are
>> >>>>>> considering disabling CSP since it's useless as we can't
>> >>>>>> effectively
>> >>>>>> debug
>> >>>>>> it, this is very important for large scale applications.
>> >>>>
>> >>>>
>> >>>> Are you trying to debug a broken application, or figure out where
>> >>>> injected content is coming from?
>> >>>>
>> >>>> I'm sympathetic to your need and it may be worth experimenting with,
>> >>>> but
>> >>>> I would not want user-applied CSP to report to the page. At least not
>> >>>> detectably as a "CSP" error; if we want to fire normal existing
>> >>>> onerror=
>> >>>> handlers for images that don't load that may be fine.
>> >>>>
>> >>>> I'm not sure what to do about extension-supplied CSP. Again, I would
>> >>>> not
>> >>>> want it reporting to the page, but it would be handy if there were a
>> >>>> way to
>> >>>> report it to the extension. I'm sure extensions can root around in
>> >>>> the web
>> >>>> console messages and find it, but a more direct API might be good.
>> >>>>
>> >>>> Such APIs would be out of scope for this WG so I'd just like to state
>> >>>> the privacy principal that user-agent supplied policies do not report
>> >>>> violations to the originating server or page content. I'm not against
>> >>>> firing
>> >>>> events at the page for violations of the page's own policy.
>> >>>>
>> >>>> -Dan Veditz
>> >>>>
>> >>>
>> >
>
>
Received on Tuesday, 27 November 2012 21:51:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 November 2012 21:51:17 GMT