Les tests WebAuthn ont émergé alors que les normes FIDO2 ont remplacé l'ancien U2F, introduisant des machines d'état de cérémonie complexes impliquant des données client, des objets d'attestation et des défis cryptographiques. Le problème central réside dans l'hétérogénéité des authentificateurs ; les authentificateurs de plateforme comme Windows Hello diffèrent radicalement des matériels itinérants comme YubiKey en ce qui concerne le stockage des clés résidentes, les protocoles de transport (USB, NFC, BLE) et les exigences UV, tandis que les navigateurs appliquent des politiques de permissions différentes pour les contextes inter-origin. Une méthodologie manuelle systématique nécessite une cartographie de la taxonomie des authentificateurs, où chaque appareil est classé par son format d'attestation (packed, tpm, fido-u2f), capacités et disponibilité des transports. Les testeurs doivent exécuter manuellement des cérémonies d'enregistrement et d'authentification à travers Chrome, Safari, Firefox, et Edge, en inspectant les objets d'attestation encodés en CBOR via les DevTools du navigateur pour vérifier la structure fmt et attStmt par rapport au FIDO Metadata Service (MDS). Une attention particulière doit être portée aux contextes iframe inter-origin, en validant que les permissions allow="publickey-credentials-create" et allow="publickey-credentials-get" sont correctement appliquées, et que les flux de clés résidentes gèrent correctement le filtre excludeCredentials pour éviter les enregistrements en double.
Un portail de santé a intégré l'enregistrement WebAuthn à l'intérieur d'un widget React servi depuis un sous-domaine CDN, permettant aux médecins d'utiliser YubiKey 5 NFC pour l'authentification à deux facteurs ou macOS Touch ID pour une connexion sans mot de passe. Les médecins ont signalé des échecs intermittents où Safari sur iOS ne reconnaissait pas la YubiKey via NFC après une inscription réussie sur le bureau Chrome, et les invites Touch ID ont échoué silencieusement lorsque le widget était chargé dans une iframe inter-origin à l'intérieur du système de dossier de santé électronique Epic de l'hôpital. Nous avons envisagé trois approches distinctes pour isoler la cause fondamentale de ces échecs d'intégration spécifiques au matériel.
La première solution a impliqué des tests automatisés avec des authentificateurs virtuels via Puppeteer ou Selenium utilisant le protocole d'authentificateur virtuel WebDriver. Cette méthode offre une grande vitesse et une répétabilité parfaite pour les tests de régression du traitement des défis-réponses côté serveur et la logique de parsing CBOR. Cependant, elle échoue à reproduire des particularités spécifiques au matériel—comme les indices de transport de YubiKey en conflit avec l'implémentation NFC de Safari ou les différences de politique de permissions des iframe entre Chrome et Safari—et ne peut pas simuler les invites biométriques UV ou les interactions tactiles physiques.
La deuxième solution proposait des tests manuels ad-hoc en utilisant n'importe quel appareil disponible au bureau pour fournir un retour immédiat sur l'expérience utilisateur. Bien que cette approche capture le comportement des navigateurs dans le monde réel, elle entraîne une couverture incohérente et une reproductibilité ; les testeurs ont souvent manqué que les appareils Android nécessitent un couplage BLE pour les clés de sécurité tandis que iOS préfère NFC, conduisant à de faux négatifs. De plus, le manque de vérification structurée de l'attestation signifiait que nous ne pouvions pas distinguer entre une YubiKey véritable et un clone de firmware compromis retournant des chaînes de certificats X.509 invalides ou des valeurs AAGUID incorrectes.
La troisième solution a mis en place un régime de test de matrice d'authentificateurs structurée avec des dispositifs physiques, où nous avons catalogué les capacités de chaque authentificateur (prise en charge des clés résidentes, format d'attestation, types de transport) et exécuté manuellement des cérémonies à travers des combinaisons de navigateurs et de systèmes d'exploitation. Nous avons intercepté le trafic avec Burp Suite et les DevTools du navigateur pour inspecter le clientDataJSON et attestationObject, testant spécifiquement les scénarios inter-origin en intégrant le flux d'enregistrement dans des iframes avec des attributs allow variés et en vérifiant le comportement de la clé résidente en définissant requireResidentKey: true et en tentant l'authentification avec un tableau allowCredentials vide.
Solution choisie et résultat
Nous avons choisi l'approche de matrice structurée car le comportement WebAuthn est fondamentalement lié à l'implémentation matérielle et aux politiques de sécurité des navigateurs que les environnements virtuels ne peuvent pas émuler. Cette méthodologie a révélé que Safari nécessite des attributs explicites allow="publickey-credentials-get" pour les iframes inter-origin, que Chrome infère automatiquement, causant les échecs silencieux dans l'intégration de Epic. De plus, nous avons découvert que YubiKey 5 NFC retourne transports: ["nfc", "usb"] mais iOS Safari n'énumère que nfc durant la cérémonie, conduisant à ce que le filtre allowCredentials côté serveur rejette l'identifiant lorsque la validation du transport était strictement appliquée. Après avoir assoupli la validation du transport côté serveur pour accepter tout transport annoncé par l'authentificateur et ajouté des vérifications de permissions iframe à notre liste de contrôle de tests manuels, l'authentification inter-appareils a réussi de manière cohérente à travers l'écosystème de dispositifs mixtes de l'hôpital.
Comment vérifiez-vous manuellement l'intégrité cryptographique d'un objet d'attestation pour garantir que l'authentificateur est authentique et non un firmware compromis ou un émulateur durant les tests en boîte noire ?
De nombreux candidats supposent que la vérification de l'attestation est purement une préoccupation côté serveur. Pour valider manuellement, extrayez l'attestationObject de la réponse PublicKeyCredential du navigateur (décodez en base64url en binaire), parsez-le avec un débogueur CBOR (comme cbor.me), et inspectez le champ fmt. Pour l'attestation packed, vérifiez la chaîne de certificats X.509 contre le FIDO Alliance Metadata Service (MDS) pour vérifier les authentificateurs révoqués ou les indicateurs d'auto-attestation. Pour l'attestation tpm, validez que le certificat TPM inclut la EK (Endorsement Key) et que la structure certInfo correspond à l'algorithme de hachage attendu. Cette inspection manuelle attrape les authentificateurs retournant des signatures malformées ou des valeurs AAGUID incorrectes que les scripts automatisés pourraient négliger s'ils ignorent la vérification stricte de l'attestation.
Quelle est la distinction précise entre User Presence (UP) et User Verification (UV), et comment cela impacte-t-il les tests de clés résidentes (identifiants découvrables) à travers les authentificateurs de plateforme vs. itinérants ?
Les candidats confondent souvent le simple toucher sur une YubiKey (UP) avec la saisie d'un PIN (UV). Dans les tests manuels, vous devez vérifier que la définition de userVerification: "discouraged" permet toujours l'enregistrement sur une YubiKey (qui n'effectue que UP), mais que la définition de residentKey: "required" force UV sur la plupart des authentificateurs car les clés résidentes nécessitent une protection. Les testeurs manquent de noter que Windows Hello effectue toujours UV (biométrique ou PIN) même quand déconseillé, tandis que macOS Touch ID respecte l'indicateur mais échoue à créer des clés résidentes sans UV. Vous devez tester manuellement la cérémonie avec des clés résidentes tant required que preferred, en observant si l'authentificateur retourne un credentialId durant l'authentification sans allowCredentials (prouvant qu'il était résident), et en vérifiant le byte d'indicateurs authenticatorData (bit 0 pour UP, bit 2 pour UV) en utilisant un parseur CBOR pour confirmer que le comportement de l'authentificateur correspond aux options.
Comment testez-vous la fonctionnalité excludeCredentials pour éviter les enregistrements en double lorsque vous n'avez qu'une seule clé de sécurité physique, en garantissant que l'authentificateur identifie correctement les identifiants existants ?
Cela teste la compréhension du mécanisme de découverte côté client. Enregistrez manuellement un identifiant, capturez le rawId, puis initiez une nouvelle cérémonie d'enregistrement avec excludeCredentials contenant cet ID et le même user.id. Un authentificateur conforme devrait retourner une DOMException nommée InvalidStateError. Cependant, les candidats négligent que Windows Hello et certains keystores Android peuvent retourner l'identifiant existant au lieu d'une erreur (ce qui est valide selon les spécifications WebAuthn Level 2 si l'authentificateur ne supporte pas les listes d'exclusion). Vous devez vérifier les deux résultats : que le serveur gère l'erreur avec grâce et que, si un identifiant est retourné, il correspond à l'ID exclu et est rejeté côté serveur. De plus, testez avec un user.id différent pour garantir que l'authentificateur n'exclut pas incorrectement les identifiants provenant de différents comptes utilisateurs, ce qui indiquerait une grave vulnérabilité de confidentialité.