Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upApply integrity checks to inline script and style blocks. #86
Conversation
This comment has been minimized.
This comment has been minimized.
|
Makes sense. IMHO this should have an informal note / redirection that CSP modified the allow behavior depending on policy. Did you file an issue in CSP to write down the blocking of correct but disallowed (absent from policy) metadata? |
This comment has been minimized.
This comment has been minimized.
CSP didn't modify SRI's behavior at all, AFAIR. It layers on top of SRI, imposing some additional restrictions prior to SRI's enforcement. (Or is that what you mean?)
As currently defined, it fails the bits in step 1.3 of https://w3c.github.io/webappsec-csp/#script-pre-request, which happens during Fetch, prior to SRI enforcement. So we'd expect a CSP error failing the request rather than an SRI error. I'm pretty sure that's what Chrome's console reports, and that we fire a securitypolicyviolation event. Is there more that CSP should do here? |
This comment has been minimized.
This comment has been minimized.
Yes. SRI will allow, but the resource matching the integrity attribute still has to pass a CSP (if existant). Maybe that's not noteworthy in itself. But what's layered on top of what isn't immediately obvious to developers, is it? I'm not sure how to make the order in which things are processed (layered) more explicit.
No, that makes sense. Nevermind then. |
|
What's the use case for this feature? |
| this algorithm after the CSP check in step 13. | ||
|
|
||
| ISSUE: This needs to be wired up to HTML's [=update a style block=] algorithm by inserting a call | ||
| to this algorithm after the CSP check in step 5. |
This comment has been minimized.
This comment has been minimized.
annevk
Jan 4, 2020
Member
Well, you'll also need to define it as a valid attribute for the style element if this is actually a thing we want to encourage.
This comment has been minimized.
This comment has been minimized.
mikewest
Jan 7, 2020
Author
Member
You're right. I thought we'd done that already, but of course it's only valid for <link>.
This comment has been minimized.
This comment has been minimized.
|
This was not fixed by that PR. |
This comment has been minimized.
This comment has been minimized.
Inline integrity information can provide some defense in depth against injection attacks (as an injection into a script block wouldn't automatically mean code execution if the block had an Adding this support might also allow us to more cleanly layer CSP's behavior on top of SRI for inline blocks, just as we have for externalized scripts. That isn't user-facing at all, but might clean up the spec a bit. There was some discussion of/agreement on this in https://www.w3.org/2016/05/16-webappsec-minutes.html#item02, and on and off since then. |
This comment has been minimized.
This comment has been minimized.
|
And the injection point would filter HTML somehow and only allow injection of content already covered by the integrity attribute value? Especially that last part seemed rather curious to me, but maybe it's valid in certain complicated setups. |
This comment has been minimized.
This comment has been minimized.
I admit that the use case from a security perspective is somewhat contrived (@arturjanc might have actual data here from Google's products). It assumes an injection point like Apple had performance reasons in the minutes linked above (that are unfortunately a bit difficult to tease out of that record), and I think there are spec-sanity reasons to do so (I find it somewhat confusing that CSP can allow inline script by hash, but that it does so completely independently of SRI). Given that Chrome's shipping implementation is already halfway here, I'd prefer to simply make that work the way outlined here than remove it. |
This comment has been minimized.
This comment has been minimized.
|
The thing I wanted to point is that the integrity value would have to match the eventual |
This comment has been minimized.
This comment has been minimized.
|
Yes. If a developer is parsing the data on the server and generating an integrity attribute on the fly, then all bets are off. An alternative way of looking at that is that calculating a hash to match the eventual |
This comment has been minimized.
This comment has been minimized.
|
For my understanding, the expected usage pattern is that |
This comment has been minimized.
This comment has been minimized.
arturjanc
commented
Jan 25, 2020
|
I'm likely missing some context here, but I'm also not entirely clear on how this could be used as an injection defense:
The way I see this potentially working is if there was an integrity attribute that covered the parse tree of the script, but not its full contents. Then, if I have something like Alas, that's not really what SRI does... :) |
mikewest commentedDec 16, 2019
•
edited by pr-preview bot
Closes #44.
If this looks like a reasonable approach, I'll put up patches to HTML and CSP as well, and try to find someone to fix Chromium's implementation.
/cc @annevk @mozfreddyb @devd @fmarier @metromoxie
Preview | Diff