Поделиться через

Обзор расширенной защиты для проверки подлинности

Расширенная защита для проверки подлинности помогает защитить от атак злоумышленника в середине (MITM), при которых злоумышленник перехватывает учетные данные клиента и пересылает их на сервер.

Рассмотрим сценарий с тремя участниками: клиентом, сервером и злоумышленником. Сервер имеет URL-адрес https://server, а злоумышленник имеет URL-адрес https://attacker. Злоумышленник обманным путем заставляет клиента обращаться к нему, как если бы он был сервером. Затем злоумышленник отправляет запрос на сервер. Если злоумышленник пытается получить доступ к защищенному ресурсу, сервер отвечает злоумышленнику с заголовком WWW-Authenticate. Злоумышленник не имеет данных аутентификации, поэтому он отправляет заголовок WWW-Authenticate на клиент. Клиент отправляет заголовок авторизации злоумышленнику, а злоумышленник отправляет заголовок на сервер и получает доступ к защищенным ресурсам с помощью учетных данных клиента.

В настоящее время, когда клиентское приложение проходит проверку подлинности на сервере с помощью Kerberos, Digest или NTLM с помощью HTTPS, сначала устанавливается канал безопасности уровня транспорта (TLS), а проверка подлинности выполняется с помощью этого канала. Однако между ключом сеанса, созданным протоколом SSL, и ключом сеанса, созданным во время проверки подлинности, отсутствует привязка. Таким образом, в предыдущем сценарии, если обмен данными выполняется через TLS (например, канал HTTPS), между клиентом и злоумышленником создаются два SSL-канала, а другой между злоумышленником и сервером. Учетные данные клиента отправляются от клиента на сервер сначала через SSL-канал между клиентом и злоумышленником, а затем через канал между злоумышленником и сервером. Когда учетные данные клиента достигают сервера, сервер проверяет учетные данные, не обнаруживая, что канал, по которому эти учетные данные были отправлены злоумышленником, а не клиентом.

Решение — использовать защищенный TLS внешний канал и внутренний канал, прошедший проверку подлинности клиента, и передать маркер привязки канала (CBT) на сервер. CBT является свойством защищенного протоколом TLS внешнего канала и используется для привязки внешнего канала к сеансу через внутренний канал аутентификации клиента.

В предыдущем сценарии CBT TLS-канала между клиентом и злоумышленником объединяется с информацией об авторизации, отправляемой на сервер. Сервер с поддержкой CBT сравнивает CBT, содержащийся в сведениях о проверке подлинности клиента, который соответствует каналу клиента-злоумышленника, с CBT, подключенным к каналу нападающего сервера. Тест CBT специфичен для назначения канала, поэтому CBT клиента-злоумышленника не соответствует CBT злоумышленник-сервер. Это позволяет серверу обнаружить атаку MITM и отказаться от запроса проверки подлинности.

Клиентская сторона не требует каких-либо параметров конфигурации. После обновления клиента для передачи CBT на сервер он всегда делает это. Если сервер также обновлен, его можно настроить для использования CBT или игнорировать его. Если он не был обновлен, он игнорирует его.

Сервер может иметь следующие уровни защиты:

  • Нет. Проверка привязки канала не выполняется. Это поведение всех серверов, которые не были обновлены.

  • Частично. Все клиенты, которые были обновлены, должны предоставить сведения о привязке канала к серверу. Клиенты, которые не были обновлены, не должны делать это. Это промежуточный параметр, позволяющий обеспечить совместимость приложений.

  • Полный. Все клиенты должны предоставлять сведения о привязке канала. Сервер отклоняет запросы проверки подлинности от клиентов, которые этого не делают.

Дополнительные сведения см. в примере Win7 CBT/Extended Protection.

См. также