Integrating hash reporting into CSP

[ddworken]

I'm wondering: Would it be feasible to have this be a part of CSP, rather than a standalone proposal? While I know generally we are hesitant to shove more things into CSP, I actually think there could be quite a bit of value in integrating this into CSP since it would unlock a new use case for this: Deploying a hash-based CSP. Currently it is rather difficult for sites to deploy hash-based CSPs since it requires that they manually calculate the hashes of all JS. If we could have CSP reports include hashes, this would make it trivial to use report-only mode to calculate a CSP header for any application, which has the potential to greatly ease adoption of CSP.

Replying to some of the points made in the explainer:

CSP enforcement and reporting happens at request-time, the current implementation does not have access to the resource hashes. That's doubly true in enforcement mode, where the resources are never downloaded (and hence the browser never knows the hash).

I think it would be reasonable if we limited hash reporting to report-only mode, since there is probably much less utility to knowing the hash when in enforcing mode. And for report-only mode, I wonder: Would it be possible to defer sending reports until response time? Or alternatively, could CSP introduce a new report type for this that is sent at response-time? Either of these options seem like they would work for both potential uses for this feature.

On top of that, they may collide with actual CSP policies that the site would want to deploy.

Since CSP allows setting multiple independent policies that are independently evaluated, this shouldn't be an issue. A website could easily set two distinct CSP policies:

Content-Security-Policy: script-src 'nonce-...'
Content-Security-Policy-Report-Only: script-src 'none' 'report-hash'

Where the first one would mitigate XSS and the second one would collect script hashes.

So overall, I suspect that putting this in CSP might increase utility at the cost of a little extra complexity in CSP.

[yoavweiss]

Thanks for filing this!

Content-Security-Policy: script-src 'nonce-...'
Content-Security-Policy-Report-Only: script-src 'none' 'report-hash'

Oh, I didn't think of report-hash as a separate CSP feature. If sent as a separate report, this would be simply a matter of API shape changes from the current proposal.
If sent as part of the current CSP reports, it will require their deferral.

I'd love @mikewest's opinions of the above.

[ddworken]

Oh, I didn't think of report-hash as a separate CSP feature. If sent as a separate report, this would be simply a matter of API shape changes from the current proposal.

Yeah, I think it would be quite reasonable to make this an opt-in feature (via a report-hash keyword, similar to how report-sample works) and the reports can just be sent as entirely separate reports. So this is really just a change of the shape of the API, so that we can also have this work for other types of scripts (now, or potentially deferring that to the future).

[ddworken]

A number of folks at Google (including @mikewest, @camillelamy, @aaj, @lweichselbaum) met up last week to brainstorm future plans around CSP and we're quite excited about some potential new improvements to CSP, especially around hashes. Concretely, we're thinking about picking up the work on URL hashes and eval hashes which will both be big steps towards making hash-based CSPs easier to adopt. Given that, we're also generally in favor of trying to fit this feature into CSP (even if it is a separate type of report dispatched at a separate time) since it will fit in well with the effort to make hash-based CSPs more practical to adopt.

@yoavweiss if we're on board with this plan, does this approach seem like it could solve your use cases?

[aaj]

@ddworken Well I'm flattered but I don't work at google. Did you mean @Jaredk3nt?

[aaj]

A friend of mine has spent an unreasonable amount of time just trying to figure out who you've confused me with, based on the typo alone. WE NEED TO KNOW!

[ddworken]

Ah, I'm sorry about the mistaken tag! @arturjanc is who I meant to tag. :)

[arturjanc]

I like this idea and see a lot of value in including hashes in violation reports (for both inline scripts and script#src attributes, and contents of external script resources, wherever that's allowed by the SOP or presence of CORS).

It's not exactly the same, but we also have w3c/webappsec-csp#575 which suggested 'report-hash' for the use case @ddworken mentioned above, and where IIRC we had some consensus, but never followed up on an implementation (also because we hadn't fully fleshed out the proposal in w3c/webappsec-csp#574). So maybe we now have a critical mass of functionality to actually implement this?

[arturjanc]

Also, nice to meet you @aaj, please consider yourself an honorary Googler based on the callout in this thread :)

[yoavweiss]

Given that yesterday's WebAppSec discussion had consensus on this direction, what's the best way to integrate this with CSP? Should I continue to incubate this separately? Or should I open a PR on CSP itself?

^^ @mikewest @antosart

[antosart]

Given the consensus and since this seems a relatively small addition to the script-src directive, I'd say a PR on CSP makes sense here...?

[yoavweiss]

Thanks for filing this. I'm replacing this proposal with a CSP PR: w3c/webappsec-csp#693