Тестирование WebAuthn возникло, когда стандарты FIDO2 заменили устаревший U2F, вводя сложные машины состояний процессов, включающих клиентские данные, объекты аттестации и криптографические задачи. Основная проблема заключается в разнообразии аутентификаторов; платформенные аутентификаторы, такие как Windows Hello, отличаются радикально от обыкновенных аппаратных устройств, таких как YubiKey, по хранению резидентных ключей, транспортным протоколам (USB, NFC, BLE) и требованиям UV, в то время как браузеры налагают разные политики разрешений для кросс-доменных контекстов. Систематическая ручная методология требует картирования таксономии аутентификаторов, где каждое устройство классифицируется по его формату аттестации (packed, tpm, fido-u2f), возможностям и доступности транспорта. Тестировщики должны вручную выполнять церемонии регистрации и аутентификации в Chrome, Safari, Firefox и Edge, исследуя CBOR-кодированные объекты аттестации через инструменты разработчика браузера, чтобы проверить структуру fmt и attStmt на соответствие Службе метаданных FIDO (MDS). Особое внимание следует уделить кросс-доменным контекстам iframe, проверяя, что разрешения allow="publickey-credentials-create" и allow="publickey-credentials-get" применяются правильно, и что резидентные ключевые потоки корректно обрабатывают фильтр excludeCredentials, чтобы предотвратить дублирующиеся регистрации.
Медицинский портал встроил регистрацию WebAuthn внутри React-виджета, размещаемого из поддомена CDN, позволяя врачам использовать YubiKey 5 NFC для аутентификации второго фактора или macOS Touch ID для входа без пароля. Врачи сообщили о периодических сбоях, при которых Safari на iOS не распознавал YubiKey через NFC после успешной регистрации в десктопном Chrome, и запросы Touch ID завершались молча, когда виджет загружался в кросс-доменном iframe внутри системы учёта электронных медицинских записей Epic. Мы рассматривали три различных подхода для изоляции коренной причины этих интеграционных сбоев, специфичных для оборудования.
Первое решение включало автоматизированное тестирование с виртуальными аутентификаторами через Puppeteer или Selenium с использованием виртуального протокола аутентификатора WebDriver. Этот метод предлагает высокую скорость и идеальную повторяемость для регрессии обработки серверных задач на основе ответов и логики разбора CBOR. Однако он не может воспроизвести особенности, специфичные для оборудования — такие как конфликтующие подсказки по передаче YubiKey с реализацией NFC в Safari или различия в политике разрешений iframe между Chrome и Safari — и не может смоделировать биометрические запросы UV или физические взаимодействия касания.
Второе решение предложило произвольное ручное тестирование с использованием всех доступных в офисе устройств для предоставления мгновенной обратной связи о пользовательском опыте. Хотя этот подход фиксирует поведение браузера в реальном мире, он приводит к непоследовательному покрытию и воспроизводимости; тестировщики часто упускали из виду, что Android-устройства требуют сопряжения BLE для ключей безопасности, в то время как iOS предпочитает NFC, что приводит к ложным отрицаниям. Кроме того, отсутствие структурированной проверки аттестации означало, что мы не смогли бы отличить настоящую YubiKey от скомпрометированного программного обеспечения, возвращающего недействительные цепочки сертификатов X.509 или неправильные значения AAGUID.
Третье решение реализовало структурированную методику тестирования матрицы аутентификаторов с физическими устройствами, где мы каталогизировали возможности каждого аутентификатора (поддержка резидентного ключа, формат аттестации, типы транспорта) и вручную выполняли церемонии через комбинации браузера и ОС. Мы перехватывали трафик с помощью Burp Suite и инструментов разработчика браузера, чтобы исследовать clientDataJSON и attestationObject, тестируя специализированные кросс-доменные сценарии, встраивая поток регистрации в iframes с различными атрибутами allow и проверяя поведение резидентного ключа, устанавливая requireResidentKey: true и пытаясь аутентифицироваться с пустым массивом allowCredentials.
Выбранное решение и результат
Мы выбрали структурированный матричный подход, потому что поведение WebAuthn связано с осуществлением аппаратного обеспечения и политик безопасности браузера, которые виртуальные среды не могут эмулировать. Эта методология выявила, что Safari требует явных атрибутов allow="publickey-credentials-get" для кросс-доменных iframes, которые Chrome автоматически подразумевает, что и вызвало молчаливые сбои в интеграции с Epic. Кроме того, мы обнаружили, что YubiKey 5 NFC возвращает transports: ["nfc", "usb"], но iOS Safari перечисляет только nfc во время церемонии, в результате чего серверный фильтр allowCredentials отклоняет учетные данные, когда проверка транспорта была строго выполнена. После ослабления проверки транспорта на стороне сервера, чтобы принимать любой транспорт, рекламируемый аутентификатором, и добавления проверок разрешений iframe в наш контрольный список ручного тестирования, аутентификация между разными устройствами прошла успешно в смешанной экосистеме устройств больницы.
Как вручную проверить криптографическую целостность объекта аттестации, чтобы убедиться, что аутентификатор является подлинным, а не скомпрометированным программным обеспечением или эмулятором во время черного ящика тестирования?
Многие кандидаты предполагают, что проверка аттестации — это чисто серверная задача. Чтобы вручную проверить, извлеките attestationObject из ответа PublicKeyCredential браузера (кодируйте в base64url в бинарный формат), проанализируйте его с помощью отладчика CBOR (например, cbor.me) и проверьте поле fmt. Для packed аттестации проверьте цепочку сертификатов X.509 с помощью Службы метаданных ФИДО (MDS), чтобы проверить, нет ли аннулированных аутентификаторов или флагов самоаттестации. Для 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 резидентными ключами, наблюдая, возвращает ли аутентификатор credentialId во время аутентификации без allowCredentials (доказывая, что он был резидентным), и проверяя байт флага authenticatorData (бит 0 для UP, бит 2 для UV) с использованием парсера CBOR, чтобы подтвердить, что поведение аутентификатора соответствует параметрам.
Как протестировать функциональность excludeCredentials, чтобы предотвратить дублирующую регистрацию, если у вас только один физический ключ безопасности, чтобы гарантировать, что аутентификатор правильно идентифицирует существующие учетные данные?
Это тестирует понимание механизма клиентского обнаружения. Вручную зарегистрируйте учетные данные, захватите rawId, затем начните новую церемонию регистрации с excludeCredentials, содержащим этот ID и тот же user.id. Соответствующий аутентификатор должен вернуть DOMException с именем InvalidStateError. Однако кандидаты могут упустить из виду, что Windows Hello и некоторые Android-хранилища могут вместо ошибки вернуть существcredential (что допустимо согласно спецификации WebAuthn Уровня 2, если аутентификатор не поддерживает исключительные списки). Вы должны проверить оба результата: чтобы сервер обрабатывал ошибку гибко и чтобы, если ключевые данные возвращаются, они соответствовали исключенному ID и отклонялись на стороне сервера. Также протестируйте с другим user.id, чтобы убедиться, что аутентификатор не исключает ошибочно ключевые данные из разных учетных записей пользователей, что будет означать серьезную уязвимость конфиденциальности.