XSS Is Deadly for Passkeys: The Hidden Risk of Attestation None
15 points by fazalmajid
15 points by fazalmajid
Trying to figure out what about this is passkey-specific...
Assuming somebody manages to XSS-attack Github, they could similarly add a personal access token to the user's account, giving the attacker full and persistent access to the user's resources. (Until the token times out, which can be up to one year last time I looked.)
So AFAIU the problem occurs in any system where you can add additional credentials to an account, whether it's passkeys or Github-like tokens.
Yup, XSS is a separate class of attacks and hurts the user regardless of the authentication method. As the article mentions, some properties of passkeys still hold up: using XSS to sniff a passkey assertion only gives one-time access (sniffing registration with XSS gains the attacker nothing), but sniffing a password registration or authentication gives silent access to the attacker that the user can't detect and may be used on other sites if the password (or derivatives) were reused.
CSP, trusted types, HTML sanitizer API, etc. are the appropriate mitigations for XSS, not passkeys.
Very interesting (and detailed) article by Scott Helme on how passkey attestation conflicts with passkey sync, and how without authentication, the passkey registration flow is vulnerable to XSS.
Also relevant, Adam Langley's excellent mini eBook on Webauthn and passkeys: https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html
Alex Russell was calling XSS the "ring 0" attack on the web almost 20 years ago. Still true today: if your site has a functional XSS the attacker doesn't even need to register passkeys or steal cookies, they can fire up some fetch() calls and take action as your account.
Yes, but the attack described in the article persists potentially indefinitely, even after the user has closed the page.
P.S. So it's worse than stealing cookies, because those would time out at some point.