WebAuthn testen ontstonden toen FIDO2 normen de legacy U2F vervingen, wat complexe ceremonie-staatsmachines introduceerde waarbij clientgegevens, attestatieobjecten en cryptografische uitdagingen betrokken zijn. Het kernprobleem ligt in authenticatoorheterogeniteit; platformauthenticators zoals Windows Hello verschillen radicaal van rondzwervende hardware zoals YubiKey wat betreft resident key-opslag, transportprotocollen (USB, NFC, BLE), en UV vereisten, terwijl browsers verschillende toestemmingbeleidsregels afdwingen voor cross-origin contexten. Een systematische handmatige methodologie vereist authenticator taxonomie-mapping, waarbij elk apparaat wordt geclassificeerd op basis van zijn attestatie-indeling (packed, tpm, fido-u2f), mogelijkheden en transportbeschikbaarheid. Testers moeten handmatig registratie- en authenticatierituelen uitvoeren in Chrome, Safari, Firefox en Edge, waarbij ze de CBOR-gecodeerde attestatieobjecten inspecteren via browser DevTools om de fmt en attStmt structuur te verifiëren tegen de FIDO Metadata Service (MDS). Speciale aandacht moet worden besteed aan cross-origin iframe contexten, waarbij wordt gevalideerd dat allow="publickey-credentials-create" en allow="publickey-credentials-get" rechten correct worden gehandhaafd, en dat resident key-stromen de excludeCredentials filter correct afhandelen om dubbele registraties te voorkomen.
Een gezondheidsportaal heeft WebAuthn registratie ingebed in een React widget die van een CDN-subdomein werd geserveerd, waardoor artsen YubiKey 5 NFC konden gebruiken voor tweefactorauthenticatie of macOS Touch ID voor wachtwoordloze login. Artsen meldden intermitterende storingen waarbij Safari op iOS de YubiKey via NFC niet herkende na succesvolle registratie op desktop Chrome, en Touch ID prompts stilzwijgend mislukten wanneer de widget in een cross-origin iframe in het ziekenhuis's Epic elektronische gezondheidsrecord systeem werd geladen. We overweegden drie verschillende benaderingen om de oorzaak van deze hardware-specifieke integratiefouten te isoleren.
De eerste oplossing omvatte geautomatiseerde tests met virtuele authenticators via Puppeteer of Selenium met behulp van het WebDriver virtuele authenticatorprotocol. Deze methode biedt hoge snelheid en perfecte reproduceerbaarheid voor regressietests van de serverzijde challenge-response verwerking en CBOR parsing logica. Het faalt echter om hardware-specifieke eigenaardigheden te reproduceren—zoals YubiKey transport aanwijzingen die conflicteren met de NFC-implementatie van Safari of de iframe toestemmingbeleidsverschillen tussen Chrome en Safari—en kan geen biometrische UV prompts of fysieke tikinteracties simuleren.
De tweede oplossing stelde ad-hoc handmatige testen voor met alle beschikbare apparaten op kantoor om onmiddellijke feedback te geven over de gebruikerservaring. Hoewel deze benadering het gedrag van echte browsers vastlegt, resulteert het in inconsistente dekking en reproduceerbaarheid; testers misten vaak dat Android apparaten BLE pairing vereisen voor beveiligingssleutels terwijl iOS de voorkeur geeft aan NFC, wat leidt tot valse negatieven. Bovendien betekende het gebrek aan gestructureerde attestatieverificatie dat we niet konden onderscheiden tussen een echte YubiKey en een gecompromitteerde firmware kloon die ongeldige X.509 certificaatketens of onjuiste AAGUID waarden retourneerde.
De derde oplossing implementeerde een gestructureerde authenticator matrix testregime met fysieke apparaten, waarbij we de mogelijkheden van elke authenticator (ondersteuning voor resident keys, attestatie-indeling, transporttypes) catalogueerden en handmatig rituelen uitvoerden over browser- en OS-combinaties. We onderschepten verkeer met Burp Suite en browser DevTools om de clientDataJSON en attestationObject te inspecteren, specifiek door cross-origin scenario's te testen door het registratieproces in iframes met variërende allow attributen in te bedden en het gedrag van resident keys te verifiëren door requireResidentKey: true in te stellen en authenticatie te proberen met een lege allowCredentials array.
Gekozen oplossing en resultaat
We selecteerden de gestructureerde matrixaanpak omdat WebAuthn-gedrag fundamenteel verbonden is met hardware-implementatie en browserbeveiligingsbeleid die virtuele omgevingen niet kunnen emuleren. Deze methodologie onthulde dat Safari expliciete allow="publickey-credentials-get" attributen vereist voor cross-origin iframes, die Chrome automatisch afleidt, wat de stille mislukkingen in de Epic integratie veroorzaakte. Bovendien ontdekten we dat YubiKey 5 NFC transports: ["nfc", "usb"] retourneert, maar iOS Safari slechts nfc tijdens de ceremonie opsomt, waardoor de serverzijde allowCredentials filter de referentie afwijst wanneer transportvalidatie strikt werd gehandhaafd. Na het versoepelen van de transportvalidatie op de server om elk transport dat door de authenticator werd geadverteerd te accepteren en het toevoegen van iframe toestemming controles aan onze handmatige testchecklijst, slaagde cross-device authenticatie consequent in de gemengde apparaatecosystemen van het ziekenhuis.
Hoe verifieer je handmatig de cryptografische integriteit van een attestatieobject om ervoor te zorgen dat de authenticator echt is en geen gecompromitteerde firmware of emulator tijdens black-box testen?
Veel kandidaten gaan ervan uit dat de attestatieverificatie puur een serverzijde kwestie is. Om handmatig te valideren, extraheer je het attestationObject uit het PublicKeyCredential antwoord van de browser (base64url decoderen naar binair), parse het met een CBOR debugger (zoals cbor.me), en inspecteer het fmt veld. Voor packed attestatie, verifieer de X.509 certificaatketen tegen de FIDO Alliance Metadata Service (MDS) om te controleren op ingetrokken authenticators of zelf-attestatiewimpels. Voor tpm attestatie, valideer dat het TPM certificaat de EK (Endorsement Key) omvat en dat de certInfo structuur overeenkomt met het verwachte hash-algoritme. Deze handmatige inspectie vangt authenticators die verkeerd gevormde handtekeningen of onjuiste AAGUID waarden retourneren die door geautomatiseerde scripts mogelijk niet worden opgemerkt als ze strikte attestatieverificatie overslaan.
Wat is het precieze onderscheid tussen Gebruikersaanwezigheid (UP) en Gebruikersverificatie (UV), en hoe beïnvloedt dit het testen van resident keys (ontdekbare referenties) over platform- versus rondzwervende authenticators?
Kandidaten verwarren vaak de simpele aanraking op een YubiKey (UP) met PIN-invoer (UV). In handmatige tests moet je verifiëren dat het instellen van userVerification: "discouraged" nog steeds registratie op een YubiKey toestaat (die alleen UP doet), maar het instellen van residentKey: "required" dwingt UV op de meeste authenticators omdat resident keys bescherming vereisen. Testers missen dat Windows Hello altijd UV uitvoert (biometrisch of PIN) zelfs wanneer het wordt afgeraden, terwijl macOS Touch ID de vlag respecteert maar zonder UV resident key creatie mislukt. Je moet de ceremonie handmatig testen met zowel required als preferred resident keys, en observeren of de authenticator een credentialId retourneert tijdens authenticatie zonder allowCredentials (wat bewijst dat het resident was), en de authenticatorData vlaggenbyte controleren (bit 0 voor UP, bit 2 voor UV) met behulp van een CBOR parser om te bevestigen dat het gedrag van de authenticator overeenkomt met de opties.
Hoe test je de excludeCredentials functionaliteit om dubbele registratie te voorkomen wanneer je slechts één fysieke beveiligingssleutel hebt, en ervoor te zorgen dat de authenticator bestaande referenties correct identificeert?
Dit test het begrip van het client-side ontdekkingsmechanisme. Registreer handmatig een referentie, vang de rawId, en start vervolgens een nieuwe registratie ceremonie met excludeCredentials die dat ID en dezelfde user.id bevat. Een conforme authenticator zou een DOMException genaamd InvalidStateError moeten retourneren. Kandidaten missen echter dat Windows Hello en sommige Android keystores mogelijk de bestaande referentie retourneren in plaats van een fout (wat geldig is volgens de WebAuthn Niveau 2 specificatie als de authenticator geen uitsluitlijsten ondersteunt). Je moet beide uitkomsten verifiëren: dat de server de fout netjes afhandelt, en dat als een referentie wordt geretourneerd, deze overeenkomt met de uitgesloten ID en serverzijde wordt afgewezen. Test bovendien met een andere user.id om ervoor te zorgen dat de authenticator niet per ongeluk referenties van verschillende gebruikersaccounts uitsluit, wat zou wijzen op een ernstige privacy kwetsbaarheid.