Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider requiring mitigation of script injection attacks. #133

Open
mikewest opened this issue Jun 24, 2024 · 3 comments
Open

Consider requiring mitigation of script injection attacks. #133

mikewest opened this issue Jun 24, 2024 · 3 comments
Labels

Comments

@mikewest
Copy link
Member

In #109, @RByers noted that mandatory encryption could be a path towards mitigating the risk that unexpected/injected code on a site could enable an attacker to extract details of a user's identity.

I'd suggest a) that that risk is real, and b) that you could mitigate it to some extent by requiring the page on which the API executes to have at least minimal defenses against injection attacks by requiring a sufficiently-strong CSP along the lines of https://mikewest.github.io/injection-mitigated/.

@RByers
Copy link
Member

RByers commented Jun 27, 2024

This is certainly interesting to me, but the details really matter here. I'm OK imposing some burden on adoption, but it's got to be a bar that many would already find reasonable, understandable and achievable.

Is the [InjectionMitigated] idea being used for any web platform APIs today? Do you have HTTP Archive (or UMA) data indicating what fraction of the web is already meeting the criteria you've outlined?

If you show us a pragmatic bar which many security-sensitive sites already meet, then I'm open to exploring if we could make it a requirement for this API - even if we're the first such API to do so. But precisely defining that pragmatic bar, keeping track of the fraction of the web already meeting it and doing the evangelism for common infrastructure to try to drive up compatibility with the criteria seems like to me to be an independent (and possibly substantial) effort that would need to be a pre-requisite to any API taking a hard dependency, right?

@mikewest
Copy link
Member Author

Is the [InjectionMitigated] idea being used for any web platform APIs today?

Chromium has an implementation of the attribute that we're using for getAllScreensMedia() (see media_devices.idl) to lock in some of the security properties of IWAs (strict CSP + Trusted Types enforcement) while that feature is in an IWAless OT.

Do you have HTTP Archive (or UMA) data indicating what fraction of the web is already meeting the criteria you've outlined?

UMA suggests that ~10% of top-level pages have a strict CSP, and ~4% of top-level pages enforce Trusted Types. I suspect there's strong overlap between the two, given the folks involved.

But precisely defining that pragmatic bar, keeping track of the fraction of the web already meeting it and doing the evangelism for common infrastructure to try to drive up compatibility with the criteria seems like to me to be an independent (and possibly substantial) effort that would need to be a pre-requisite to any API taking a hard dependency, right?

Yes, that's quite fair.

[InjectionMitigated] is not a solidly agreed-upon proposal at the moment. It's an evolution of the "secure context" concept that we've discussed on and off for the last few years that I'm planning to poke people about at TPAC now that there's broad vendor agreement on Trusted Types. I think it matches the security community's general guidance around how developers can effectively mitigate the risk of XSS, so I don't expect a whole lot of pushback on the general concept (though of course there will be robust discussion around where we'd reasonably draw a line between APIs that benefit from such a restriction, and APIs for which it's an unreasonable burden).

@RByers
Copy link
Member

RByers commented Jun 28, 2024

Ah that's great, thanks Mike! I didn't realize this had gotten that far along. I can point our potential customers at strict CSP and trusted types and get their feedback on how hard they would be to adopt. I assume those two links are the best resources to get developers started with, but let me know if there's anything better. It seems like it would be a tough sell to completely block an API like this on those at the moment, but maybe? Or maybe we can start with a middle ground like altering Chromium's credential presentation risk engine (and so UI behavior like user warnings) based on the presence of these features?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants