Die WebAuthn-Tests entstanden, als die FIDO2-Standards das veraltete U2F ersetzten und komplexe Zeremonien-Zustandsmaschinen einführten, die Client-Daten, Attestationsobjekte und kryptografische Herausforderungen beinhalten. Das Hauptproblem liegt in der Heterogenität der Authentifikatoren; Plattform-Authentifikatoren wie Windows Hello unterscheiden sich radikal von roaming Hardware wie YubiKey in Bezug auf den Speicher des residenten Schlüssels, Transportprotokolle (USB, NFC, BLE) und UV-Anforderungen, während Browser unterschiedliche Berechtigungspolitiken für Cross-Origin-Kontexte durchsetzen. Eine systematische manuelle Methodik erfordert eine Taxonomie der Authentifikatoren, bei der jedes Gerät nach seinem Attestationsformat (packed, tpm, fido-u2f), Fähigkeiten und Transportverfügbarkeit klassifiziert wird. Tester müssen manuell Registrierungs- und Authentifizierungszeremonien über Chrome, Safari, Firefox und Edge ausführen und die CBOR-kodierten Attestationsobjekte über die Entwicklertools des Browsers untersuchen, um die Struktur von fmt und attStmt mit dem FIDO Metadata Service (MDS) zu überprüfen. Besonderes Augenmerk muss auf Cross-Origin iframe-Kontexte gelegt werden, um zu validieren, dass die Berechtigungen allow="publickey-credentials-create" und allow="publickey-credentials-get" korrekt durchgesetzt werden und dass die Flüsse des residenten Schlüssels den Filter excludeCredentials richtig behandeln, um doppelte Registrierungen zu verhindern.
Ein Gesundheitsportal bettete die WebAuthn-Registrierung in ein React-Widget ein, das von einer CDN-Subdomain bereitgestellt wurde, sodass Ärzte YubiKey 5 NFC für die Authentifizierung mit einem zweiten Faktor oder macOS Touch ID für passwortloses Anmelden verwenden konnten. Ärzte berichteten von sporadischen Fehlern, bei denen Safari auf iOS den YubiKey via NFC nach erfolgreicher Registrierung auf dem Desktop mit Chrome nicht erkannte, und die Touch ID-Aufforderungen lautlos fehlschlugen, als das Widget in einem Cross-Origin iframe im elektronischen Gesundheitssystem Epic des Krankenhauses geladen wurde. Wir betrachteten drei verschiedene Ansätze, um die Ursachen dieser hardware-spezifischen Integrationsfehler zu isolieren.
Die erste Lösung bestand in automatisierten Tests mit virtuellen Authenticatoren über Puppeteer oder Selenium unter Verwendung des WebDriver-Protokolls für virtuelle Authenticatoren. Diese Methode bietet hohe Geschwindigkeit und perfekte Wiederholbarkeit für Regressionstests der serverseitigen Challenge-Response-Verarbeitung und der CBOR-Parser-Logik. Sie kann jedoch hardware-spezifische Eigenheiten nicht reproduzieren – wie etwa YubiKey-Transporthinweise, die mit der NFC-Implementierung von Safari in Konflikt stehen, oder die Unterschiede in den Berechtigungspolitiken von iframe zwischen Chrome und Safari – und kann biometrische UV-Aufforderungen oder physische Tap-Interaktionen nicht simulieren.
Die zweite Lösung schlug anpassbare manuelle Tests mit bereits verfügbaren Geräten im Büro vor, um sofortiges Feedback zur Benutzererfahrung zu erhalten. Obwohl dieser Ansatz das reale Verhalten von Browsern erfasst, führt er zu inkonsistenter Abdeckung und Wiederholbarkeit; Tester verpassten oft, dass Android-Geräte BLE-Kopplung für Sicherheitsschlüssel benötigen, während iOS NFC bevorzugt, was zu falschen Negativen führte. Darüber hinaus ermöglichte der Mangel an strukturierten Attestationsüberprüfungen nicht, zwischen einem echten YubiKey und einem kompromittierten Firmware-Klon zu unterscheiden, der ungültige X.509-Zertifikatsketten oder falsche AAGUID-Werte zurückgab.
Die dritte Lösung implementierte ein strukturiertes Testregime für Authentifikatoren mit physischen Geräten, bei dem wir die Fähigkeiten jedes Authentifikators (Unterstützung residenter Schlüssel, Attestationsformat, Transporttypen) katalogisierten und die Zeremonien manuell über Browser- und OS-Kombinationen ausführten. Wir überwachten den Datenverkehr mit Burp Suite und den Entwicklertools des Browsers, um den clientDataJSON und das attestationObject zu inspizieren, indem wir speziell Cross-Origin-Szenarien testeten, indem wir den Registrierungsfluss in iframes mit variierenden allow-Attributen einbetteten und das Verhalten des residenten Schlüssels überprüften, indem wir requireResidentKey: true festlegten und versuchten, mit einem leeren allowCredentials-Array zu authentifizieren.
Gewählte Lösung und Ergebnis
Wir wählten den strukturierten Matrixansatz, weil das WebAuthn-Verhalten grundsätzlich an die Hardwareimplementierung und die Sicherheitspolitiken des Browsers gebunden ist, die virtuelle Umgebungen nicht emulieren können. Diese Methodik zeigte, dass Safari explizite allow="publickey-credentials-get"-Attribute für Cross-Origin iframes benötigt, was Chrome automatisch ableitet, was zu den stillen Fehlern in der Epic-Integration führte. Darüber hinaus entdeckten wir, dass YubiKey 5 NFC transports: ["nfc", "usb"] zurückgibt, aber iOS Safari während der Zeremonie nur nfc enumeriert, was dazu führt, dass der serverseitige allowCredentials-Filter die Anmeldeinformationen ablehnt, wenn die Transportverifizierung strikt durchgesetzt wird. Nachdem wir die Transportverifizierung auf dem Server gelockert hatten, um jeden vom Authentifikator beworbenen Transport zu akzeptieren, und Berechtigungsprüfungen für iframes zu unserer manuellen Test-Checkliste hinzugefügt hatten, gelang die geräteübergreifende Authentifizierung konsequent im gemischten Geräteökosystem des Krankenhauses.
Wie überprüfen Sie manuell die kryptografische Integrität eines Attestationsobjekts, um sicherzustellen, dass der Authenticator echt und nicht ein kompromittierter Firmware oder Emulator ist, während Sie Black-Box-Tests durchführen?
Viele Kandidaten nehmen an, dass die Überprüfung der Attestation rein ein serverseitiges Anliegen ist. Um manuell zu validieren, extrahiere das attestationObject aus der PublicKeyCredential-Antwort des Browsers (base64url dekodieren in binär), analysiere es mit einem CBOR-Debugger (z. B. cbor.me) und überprüfe das Feld fmt. Bei packed Attestierungen überprüfe die X.509-Zertifikatskette über den FIDO Alliance Metadata Service (MDS), um auf widerrufene Authentifikatoren oder Selbstattestierungsflags zu prüfen. Bei tpm-Attestierungen verifiziere, dass das TPM-Zertifikat den EK (Endorsement Key) enthält und dass die Struktur certInfo mit dem erwarteten Hash-Algorithmus übereinstimmt. Diese manuelle Inspektion erkennt Authentifikatoren, die fehlerhafte Signaturen oder falsche AAGUID-Werte zurückgeben, die automatisierte Skripte möglicherweise übersehen könnten, wenn sie strikte Attestationsüberprüfungen überspringen.
Was ist der präzise Unterschied zwischen User Presence (UP) und User Verification (UV), und wie beeinflusst dies die Prüfung von residenten Schlüsseln (entdeckbare Anmeldedaten) bei Plattform- im Vergleich zu roaming-Authentifikatoren?
Kandidaten verwechseln oft das einfache Berühren eines YubiKey (UP) mit der PIN-Eingabe (UV). Bei manuellen Tests müssen Sie überprüfen, ob das Festlegen von userVerification: "discouraged" die Registrierung auf einem YubiKey (der nur UP durchführt) weiterhin zulässt, aber das Festlegen von residentKey: "required" in den meisten Authentifikatoren UV erfordert, da residenten Schlüsseln Schutz benötigt wird. Tester übersehen, dass Windows Hello immer UV (biometrisch oder PIN) durchführt, selbst wenn es abgelehnt wird, während macOS Touch ID das Flag respektiert, aber die Erstellung residenter Schlüssel ohne UV fehlschlägt. Sie müssen die Zeremonie sowohl mit required als auch preferred residenten Schlüsseln manuell testen und beobachten, ob der Authentifikator während der Authentifizierung ohne allowCredentials eine credentialId zurückgibt (was beweist, dass sie resident war), und das Bytes der authenticatorData-Flags überprüfen (Bit 0 für UP, Bit 2 für UV) mit einem CBOR-Parser, um zu bestätigen, dass das Verhalten des Authentifikators den Optionen entspricht.
Wie testen Sie die Funktionalität excludeCredentials, um doppelte Registrierungen zu verhindern, wenn Sie nur einen physischen Sicherheitsschlüssel haben und sicherstellen, dass der Authenticator vorhandene Anmeldedaten korrekt identifiziert?
Dies testet das Verständnis des client-seitigen Entdeckungsmechanismus. Registriere manuell eine Anmeldeinformation, erfasse die rawId, und starte dann eine neue Registrierungszeremonie mit excludeCredentials, die diese ID und denselben user.id enthält. Ein konformer Authenticator sollte eine DOMException mit dem Namen InvalidStateError zurückgeben. Kandidaten übersehen jedoch, dass Windows Hello und einige Android-Keystores möglicherweise die vorhandene Anmeldeinformation zurückgeben, anstatt einen Fehler anzuzeigen (was gemäß der WebAuthn Level 2-Spezifikation gültig ist, wenn der Authenticator keine Exklusionslisten unterstützt). Sie müssen beide Ergebnisse überprüfen: dass der Server den Fehler elegant behandelt und dass, wenn eine Anmeldeinformation zurückgegeben wird, sie mit der ausgeschlossenen ID übereinstimmt und serverseitig abgelehnt wird. Darüber hinaus sollten Sie mit einer anderen user.id testen, um sicherzustellen, dass der Authenticator keine Anmeldedaten aus verschiedenen Benutzerkonten fälschlicherweise ausschließt, was auf eine schwerwiegende Datenschutzanfälligkeit hinweisen würde.