Re: Reducing reporting noise

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
>
>