XSS Is Deadly for Passkeys: The Hidden Risk of Attestation None

Sponsored by: Report URI - Your website is running code you don't control. See it. Control it. Prove it.

A single XSS vulnerability can turn passkeys from a phishing-resistant login mechanism into a persistent account takeover backdoor. If malicious JavaScript can run on your page, it may be able to register an attacker-controlled passkey against the victim’s account. The user sees nothing, the website records a successful registration, and the attacker walks away with a valid authentication backdoor.

For an organisation, that means more than “someone found XSS”. It means identity compromise, persistence, audit-trail ambiguity, regulatory exposure, and a security control that appears to have worked while silently enabling an attacker. The uncomfortable truth is that while passkeys do bring amazing benefits, and I think that everyone should use them, there is a dangerous gap in the threat model that's being overlooked by almost everyone I speak to. This blog post explains the risk, demonstrates how this is possible, and what the effective defences look like.

Introduction Before we get started, if you'd like a brief overview of how passkeys work, you can jump over to my Passkeys 101 blog post, where I explain the basics. I'm going to assume in this blog post that you understand the concept of passkeys, and we're going to look at how they work in more detail in this post. We also need to establish some terminology to make the rest of this blog post easier to understand: Relying Party : The website or application that stores and verifies a user's passkey credential for authentication. Authenticator : The user’s device or password manager that creates, stores, and uses the private key to prove the user’s identity to the Relying Party. Attestation : The mechanism an Authenticator can use during registration to prove what kind of hardware created the credential.

How Passkey Registration Works When registering a passkey with an RP like Report URI, JavaScript will make a call out to fetch the data it needs: const optRes = await fetch('/passkeys/register_get_options/' + getCsrfToken(), { method: 'POST' });POST /passkeys/register_get_options/8f3c1a9e4b2d7f60c5a1e8d2b9f4a7c3 HTTP/1.1 Host: report-uri.com Cookie: session=... Content-Length: 0 The RP will return a response that looks like this and contains the publicKey object: HTTP/1.1 200 OK Content-Type: application/json

"publicKey": { "rp": { "name": "Report URI", "id": "report-uri.com" }, "user": { "id": "Yi8kP1xqd0Jx3mWZ8Q2vK7nR4tH6sLpA9dF1gE0wXc=", "name": "jane@example.com", "displayName": "jane@example.com" }, "challenge": "kQ7nR4tH6sLpA9dF1gE0wXc2vK7mZ8Q2Yi8kP1xqd0J", "pubKeyCredParams": [ { "type": "public-key", "alg": -8 }, { "type": "public-key", "alg": -7 }, { "type": "public-key", "alg": -257 } ], "timeout": 60000, "authenticatorSelection": { "requireResidentKey": true, "residentKey": "required", "userVerification": "required" }, "attestation": "none", "excludeCredentials": [ "type": "public-key", "id": "AX9k2mZ8Q2vK7nR4tH6sLpA9dF1gE0wXc...", "transports": ["usb", "nfc", "ble", "hybrid", "internal"] Now that your device has the information it needs, it can create the new passkey and save it, likely showing you some kind of confirmation that requires a PIN, FaceID, TouchID, etc... This is done with the following JavaScript API call that will trigger the interaction with your Authenticator: const cred = await navigator.credentials.create({ publicKey }); If you complete the process, your Authenticator will then store your new passkey. The JavaScript will then build the response to send back to the RP to confirm that everything has been completed and to save the new passkey against the user's account: const payload = { name: nameInput?.value?.trim() || '', password: passwordInput.value, id: cred.id, rawId: cred.rawId, type: cred.type, clientDataJSON: cred.response.clientDataJSON, attestationObject: cred.response.attestationObject, };

const finRes = await fetch('/passkeys/register_finish/' + getCsrfToken(), { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload), }); The attestationObject contains the important information, with everything else being mostly metadata. Here's the content of the attestationObject with the public key being the crucial part: attestationObject (CBOR) ├─ fmt ← attestation format, e.g. "none" / "apple" ├─ authData ← authenticator data │ ├─ rpIdHash ← SHA-256 hash of the RP ID │ ├─ flags ← UP/UV/AT/ED flags, etc. │ ├─ signCount ← signature counter │ └─ attestedCredentialData │ ├─ aaguid ← type/model id, not useful for synced passkeys │ ├─ credentialIdLength │ ├─ credentialId ← credential is, also surfaced as id/rawId │ └─ credentialPublicKey ← COSE-encoded public key └─ attStmt ← attestation statement; empty for fmt "none" The RP can now save the public key against the user and we know that this is a passkey they will be...

XSS Is Deadly for Passkeys: The Hidden Risk of Attestation None

Related Articles

Elevated error rates on requests to multiple models

Donald Trump and sons to be 'forever' exempt from tax audits

PopuLoRA: Co-Evolving LLM Populations for Reasoning Self- Play

Old Reddit Is Down

The ultimate female fantasy – A feminist critique of Beauty and the Beast