Testowanie WebAuthn powstało w wyniku zastąpienia standardów FIDO2 przestarzałym U2F, wprowadzając złożone automaty ceremoniowe, które obejmują dane klienta, obiekty poświadczenia i wyzwania kryptograficzne. Kluczowy problem polega na różnorodności uwierzytelniaczy; uwierzytelnicze platformowe, takie jak Windows Hello, zasadniczo różnią się od przenośnego sprzętu, takiego jak YubiKey, w zakresie przechowywania kluczy rezydentów, protokołów transportowych (USB, NFC, BLE) oraz wymagań dotyczących UV, podczas gdy przeglądarki egzekwują różne polityki uprawnień dla kontekstów cross-origin. Systematyczna metodologia ręczna wymaga mapowania taksonomii uwierzytelniaczy, w której każde urządzenie jest klasyfikowane według swojego formatu poświadczenia (packed, tpm, fido-u2f), możliwości oraz dostępności transportu. Testerzy muszą ręcznie przeprowadzać ceremonie rejestracji i uwierzytelniania w Chrome, Safari, Firefox i Edge, sprawdzając obiekty poświadczeń zakodowane w CBOR za pomocą narzędzi deweloperskich przeglądarki, aby zweryfikować strukturę fmt i attStmt w odniesieniu do FIDO Metadata Service (MDS). Szczególną uwagę należy zwrócić na konteksty iframe cross-origin, weryfikując, czy uprawnienia allow="publickey-credentials-create" i allow="publickey-credentials-get" są właściwie egzekwowane, oraz że przepływy klucza rezydenta prawidłowo obsługują filtr excludeCredentials, aby zapobiec podwójnym rejestracjom.
Portal medyczny osadził rejestrację WebAuthn w widgetcie React dostarczanym z subdomeny CDN, umożliwiając lekarzom użycie YubiKey 5 NFC do uwierzytelniania drugiego czynnika lub macOS Touch ID do logowania bez hasła. Lekarze zgłaszali sporadyczne awarie, w których Safari na iOS nie rozpoznawał YubiKey przez NFC po udanej rejestracji na komputerze Chrome, a monity Touch ID zawodziły cicho, gdy widget został załadowany w osadzonym iframe w elektronicznym systemie zdrowia Epic szpitala. Rozważyliśmy trzy odrębne podejścia, aby zidentyfikować przyczynę tych sprzętowych awarii integracyjnych.
Pierwsze rozwiązanie obejmowało automatyczne testowanie z wirtualnymi uwierzytelniaczami za pomocą Puppeteer lub Selenium z wykorzystaniem protokołu wirtualnego uwierzytelniczego WebDriver. Ta metoda oferuje wysoką prędkość i doskonałą powtarzalność dla testów regresyjnych obsługi serwerowej wyzwań-odpowiedzi oraz logiki analizy CBOR. Jednak nie odtwarza specyficznych dla sprzętu dziwactw—takich jak konflikty wskazówek transportowych YubiKey z implementacją NFC w Safari lub różnice w polityce uprawnień iframe między Chrome a Safari—i nie może symulować biometrycznych monity UV ani interakcji fizycznych.
Drugie rozwiązanie zaproponowało doraźne testowanie ręczne przy użyciu dostępnych w biurze urządzeń, aby na bieżąco uzyskiwać opinie na temat doświadczeń użytkowników. Chociaż to podejście uchwyciło rzeczywiste zachowanie przeglądarek, prowadziło do niespójności w pokryciu i powtarzalności; testerzy często przeoczyli, że urządzenia Android wymagają parowania BLE dla kluczy bezpieczeństwa, podczas gdy iOS preferuje NFC, co prowadziło do fałszywych negatywów. Ponadto, brak strukturalnej weryfikacji poświadczenia oznaczał, że nie mogliśmy odróżnić autentycznego YubiKey od skompromitowanego klona firmware zwracającego nieważne łańcuchy certyfikatów X.509 lub niepoprawne wartości AAGUID.
Trzecie rozwiązanie wprowadziło zorganizowany reżim testowania matryc uwierzytelniaczy z użyciem fizycznych urządzeń, gdzie skatalogowaliśmy możliwości każdego uwierzytelnicza (wsparcie dla kluczy rezydentów, format poświadczenia, typy transportu) i ręcznie przeprowadziliśmy ceremonie w różnych kombinacjach przeglądarek i systemów operacyjnych. Przechwytywaliśmy ruch za pomocą Burp Suite i narzędzi deweloperskich przeglądarki, aby sprawdzić clientDataJSON i attestationObject, testując szczególnie scenariusze cross-origin, osadzając przepływ rejestracji w iframe z różnymi atrybutami allow i weryfikując zachowanie klucza rezydenta, ustawiając requireResidentKey: true i próbując uwierzytelnić się z pustą tablicą allowCredentials.
Wybór rozwiązania i wynik
Wybraliśmy zorganizowane podejście ze względu na to, że zachowanie WebAuthn jest zasadniczo związane z implementacją sprzętu i polityką bezpieczeństwa przeglądarek, których środowiska wirtualne nie mogą emulować. Ta metodologia ujawniła, że Safari wymaga jawnych atrybutów allow="publickey-credentials-get" dla iframes cross-origin, które Chrome wnioskuje automatycznie, co powoduje ciche awarie w integracji z Epic. Dodatkowo, odkryliśmy, że YubiKey 5 NFC zwraca transports: ["nfc", "usb"], ale iOS Safari w trakcie ceremonii wymienia jedynie nfc, co powoduje, że filtr allowCredentials po stronie serwera odrzuca poświadczenie, gdy walidacja transportu była surowo egzekwowana. Po poluzowaniu walidacji transportu po stronie serwera, aby akceptować dowolny transport reklamowany przez uwierzytelnicz, i dodaniu kontroli uprawnień iframe do naszego ręcznego wykazu testów, uwierzytelnianie między urządzeniami zadziałało konsekwentnie w ekosystemie różnych urządzeń szpitala.
Jak ręcznie weryfikujesz kryptograficzną integralność obiektu poświadczenia, aby upewnić się, że uwierzytelniacz jest autentyczny, a nie skompromitowany firmware lub emulator podczas testowania czarnej skrzynki?
Wielu kandydatów zakłada, że weryfikacja poświadczenia jest wyłącznie problemem po stronie serwera. Aby ręcznie zweryfikować, wydobądź attestationObject z odpowiedzi PublicKeyCredential w przeglądarce (zdekoduj base64url na binarny), przeanalizuj to za pomocą debugera CBOR (takiego jak cbor.me) i sprawdź pole fmt. Dla poświadczeń packed potwierdź łańcuch certyfikatów X.509 w odniesieniu do FIDO Alliance Metadata Service (MDS), aby sprawdzić, czy uwierzytelnicze są unieważnione lub czy flagi samoświadectwa są ustawione. Dla poświadczeń tpm zweryfikuj, czy certyfikat TPM zawiera EK (klucz potwierdzający) i czy struktura certInfo odpowiada oczekiwanemu algorytmowi skrótu. Ta ręczna inspekcja wykrywa uwierzytelnicze zwracające źle uformowane podpisy lub niepoprawne wartości AAGUID, które skrypty automatyczne mogą przeoczyć, jeśli pominą surową weryfikację poświadczenia.
Jaka jest dokładna różnica między Obecnością Użytkownika (UP) a Weryfikacją Użytkownika (UV) i jak wpływa to na testowanie kluczy rezydentów (poświadczenia do odkrycia) między uwierzytelniaczami platformowymi a przenośnymi?
Kandydaci często mylą prosty dotyk na YubiKey (UP) z wprowadzeniem PIN-u (UV). W testowaniu ręcznym musisz zweryfikować, że ustawienie userVerification: "discouraged" nadal pozwala na rejestrację na YubiKey (które dokonuje tylko UP), ale ustawienie residentKey: "required" zmusza do UV w przypadku większości uwierzytelniaczy, ponieważ klucze rezydentów wymagają ochrony. Testerzy przeoczają, że Windows Hello zawsze wykonuje UV (biometryczne lub PIN), nawet gdy zostanie odradzone, podczas gdy macOS Touch ID respektuje flagę, ale nie udaje się stworzyć klucza rezydenta bez UV. Musisz ręcznie przetestować ceremonię zarówno z required, jak i preferred kluczami rezydentów, obserwując, czy uwierzytelniacz zwraca credentialId podczas uwierzytelnienia bez allowCredentials (udowadniając, że był rezydentem) i sprawdzając bajty flagi authenticatorData (bit 0 dla UP, bit 2 dla UV) za pomocą parsera CBOR, aby potwierdzić, że zachowanie uwierzytelnicza odpowiada opcjom.
Jak testujesz funkcjonalność excludeCredentials, aby zapobiec podwójnym rejestracjom, gdy masz tylko jeden fizyczny klucz bezpieczeństwa, zapewniając, że uwierzytelniacz poprawnie identyfikuje istniejące poświadczenia?
To sprawdzanie zrozumienia klienta mechanizmu odkrywania. Ręcznie zarejestruj poświadczenie, przechwyć rawId, a następnie rozpocznij nową ceremonię rejestracji z excludeCredentials, zawierającą ten identyfikator i to samo user.id. Zgodny uwierzytelnicz powinien zwrócić DOMException o nazwie InvalidStateError. Jednak kandydaci mogą przeoczyć, że Windows Hello i niektóre keystore'y Android mogą zwrócić istniejące poświadczenie zamiast błędu (co jest ważne zgodnie z specyfikacją WebAuthn poziomu 2, jeśli uwierzytelnicz nie obsługuje list wykluczeń). Musisz zweryfikować oba wyniki: że serwer obsługuje błąd w sposób płynny oraz że jeśli poświadczenie zostanie zwrócone, pasuje do wykluczonego identyfikatora i jest odrzucane po stronie serwera. Ponadto, przetestuj z innym user.id, aby upewnić się, że uwierzytelniacz nie wyklucza błędnie poświadczeń z różnych kont użytkowników, co wskazywałoby na poważną lukę w prywatności.