Handle Content-Security Policy (CSP) violation reports

[benvinegar]

Content-Security Policy (CSP) is a new browser feature that makes it possible to restrict JavaScript files and other assets to a trusted set of origins:

http://www.html5rocks.com/en/tutorials/security/content-security-policy/
http://www.w3.org/TR/CSP/

CSP has a reporting mechanism whereby violations can be automatically POSTed by the browser to a reporting endpoint. It would be awesome if Sentry supported CSP violation reports, making it super easy for Sentry users to identify and track CSP violations (e.g. possible XSS attacks).

More on CSP's reporting mechanism:

http://www.html5rocks.com/en/tutorials/security/content-security-policy/#reporting
http://www.w3.org/TR/CSP/#sample-violation-report

[dcramer]

One note: need to figure out how security is handled here (is there an Origin? Referrer?)

[christianvuerings]

+1

[xncoder]

+1

[oreoshake]

@dcramer there is a referrer, origin is null, cookies will be stripped unless allowed by CORS.

http://www.w3.org/TR/2013/WD-CSP11-20130604/#sample-violation-report

[joostdevries]

+1 a lot.

[hd-deman]

+1

[36degrees]

+1

[joostdevries]

anyone working on a pr for this?

[mattrobenolt]

@joostdevries I was, then realized that this is a mess.

• A browser can make tons of requests to this, so we'd just be getting DDoS'd 24/7.
  • A separate HTTP request is made for every single violation. In my initial testing in my normal browser without touching anything, I put a strict CSP rule on a page and it made like, 12 HTTP requests to report the problems. One for every single browser plugin I had that tried to modify the page or something.
• How do we aggregate and report on this?
• How does this look in the UI?

Imagine every visitor to your site making 12+ error reports to Sentry on every page load. getsentry.com wouldn't be able to handle that and I doubt anyone trying to do this at any scale with lots of page views would die as well. I think there needs to be a lighter more specific mechanism for logging these. Treating them as a normal exception might not be the right approach here.

[alex]

@mattrobenolt it seems like they should be aggregated by {url, asset}, or maybe just {asset}; URLs might need to be turned into patterns somehow?

[alex]

(Also, anything that we come up with here probably makes sense for HTTP Public-key-pinning as well)

[dcramer]

@alex I think the main concern was just the volume of data. There doesn't seem to be a way to sample/restrict it, and JS events are already pretty high volume (I imagine this being higher).

This is more of a concern for getsentry.com, but until we have a really solid "you're going to pay us for the CPU you cost us" solution it's a bit scary to offer something like this. I see it in a similar vein as HTTP 404 logging.

[mattrobenolt]

Yeah, I think there's just a lack of information here so far. I should probably start tracking it somewhere just to collect data and see where we're at and what sense I can make of it. It's definitely a thing we should figure out though, I agree.

[mattrobenolt]

And yes, volume of data can be ridiculous, but I think can be solved.

[alex]

So, the primary use case I'm interested in is helping site maintainers detect resources that are inadvertantly accessed over HTTP, when they have a theoretically HTTPS-only site, to help them avoid mixed content warnings.

It seems like that use case can probably be acheived with less data. Are there other important use cases?