Reducing reporting noise

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 Thursday, 19 June 2014 21:50:32 UTC