search

WICG / signature-based-sri

Signature-based Resource Loading Restrictions
https://wicg.github.io/signature-based-sri/
Other
20 stars 2 forks source link

CORS integration #17

Open annevk opened 1 day ago

annevk commented 1 day ago

I think we'd have to be extremely careful if we didn't require CORS (and given that most new things require CORS anyway it's not clear it's worth the hassle). And if we require CORS we need to consider whether the user agent can poke through the lack of Access-Control-Expose-Headers for these new response headers or not.

mikewest commented 1 day ago

I don't think anything in this proposal changes the CORS requirement; that really does seem mandatory for signatures and hashes alike.

I don't think it's necessary that we expose those headers, but I can see an argument that unless the headers are exposed, there's some information leakage based on the key used for signing (e.g. the contents of Signature-Input)? Is that what you're concerned about here, or have I missed your point?

annevk commented 1 day ago

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

As for exposing headers, I think ideally user agents would be able to use https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name deep in the networking subsystem to identify which headers to share with their caller. If we poke holes in that by using response headers not in that list for internal purposes we end up making such a system more involved to deploy and less robust overall.

Not sure if there's an actual leak or not. Perhaps if the server was not expecting the browser to make use of headers that are not part of the safelist, which kinda is the desirable model.

mikewest commented 1 day ago

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

@ddworken might have additional context (or a different opinion?) here, but it seems necessary to me, and that's how the proposal is currently written.

If we poke holes in that by using response headers not in that list for internal purposes we end up making such a system more involved to deploy and less robust overall.

Assuming we run with #16, would you suggest adding Signature, Signature-Input, and *-Digest to the safelist? That doesn't initially seem unreasonable to me, and could clarify the ways in which delivering those headers might impact response handling.

annevk commented 1 day ago

Either we add them to the safelist or we require them to be specified by ...-Expose-Headers.

mikewest commented 1 day ago

Ok, thanks!

I'll add a monkey-patch to the doc once we work out what which headers we're planning to rely upon and evaluate their content. I know I'm not familiar enough yet with Signature and Signature-Input to judge risk. Assuming no surprises, I'd prefer adding them to the safelist, but we can evaluate that together later.

ddworken commented 1 day ago

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

@ddworken might have additional context (or a different opinion?) here, but it seems necessary to me, and that's how the proposal is currently written.

So I think the idea here was that it might not be necessary since signature-based SRI wouldn't provide any visibility into the contents of the response (unlike hash-based SRI, which allows probing against specific hash values). Though I do tend to agree that it is better to just keep the CORS requirement to avoid the complexity/risk here.