Consider requiring mitigation of script injection attacks.

[mikewest]

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]

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]

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]

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?

[johannhof]

CC @simoneonofri

[npdoty]

Would mitigating script injection attacks through CSPs be more challenging for implementer adoption than handling a separate key for signing requests and server-side decryption of credential responses? (As a not-very-advanced web developer, I would find it easier to get up to date on my CSP declarations than I would handling additional cryptographic keys without errors.)

Also, do we expect that decrypting on the server side is helping protect against this attack? It seems like in most examples that the response is sent to the server to be decrypted and then the relevant results are sent to the website to show the user what information has been submitted/confirmed, and it would seem like the malicious script could snoop the data at that stage. Handling script injection would also be one mitigation for the attack where the script introduces a new credential request from the victim site's origin (where encrypted responses don't mitigate against that).

[simoneonofri]

Nice catch @johannhof :)

This is a very good idea from @mikewest!

Yes, on the one hand, we can make it a requirement to "RP" to use strict CSP, and if this is enforced, it will certainly help adoption.

Still on the “RP” side, another issue could be having SRI mitigate the compromised supply chain part.

Regarding mitigation (at least based on some tests I ran on digitalcredentials.dev), it depends on whether the parameters decrypted on the server side are reflected on the website.

To add the final bit to the reflection (but more as a reminder, since for now I've put it as an assumption), there is always the issue of Malicious Extensions.