{"id":12083,"date":"2019-03-14T10:02:17","date_gmt":"2019-03-14T15:02:17","guid":{"rendered":"https:\/\/rud.is\/b\/?p=12083"},"modified":"2019-03-14T10:02:17","modified_gmt":"2019-03-14T15:02:17","slug":"collecting-content-security-policy-violation-reports-in-s3-effortlessly-freely","status":"publish","type":"post","link":"https:\/\/rud.is\/b\/2019\/03\/14\/collecting-content-security-policy-violation-reports-in-s3-effortlessly-freely\/","title":{"rendered":"Collecting Content Security Policy Violation Reports in S3 (‘Effortlessly’\/’Freely’)"},"content":{"rendered":"

In the previous post<\/a> I tried to explain what Content Security Policies (CSPs) are and how to work with them in R. In case you didn’t RTFPost the TLDR is that CSPs give you<\/em> control over what can be loaded along with your web content and can optionally be configured to generate a violation report for any attempt to violate the policy you create. While you don’t need<\/em> to specify a report URI you really should since at the very least you’ll know if you errantly missed a given host, wildcard, or path. You’ll also know when there’s been malicious or just plain skeezy activity going on with third-parties and your content (which is part of the whole point of CSPs).<\/p>\n

There’s an “R” category tag on this post (so it’s hitting R-bloggers, et al) since it’s part of an unnumbered series on working with CSPs in R and the next<\/em> posts will show how to analyze the JSON-formatted reports that are generated. But, to analyze such reports you kinda need a way to get them<\/em> first. So, we’re going to setup a “serverless” workflow in Amazon AWS to shove CSP reports into a well-organized structure in S3 from which we’ll be able to access, ingest, and analyze them.<\/p>\n

Sure, there are services out there who will (legit for free) let you forward violation reports to them but if you can do this for “free” on your own and not give data out to a third-party to make money or ostensibly do-gooder reputation from I can’t fathom an argument for just giving up control.<\/p>\n

Note that all you need<\/em> is an an internet-accessible HTTPS endpoint that can take an HTTP POST request with a JSON payload and then store that somewhere, so if you want to, say, use the plumber<\/code> package to handle these requests without resorting to AWS, then by all means do so! (And, blog about it!)<\/p>\n

AWS “Serverless” CSP Report Workflow Prerequisites<\/h3>\n

You’re obviously going to need an Amazon AWS account and will also need the AWS Command Line Interface<\/a> tools installed plus an IAM user that has permissions to use CloudFormation<\/a>. AWS has been around a while<\/em> now so yet-another-howto on signing up for AWS, installing the CLI tools and generating an IAM user<\/a> would be, at-best, redundant. Amazon has decent intro resources<\/a> and, honestly, it’s 2019 and having some familiarity with how to work with at least one cloud provider is pretty much a necessary skillset at this point depending on what part of “tech” you’re in. If you’re new to AWS then follow the links in this paragraph, run through some basics and jump back to enter the four<\/em> commands you’ll need to run to bootstrap your CSP collection setup.<\/p>\n

Bootstrapping an S3 CSP Collector in AWS<\/h3>\n

We’re going to use this CloudFormation workflow<\/a> to bootstrap the CSP collection process and you should skim the yaml file<\/a> to see what’s going on. Said yaml is “infrastructure as code”, meaning it’s a series of configuration directives to generate AWS services for you (i.e. no pointing-and-clicking) and, perhaps more importantly, destroy them for you if you no longer want to keep this active.<\/p>\n

The CF Output directive<\/a> will be the URI you’re going to use in the report-uri<\/code>\/report-to<\/code> CSP directives and is something we’ll be querying for at the end of the setup process.<\/p>\n

The first set of resources<\/a> are AWS Glue<\/a> templates which would enable wiring up the CSP report results into AWS Athena<\/a>. Glue is a nice ETL framework but it’s kinda expensive if set in active mode (Amazon calls it ‘crawler’ mode) so this CloudFormation recipe only created the Glue template but does not activate it. This section can (as the repo author notes) be deleted but it does no harm and costs nothing extra so leaving it in is fine as well.<\/p>\n

The next bit<\/a> sets up an AWS Firehose<\/a> configuration which is a silly sounding name for setting up a workflow for where to store “streaming” data. This “firehose” config is just going to setup a path for an S3 bucket and then setup the necessary permissions associated with said bucket. This is where we’re going to pull data from in the next post.<\/strong><\/p>\n

The aforementioned “firehose” can take streaming data from all kinds of input sources and our data source is going to be a POSTed JSON HTTP interaction from a browser so we need to have something that listens for these POST requests and wire that up to the “firehose”. For that we need an API gateway<\/a> and that’s what the penultimate section<\/a> sets up for us. It instructs AWS to setup an API endpoint to listen for POST requests, tells it the data type (JSON) it will be handling and then tells it what AWS Lambda<\/a> to call, which is in the last section<\/a>.<\/p>\n

Said lambda code is in the repo’s index.js<\/a> and is a short Node.js script to post-process the CSP report JSON<\/a> into something slightly more usable in a data analysis context (the folks who made the violation report clearly did not have data science folks in mind when creating the structure given the liberal use if -<\/code> in field names).<\/p>\n

If the above sounds super-complex just go get CSP reports, you’re not-wrong.<\/strong> We trade off the cost and tedium of self-hosting and securing a standalone-yet-simple JSON POST handling server for a moderately complex workflow that involves multiple types of moving parts in AWS. The downside is having to gain a more than casual familiarity with AWS components. The plus side is that this is pretty much free unless your site is wildly popular and either constantly under XSS attack or your CSP policy is woefully misconfigured.<\/p>\n

“‘Free’, you say?!”<\/em> Yep. Free. (OK, “mostly” free)<\/p>\n