W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Reducing reporting noise

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 24 Jun 2014 16:14:52 -0600
Message-ID: <CACQ=j+dJnA9AAgLb7Uj3=XuEUVo=K3ss4fN0wjLOET3mE+9ZNA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Jun 20, 2014 at 7:58 AM, Glenn Adams <glenn@skynav.com> wrote:

> On Fri, Jun 20, 2014 at 2:24 AM, Mike West <mkwst@google.com> wrote:
>> Any plans to share this specification? I assume it's the same non-public
>> spec that you've mentioned before? :)
> DLNA has very recently made their specifications ("guidelines") available
> to non-members at [1]. The specific guideline I refer to is the CVP-2
> device profile found in Part 5: Device Profiles. However, the requirement I
> refer to below regarding CSP is in the process of being added to this
> guideline via the DLNA General Maintenance process. I will check if I can
> disclose the exact proposed text of the change to this group before it is
> added to the published guideline.

The proposed (draft) DLNA guideline requirements related to CSP are
essentially as follows:

[Guideline] RUI-H User Agent of a CVP-2 Client MUST implement and conform
to the Content Security Policy [CSP] reference as defined by W3C HTML5

[Guideline] If a RUI-H User Agent of a CVP-2 Client allows installation of
third-party extensions or add-ons that permits the injection of third-party
content (of any form) into a Web page, then the RUI-H User Agent MUST apply
[CSP] policy directives to the third party content when those policy
directives are sourced from a RUI-H Transport Server using HTTPS.

[Guideline] When applying CSP to a third-party extension or add-on, the
RUI-H User Agent MUST NOT report policy violations unless the violated
policy directive was specified in a Content-Security-Policy-Report-Only

> [1] http://www.dlna.org/dlna-for-industry/guidelines
>> -mike
>> --
>> Mike West <mkwst@google.com>
>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>> On Fri, Jun 20, 2014 at 12:35 AM, Glenn Adams <glenn@skynav.com> wrote:
>>> At least one derived specification (that makes normative use of CSP)
>>> restricts reporting for add-on/extension violations to directives specified
>>> in a Content-Security-Policy-Report-Only header.
>>> On Thu, Jun 19, 2014 at 3:50 PM, Daniel Veditz <dveditz@mozilla.com>
>>> wrote:
>>>> One roadblock for us in convincing our web devs to roll out CSP is the
>>>> amount of noise in the reports they get. Firefox could do a much better job
>>>> playing nice with add-ons, but we won't be able to completely suppress what
>>>> they're doing and add-ons aren't the only source of content injection.
>>>> When creating a CSP-protected website you would normally adjust the
>>>> policy and fix bugs in the site until CSP reports no violations in normal
>>>> operation. After that point any CSP reports should indicate either an
>>>> attack or a bug in your site. However, in the real world people have
>>>> modified user-agents that trigger tons of spurious reports an it would be
>>>> nice if the policy could specify a way to suppress some of this reporting.
>>>> There are several approaches that could be taken. These all address the
>>>> problem in different ways and could potentially be combined, or we could
>>>> decide only one (or none!) of these is interesting.
>>>> Capping reports per page
>>>> ------------------------
>>>> If normal unmodified browsers have zero reports then any reports at all
>>>> should indicate a real attack. Modified add-on laden browsers generating
>>>> tons of inline script warnings don't tell you much, they are just noise and
>>>> load on the system. Therefore capping the reports at a small number is good
>>>> enough to diagnose real problems assuming you have a way to filter out the
>>>> noisy modified browsers.
>>>> Syntax (new directive): max-reports 5;
>>>> alternate keyword in report-uri directive:
>>>>    report-uri 'max-5' http://mysite.com/cspreports;
>>>> The keyword is more compact and /should/ be backward compatible with
>>>> old implementations, but if it's not in practice then we'll have to use the
>>>> additional directive approach.
>>>> Throttling reports
>>>> ------------------
>>>> If sites are not staffed to investigate and respond to individual CSP
>>>> reported attacks (and I expect very few are) then for a high-traffic site a
>>>> sampling approach would work to catch non-targeted mass attacks. Today
>>>> sites could manually simulate this by randomly adding the report-uri
>>>> directive X% of the time and serving the policy without the rest of the
>>>> time, but it may be useful to off-load that to the UA.
>>>> keyword approach: report-uri 'freq-XX' http://mysite/reports;
>>>>   (where XX is an integer 1-99 representing a percentage)
>>>> directive approach: report-frequency 0.10;
>>>>   (where the number is the odds of sending 0-1)
>>>> there's obviously not much point in setting the odds to 0 or 100%, just
>>>> use or don't use report-uri to get those states.
>>>> Selective reporting
>>>> -------------------
>>>> Sometimes you'd just like to reduce the noise in reporting but you
>>>> don't want to go so far as to allow the injected content or give up on
>>>> reporting. It would be nice to be able to suppress reports you already know
>>>> about but aren't going away any time soon (e.g. attempts by an ISP to
>>>> inject a tracker or ad).
>>>> I'm afraid people will want extreme flexibility with this (e.g.
>>>> suppress reports of flickr being loaded as an image but still warn if it
>>>> shows up elsewhere) but that would make the "suppress" directive exactly as
>>>> complex as the whole rest of the syntax. For now I'm proposing simply to
>>>> suppress reporting about sites no matter where they were used
>>>> dont-report flickr.com data: googleapis.com/some/path/ 'unsafe-eval';
>>>> I'm not convinced letting people suppress reports of unsafe-eval and
>>>> unsafe-inline is a good idea, just raising the possibility. We might want
>>>> to invent new keywords to distinguish 'script-inline' from 'style-inline'
>>>> if we take this approach.
>>>> -Dan Veditz
Received on Tuesday, 24 June 2014 22:15:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC