Re: Reducing reporting noise

I'm super unpopular when it comes to opinions like this as I feel the
ideas proposed are out of scope. I feel it's the job of the reporting
endpoint to make the decision to drop a report on the floor. I realize
this is not consistent with the goal of reducing the number of reports
sent, but hey.

Given that I've lost this battle everytime, I could definitely get
behind some client-side dedup'ing. If a report is identical to a
previously triggered alert, don't sent it. It would be great to have a
"count" field that indicates how many times a given report is fired
for a given uri, but this probably introduces other complications and
canceled requests (can beacon help here?).

With client-side limitations/sampling, I worry about innocuous
things/extensions hiding real issues. With the throttle-based
approach, the law of averages should nullify this concern. If I had to
pick between the choices presented, I'd prefer the "throttling
reports" route.

Lastly as an fyi, teams supporting mobile clients have asked for
something like this due to the limited number of connections and
assumed increased latency.

On Thu, Jun 19, 2014 at 3:35 PM, 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 Friday, 20 June 2014 02:01:24 UTC