Add a flag to strip potentially sensitive data from reports

[ScottHelme]

CSP reporting is incredibly useful and provides heaps of valuable data, but it can be difficult for smaller sites to implement. This was my main motivating factor in building https://report-uri.io, a free CSP reporting service.

In the course of running this service I've come to terms with lots of odd browser behaviours and created a fairly robust set of filters to eliminate both noise and potentially sensitive information in reports.

I recently came across an issue where a report was being sent from a page that contained sensitive information in the URL as a query string. As the recipient of the report, report-uri.io had access to this sensitive information. With the above filters the query string is stripped at my edge and never hits storage, nor do I inspect or use the data for any other purposes, but it would be nice if the host had the ability to limit the information sent in the report. As more and more sites use CSP reporting, and CSP reporting as a service increases in popularity, this issue seems like it will only get bigger.

Could we have some way of limiting the data sent in a report? The first thing that jumps to mind is the ability to strip the fragment and/or query string from locations like the referrer, document-uri and blocked-uri. We could be flexible and even strip the path or provide the option to not send the referrer at all.

Given the nature of CSP reporting I don't think we can work on the assumption that reports will be sent to an endpoint under the control of the organisation.

[annevk]

If we do anything here we'd have to find a way to hide the URL entirely. Otherwise we're not really solving the capability URL problem (e.g., GitHub Gists, private GitHub repositories).

[nico3333fr]

It is a good idea, I've also found some bugs on some browsers that clearly transfer some informations that webmasters users should NOT be aware of: in some cases, I can know the visitor is using Ghostery (!) or some other extensions.
It could be also interesting to motivate people to choose secured URLs for report-uri. (it can be too bad that sensitive informations could be sent in clear by the browser)

[ScottHelme]

@annevk which URL would that be, the document-uri? If you didn't want a URL reporting in the document-uri would the answer not be to disable reporting on that particular page? The report could be close to useless without information on which page it happened on, no?

@nico3333fr I like the idea of using a secure URL for the report-uri directive, but I'm not sure how this could be enforced. It's down to the host to specify the endpoint so I guess the best we could do is pop an error in the dev console warning that the report-uri directive is not secure?

[annevk]

@ScottHelme maybe there's some way to encrypt it in a way that only the user agent and the origin in question can get back to it. Seems like you'd especially want to know about exploits on URLs protected through some capability.

[jonathanKingston]

@ScottHelme Is there much value in the reports still if the path is also obscured as @annevk is suggesting?

I agree with @nico3333fr that having only https reporting would have been a simpler solution for this. Site owners should really trust who they are sending their reports to.

Could the URI or path be specified in the CSP? Some form of unique reference to replace the normal URI?

[ScottHelme]

@jonathanKingston I see your point, but this is already becoming a growing problem for report-uri.io and CSP deployment, let alone reporting, is minimal.

Imagine if the query string parameters contain sensitive data like a name, address, maybe card data or a password reset token. Yes, the site in question trusts me enough to send me reports but I most definitely don't want that kind of data and the ability to neutralise it at source rather than rely on me to scrub it is much preferred.

There's also many other ways that this could cause a problem like local laws, regulations or for compliance reasons. If the data isn't required to be sent, then I think we should have a way to not send it.

[jonathanKingston]

@ScottHelme agreed although I would suspect those sites are in violation of the laws anyway.

Is the unique token or encryption for the URI an option? As @annevk said the data can be embedded in the URL itself just the same. Perhaps that adds too much complexity anyway.

Giving the site owner the ability to filter down to path and/or hostname might solve most cases but then I don't see a way for a site owner to easily marry the report back to a specific problem without the token/encryption.

[ScottHelme]

@jonathanKingston I'm not sure I'm following what you mean so excuse me if my response is a little whacky!

As for encrypting, do you mean if the browser encrypted the string and I then simply provide it back to the host and they can decrypt? If so, that makes the job of the service incredibly hard as they can't do any filtering, searching, or querying based on that field.

Take the following report:

{csp-report:{
    "document-uri":"https://scotthelme.co.uk/passwordReset?token=abc123"
    ...
}

If I were to send that in a CSP report then whoever owns the password reset token is at risk. If I can strip that out of the report then the report is still just as useful and we've protected the user that owns the token. Obviously there are scenarios when the query string may be needed but giving the host an option to remove it from reports would be nice!

[jonathanKingston]

@ScottHelme it was @annevk who was suggesting the encryption however it makes sense if we actually want to get the data back. Which for the likes of Single Page Apps and other modern sites the query string could really help cut down the problem area when debugging.

However I was additionally suggesting perhaps we can get reports like:

{csp-report:{
    "document-uri":"https://scotthelme.co.uk/passwordReset"
    ...
}

and

{csp-report:{
    "document-uri":"https://scotthelme.co.uk"
    ...
}

But also:

{csp-report:{
    "document-uri":"https://scotthelme.co.uk",
    "unique-token": "2422ad858e65cd7ad7d87a9c47a7517777ec6971"
    ...
}

Or:

{csp-report:{
    "document-uri":"https://scotthelme.co.uk",
    "encrypted-uri": "881504c9eef48e9d389ffd25c164e8e84ce157e3abc6f72ae3a5a69ee6e30317..."
    ...
}

(Sorry for the length of this)

[ScottHelme]

@jonathanKingston The only problem with the encryption aspect is the added complexity. You'd need to deliver a key in the policy and have the browser do the crypto before POSTing the payload. Perhaps there would be performance concerns there too.

I like the look of the first report, couldn't we achieve that with a simple directive like strip-parameters? If the site needs the query string params then the directive could be included only on sensitive pages to cut down leakage.

[jonathanKingston]

I was hoping for both truncation solutions so you could strip what you needed. I suspect there would need to be a key so you could be aware that it's truncated too:

{csp-report:{
    "document-uri":"https://scotthelme.co.uk",
    "truncated-to": "hostname"
    ...
}

Thinking about the encryption aspect, sites that are of that size and experience would likely just encrypt on their own servers, so it's probably too complex for the usage it would get... perhaps report-uri enterprise solution for those companies😉

[ScottHelme]

You could do so with multiple directives I guess, strip-(fragment|query|path).

I don't think an extra field in the report is necessary as the browser already returns original-policy so you could see the directives in that to determine if/how it was stripped.

[estark37]

People (I can't remember who, sorry) have floated the proposal that Referrer Policy should control URLs sent in CSP reports. I'm not a huge fan of that proposal, and it also wouldn't solve this particular problem (since RP doesn't give you a way to strip just query string), but it seems related so I thought I'd bring it up.

@ScottHelme, I wonder if you've thought about distributing a JS library that listens for SecurityPolicyViolationEvents and does the reporting manually, stripping out any information you don't want? Though that would be a lot more friction for your users.

[jacobbednarz]

❤️ the intent here.

I'm not sold on using encryption as I think that would be yet another hurdle for the majority of users to get a content security policy enabled. This would also be a pain to manage when you need to dig into the report and decrypt the values it sent through.

I agree with @nico3333fr that having only https reporting would have been a simpler solution for this. Site owners should really trust who they are sending their reports to.

@jonathanKingston In this context, HTTPS is irrelevant as unless it's encrypted at rest, the transport mode isn't going to save it from being compromised or leaked once the provider has it. The motto of "Easiest way to not leak sensitive material is to not handle it" comes to mind here so I think it's great service providers like @ScottHelme are raising this instead of just trying to scrub it out.

People (I can't remember who, sorry) have floated the proposal that Referrer Policy should control URLs sent in CSP reports. I'm not a huge fan of that proposal, and it also wouldn't solve this particular problem (since RP doesn't give you a way to strip just query string), but it seems related so I thought I'd bring it up.

This sounds like one solution however not everyone is using a referrer policy so I think this may leave us in the same position and like @estark37, I'd rather keep these two concerns separate.

The only way I could see this being able to be implemented is using something like @ScottHelme's suggestion of a strip-(fragment|query|path) option that would apply to the field in question and could be altered on a page-by-page basis where needed. Perhaps a default of strip-query would be suitable for most of the use cases and should you need further debugging on a page, you could conditionally remove it? This would solve the issue of people being unaware that they are sending this sensitive information to a reporting service.

[ScottHelme]

@estark37 I have thought about it yes but I want to make the barrier to entry as low as possible. This is one of the reasons I don't like not having a reporting mode flag in the CSP report itself so I can auto detect whether the policy was enforced or not. You'd be amazed at how many people switch from report only to enforced and then email me saying the service isn't showing their reports when they simply haven't updated the reporting address! I don't think we should push that on to the user ¯_(ツ)_/¯

@jacobbednarz you couldn't be more accurate: "Easiest way to not leak sensitive material is to not handle it". I'm confident in my ability to strip this at my edge when the filter is set but the simple truth is I just don't want to. I don't want someone to have to think 'can I trust the service provider' when they don't have or need to. It should be down to the host what information they send me, not down to me to filter things they don't want me to have.

Thinking about this a little more would these restrictions only need to be applied to the'document-uri' and 'blocked-uri' field? It's down to the referring site to worry about the content of the 'referrer' field but I guess the 'blocked-uri' could also be same origin and contain sensitive GET params so perhaps we should include both of those?

Content-Security-Policy: default-src 'self'; report-uri https://scotthelme.report-uri.io/r/default/csp/enforce; report-filter strip-fragment strip-query (strip-path)