WebAuthn testi, FIDO2 standartlarının eski U2F'yi değiştirmesiyle ortaya çıktı ve bu, istemci verileri, doğrulama nesneleri ve kriptografik zorlukları içeren karmaşık tören durumu makineleri getirdi. Temel sorun, otantikleyici heterojenliğindedir; Windows Hello gibi platform otantikleyicileri, yerleşik anahtar depolaması, taşıma protokolleri (USB, NFC, BLE) ve UV gereksinimleri açısından YubiKey gibi gezinen donanımlardan önemli ölçüde farklıdır, ayrıca tarayıcılar çapraz kaynaklı bağlamlar için farklı izin politikaları uygular. Sistematik bir manuel metodoloji, her cihazın doğrulama formatı (packed, tpm, fido-u2f), yetenekleri ve taşıma kullanılabilirliği ile sınıflandırıldığı bir otantikleyici taksonomisi haritalaması gerektirir. Test edenler, Chrome, Safari, Firefox ve Edge üzerinden kaydettirme ve kimlik doğrulama törenlerini manuel olarak çalıştırmalı, CBOR kodlu doğrulama nesnelerini tarayıcı DevTools aracılığıyla inceleyerek fmt ve attStmt yapısını FIDO Metadata Service (MDS) ile doğrulamalıdır. Çapraz kaynaklı iframe bağlamlarına özel dikkat gösterilmelidir; allow="publickey-credentials-create" ve allow="publickey-credentials-get" izinlerinin doğru şekilde uygulanıp uygulanmadığını ve yerleşik anahtar akışlarının excludeCredentials filtresini doğru bir şekilde işlediğini doğrulamak için dikkatli olunmalıdır.
Bir sağlık portalı, CDN alt alanından sunulan bir React widget'ı içinde WebAuthn kaydını gömdü ve hekimlerin ikinci faktör kimlik doğrulaması için YubiKey 5 NFC veya şifresiz giriş için macOS Touch ID kullanmasına izin verdi. Hekimler, iOS üzerinde Safari'nin başarılı kayıt sonrası YubiKey'i NFC ile tanımadığını ve widget'ın hastanenin Epic elektronik sağlık kayıt sistemi içinde çapraz kaynaklı bir iframe'de yüklendiğinde Touch ID istemlerinin sessizce başarısız olduğunu bildirdi. Bu donanım özel entegrasyon hatalarının kök nedenini izole etmek için üç ayrı yaklaşım düşündük.
İlk çözüm, WebDriver sanal otantikleyici protokolü kullanarak Puppeteer veya Selenium ile sanal otantikleyicilerle otomatik testler gerçekleştirmekti. Bu yöntem, sunucu tarafında zorluk-cevap işleyişini ve CBOR ayrıştırma mantığını geri test etmek için yüksek hız ve mükemmel tekrarlanabilirlik sunar. Ancak, YubiKey taşıma ipuçlarının Safari'nin NFC uygulamasıyla çelişmesi veya Chrome ve Safari arasında iframe izin politikası farklılıklarını yeniden üretmekte başarısızdır ve biyometrik UV istemlerini veya fiziksel dokunma etkileşimlerini simüle edemez.
İkinci çözüm, ofiste mevcut olan cihazlarla acil durum manuel testleri yapmayı önerdi. Bu yaklaşım, gerçek dünya tarayıcı davranışlarını yakalasa da, tutarsız kapsama ve tekrarlanabilirlik sonuçları doğurdu; test edenler genellikle Android cihazların güvenlik anahtarları için BLE eşleştirmesi gerektirdiğini, iOS'un ise NFC'yi tercih ettiğini atladılar, bu da yanlış negatiflere yol açtı. Ayrıca, yapılandırılmış bir doğrulama kontrolü eksikliği, gerçek bir YubiKey ile geçersiz X.509 sertifika zincirleri veya yanlış AAGUID değerlerini döndüren bir firmware klonu arasında ayrım yapmamızı engelledi.
Üçüncü çözüm, fiziksel cihazlarla yapılandırılmış bir otantikleyici matris testi düzeni uyguladı ve her otantikleyicinin yeteneklerini (yerleşik anahtar desteği, doğrulama formatı, taşıma türleri) katalogladık ve tarayıcı ve işletim sistemi kombinasyonları arasında törenleri manuel olarak yürüttük. Burp Suite ve tarayıcı DevTools ile trafiği yakalayarak clientDataJSON ve attestationObject'u inceledik, özellikle kayıt akışını farklı allow öznitelikleri ile gömülü iframes'de test ederek yerleşik anahtar davranışını doğrulamak için requireResidentKey: true ayarını belirleyip boş bir allowCredentials dizisi ile kimlik doğrulama yapmaya çalıştık.
Seçilen çözüm ve sonuç
WebAuthn davranışı, donanım uygulaması ve sanal ortamların emüle edemediği tarayıcı güvenlik politikaları ile temel olarak bağdaştığı için yapılandırılmış matris yaklaşımını seçtik. Bu metodoloji, Safari'nin çapraz kaynaklı iframes için açıkça allow="publickey-credentials-get" özniteliklerine ihtiyaç duyduğunu, Chrome'un ise bunu otomatik olarak çıkardığını ortaya koydu ve bu, Epic entegrasyonundaki sessiz hatalara neden oldu. Ayrıca, YubiKey 5 NFC'nin transports: ["nfc", "usb"] döndürdüğünü ancak iOS Safari'nin tören sırasında sadece nfc'yi sıraladığını keşfettik; bu durum, sunucu tarafında allowCredentials filtresinin kimlik bilgisini reddetmesine neden oldu. Sunucu tarafında taşıma doğrulamasını, otantikleyicinin reklamı yapılan her taşıyıcıyı kabul edecek şekilde gevşettikten sonra ve manuel test kontrol listemize iframe izin kontrolleri ekledikten sonra, çapraz cihaz kimlik doğrulaması hastanenin karışık cihaz ekosisteminde tutarlı bir şekilde başarıya ulaştı.
Otantikleyicinin gerçekten mevcut olduğunu ve sahte firmware veya emülatör olmadığını doğrulamak için bir doğrulama nesnesinin kriptografik bütünlüğünü nasıl manuel olarak doğruluyorsunuz?
Birçok aday, doğrulama kontrolünün tamamen sunucu tarafı bir endişe olduğunu varsayıyor. Manuel olarak doğrulamak için, tarayıcının PublicKeyCredential yanıtından attestationObject'u çıkarın (base64url'den ikiliye çözün), bir CBOR hata ayıklayıcı ile ayrıştırın (cbor.me gibi) ve fmt alanını kontrol edin. Packed doğrulama için, bireysel otantikleyicilerin geçersiz olduğunu kontrol etmek için X.509 sertifika zincirini FIDO Alliance Metadata Service (MDS) ile doğrulayın veya kendine ait doğrulama bayraklarını kontrol edin. TPM doğrulaması için, TPM sertifikasının EK (Onay Anahtarı) içerip içermediğini ve certInfo yapısının beklenen karma algoritmasıyla eşleşip eşleşmediğini doğrulayın. Bu manuel inceleme, otomatik betiklerin katı doğrulama kontrolünü atlayabileceği hatalı imzalar veya yanlış AAGUID değerleri döndüren otantikleyicileri yakalar.
Kullanıcı Varlığı (UP) ve Kullanıcı Doğrulama (UV) arasındaki kesin ayrım nedir ve bu, yerleşik anahtarların (bulunabilir kimlik bilgileri) platform ve gezinen otantikleyiciler arasında test edilmesini nasıl etkiler?
Adaylar sıklıkla YubiKey ile basit bir dokunuşu (UP) PIN girişinin (UV) bir eşlemesi olarak karıştırır. Manuel testte, userVerification: "discouraged" ayarının kayıt işlemi sırasında bir YubiKey üzerinde hala izin verip vermediğini doğrulamak zorundasınız (bu yalnızca UP yapar), ancak residentKey: "required" ayarı çoğu otantikleyici üzerinde UV zorladı çünkü yerleşik anahtarların korunması gerektirir. Test edenler, Windows Hello'nun her zaman UV (biyometrik veya PIN) gerçekleştirirken, macOS Touch ID'nin beyanını dikkate aldığı ancak UV olmadan yerleşik anahtar oluşturulmasında başarısız olduğunu kaçırırlar. Hem required hem de preferred yerleşik anahtarlarla töreni manuel olarak test etmelisiniz, otantikleyicinin allowCredentials olmadan kimlik bilgisi döndürüp döndürmediğini kontrol ederek (yerleşik olmasını kanıtlar) ve otantikleyici davranışının seçeneklerle eşleşip eşleşmediğini onaylamak için CBOR ayrıştırıcısını kullanarak authenticatorData baytını kontrol etmelisiniz (bit 0 için UP, bit 2 için UV).
Tüketici kimlik bilgilerini tekrar kayıt etmeme işlevini test etmek için yalnızca bir fiziksel güvenlik anahtarına sahipken, otantikleyicinin mevcut kimlik bilgilerini doğru bir şekilde tanımladığından nasıl emin oluyorsunuz?
Bu, istemci tarafı keşif mekanizmasını anlamayı test eder. Manuel olarak bir kimlik bilgisi kaydedin, rawId'yi yakalayın, ardından yeni bir kayıt töreni başlatın ve excludeCredentials içerisine o kimlik bilgisini ve aynı user.id'yi yerleştirin. Uygun bir otantikleyici, InvalidStateError adında bir DOMException döndürmelidir. Ancak, adaylar, Windows Hello ve bazı Android anahtar kasalarının mevcut kimlik bilgisini bir hata yerine döndürebileceğini atlayabilirler (bu, otantikleyici hariç liste desteği yoksa WebAuthn Seviye 2 spesifikasyonuna göre geçerlidir). Her iki durumu da doğrulamalısınız: sunucunun hatayı düzgün bir şekilde ele alması ve eğer bir kimlik bilgisi dönerse, bunun dışlanan kimlik bilgisiyle eşleşip eşleşmediğini ve server tarafında reddedildiğini sağlamalısınız. Ayrıca, farklı bir user.id ile test ederek otantikleyicinin farklı kullanıcı hesaplarından kimlik bilgilerini yanlış bir şekilde hariç tutmadığından emin olmalısınız; bu, ciddi bir gizlilik açığı gösterecektir.