WebAuthn 테스트는 FIDO2 표준이 기존 U2F를 대체하면서 클라이언트 데이터, 인증 객체 및 암호화된 도전 과제를 포함하는 복잡한 세례 상태 기계를 도입했습니다. 핵심 문제는 인증기의 이질성에 있습니다; Windows Hello와 같은 플랫폼 인증기는 YubiKey와 같은 로밍 하드웨어와 다르게 거주 키 저장소, 전송 프로토콜(USB, NFC, BLE) 및 UV 요건에서 크게 다릅니다. 또한 브라우저는 크로스 오리진 컨텍스트에 대해 서로 다른 권한 정책을 시행합니다. 체계적인 수동 방법론은 각 장치가 인증 형식(packed, tpm, fido-u2f), 기능 및 전송 가능성에 따라 분류되는 인증기 분류도를 요구합니다. 테스터는 Chrome, Safari, Firefox, Edge 전반에 걸쳐 등록 및 인증 행사를 수동으로 실행하며, 브라우저 DevTools를 통해 CBOR 인코딩된 인증 객체를 검사하여 fmt 및 attStmt 구조가 **FIDO 메타데이터 서비스 (MDS)**에 맞는지 검증해야 합니다. 크로스 오리진 iframe 컨텍스트에 특별한 주의를 기울여야 하며, allow="publickey-credentials-create" 및 allow="publickey-credentials-get" 권한이 올바르게 시행되고, 거주 키 흐름이 중복 등록을 방지하기 위해 excludeCredentials 필터를 올바르게 처리하는지 확인해야 합니다.
의료 포털은 React 위젯 내부에 WebAuthn 등록을 포함시켜 CD원 서브도메인으로 제공하며, 의사들은 YubiKey 5 NFC를 사용하는 이중 인증 또는 macOS Touch ID를 사용하여 비밀번호 없는 로그인을 할 수 있게 했습니다. 의사들은 iOS의 Safari에서 YubiKey가 성공적으로 등록된 후 NFC를 통해 인식되지 않는 간헐적인 실패를 보고했으며, Touch ID 프롬프트가 병원의 Epic 전자 건강 기록 시스템의 크로스 오리진 iframe에 로드되었을 때 조용히 실패했습니다. 우리는 이러한 하드웨어 특정 통합 실패의 근본 원인을 분리하기 위해 세 가지 구별된 접근 방식을 고려했습니다.
첫 번째 해결책은 Puppeteer 또는 Selenium을 사용하여 WebDriver 가상 인증기 프로토콜을 통해 가상 인증기로 자동화된 테스트를 수행하는 것이었습니다. 이 방법은 서버 측 도전-응답 처리 및 CBOR 파싱 로직에 대한 회귀 테스트에 높은 속도와 완벽한 재현성을 제공합니다. 하지만 이는 YubiKey 전송 힌트가 Safari의 NFC 구현과 충돌하는 것과 같은 하드웨어 특정 변칙을 재현하지 못하고 생체 UV 프롬프트나 물리적 탭 상호작용을 시뮬레이션할 수 없습니다.
두 번째 해결책은 사무실에 있는 어떤 장치든 사용하여 즉각적인 사용자 경험 피드백을 제공하는 즉흥적 수동 테스트를 제안했습니다. 이 접근법은 실제 웹 브라우저 동작을 캡처하지만 일관되지 않은 범위와 재현성을 초래합니다. 테스터는 종종 Android 장치가 보안 키에 대한 BLE 페어링을 요구하는 반면 iOS는 NFC를 선호한다는 사실을 놓쳐 잘못된 부정확성으로 이어졌습니다. 또한, 구조화된 인증 검증의 부족으로 인해 우리는 진짜 YubiKey와 부정한 펌웨어 클론이 잘못된 X.509 인증서 체인이나 잘못된 AAGUID 값을 반환하는 것을 구별할 수 없었습니다.
세 번째 해결책은 물리적 장치를 활용한 구조화된 인증기 매트릭스 테스트 방식으로, 우리는 각 인증기의 기능(거주 키 지원, 인증 형식, 전송 유형)을 목록화하고 브라우저와 OS 조합을 통해 수동으로 행사를 실행했습니다. 우리는 Burp Suite와 브라우저 DevTools를 통해 트래픽을 가로채 clientDataJSON 및 attestationObject를 검사했으며, allow 속성이 다양한 iframe에 대한 등록 흐름을 포함시켜 크로스 오리진 시나리오를 테스트하고, requireResidentKey: true를 설정하고 빈 allowCredentials 배열로 인증을 시도하여 거주 키 동작을 검증했습니다.
선택된 솔루션과 결과
우리는 WebAuthn 동작이 하드웨어 구현 및 브라우저 보안 정책에 근본적으로 연결되어 있으며 가상 환경이 이를 모방할 수 없기 때문에 구조적 매트릭스 접근방식을 선택했습니다. 이 방법론을 통해 Safari가 크로스 오리진 iframe에 대해 명시적인 allow="publickey-credentials-get" 속성이 필요하다는 것을 발견했으며, 이는 Chrome이 자동으로 추론하여 Epic 통합에서의 조용한 실패를 초래했습니다. 또한, YubiKey 5 NFC는 transports: ["nfc", "usb"]를 반환하지만 iOS Safari는 행사 중에 nfc만 열거하여 서버 측 allowCredentials 필터가 전송 유효성 검증이 엄격히 시행될 때 자격 증명을 거부하게 했습니다. 인증기에서 광고한 모든 전송을 수용하도록 서버 측 전송 유효성 검증을 완화하고 수동 테스트 체크리스트에 iframe 권한 검사를 추가한 후 병원의 혼합 장치 생태계에서 교차 장치 인증이 일관되게 성공했습니다.
블랙박스 테스트 중 인증기가 진짜인지, 손상된 펌웨어 또는 에뮬레이터가 아닌지 보장하기 위해 인증 객체의 암호학적 무결성을 수동으로 어떻게 검증합니까?
많은 후보자들은 인증 검증이 순전히 서버 측 문제라고 가정합니다. 수동으로 검증하기 위해 브라우저의 PublicKeyCredential 응답에서 attestationObject를 추출하고( base64url로 이진 데이터로 디코드) CBOR 디버거(예: cbor.me)를 사용하여 구문 분석하고 fmt 필드를 확인하십시오. packed 인증의 경우, **FIDO Alliance Metadata Service (MDS)**에 대해 X.509 인증서 체인을 검증하여 손상된 인증기 또는 자가 인증 플래그를 확인합니다. tpm 인증의 경우, TPM 인증서가 EK (엔도스먼트 키)를 포함하는지 및 certInfo 구조가 기대하는 해시 알고리즘과 일치하는지 검증합니다. 이 수동 검사는 자동화된 스크립트가 철저한 인증 검증을 건너뛰는 경우 간과할 수 있는 잘못된 서명을 반환하거나 잘못된 AAGUID 값을 반환하는 인증기를 포착합니다.
사용자 존재(UP)와 사용자 검증(UV) 간의 정확한 구분은 무엇이며, 이것이 플랫폼 인증기와 로밍 인증기 간의 거주 키(발견 가능한 자격 증명) 테스트에 어떤 영향을 미칩니까?
후보자들은 종종 YubiKey의 간단한 터치를 (UP) PIN 입력(UV)과 혼동합니다. 수동 테스트 시, userVerification: "discouraged"를 설정해도 YubiKey에서의 등록이 가능하도록 검증해야 합니다(이는 UP만 수행됨). 그러나 residentKey: "required"를 설정하면 대부분의 인증기에서 UV가 필요하므로 거주 키가 보호되어야 합니다. 테스터는 Windows Hello가 권장되지 않더라도 항상 UV(생체 인식 또는 PIN)를 수행한다는 사실을 놓치는 경우가 많고, macOS Touch ID는 플래그를 존중하지만 UV 없이 거주 키 생성을 실패합니다. required와 preferred 거주 키 모두에 대해 행사를 수동으로 테스트하여 인증기가 allowCredentials 없이 인증 중에 credentialId를 반환하는지 확인해야 하며(거주했음을 증명함), authenticatorData 플래그 바이트를 확인하여 (비트 0은 UP, 비트 2는 UV) 인증기의 동작이 옵션과 일치하는지 확인해야 합니다.
물리적 보안 키가 하나만 있을 때 excludeCredentials 기능을 테스트하여 인증기가 기존 자격 증명을 올바르게 식별하도록 하여 중복 등록을 방지할 수 있는 방법은?
이것은 클라이언트 측 발견 메커니즘에 대한 이해를 시험합니다. 자격 증명을 수동으로 등록하고 rawId를 캡처한 다음, 같은 user.id를 가진 excludeCredentials를 포함하여 새로운 등록 행사를 시작합니다. 호환되는 인증기는 InvalidStateError라는 명명의 DOMException을 반환해야 합니다. 그러나 후보자들은 Windows Hello와 일부 Android 키 저장소가 ID와 동일한 자격 증명을 반환할 수 있음을 간과할 수 있습니다(이는 인증기가 제외 목록을 지원하지 않을 경우 WebAuthn 레벨 2 사양에 따라 유효합니다). 두 결과를 모두 검증해야 합니다: 서버가 오류를 원활하게 처리하는지, 자격 증명이 반환되면 그것이 제외된 ID와 일치하여 서버 측에서 거부되는지 확인해야 합니다. 또한, 인증기에서 잘못된 사용자 계정으로부터의 자격 증명을 잘못 제외하지 않는지 확인하기 위해 다른 user.id로 테스트를 진행해야 하며, 이는 심각한 개인 정보 보호 취약점이 될 것입니다.