search

yoavweiss / subresource-reporting

2 stars 0 forks source link

Integrating hash reporting into CSP #4

Open ddworken opened 4 days ago

ddworken commented 4 days ago

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 commented 4 days ago

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 commented 2 days ago

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).