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


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

Расширенная защита для проверки подлинности обеспечивает защиту от атак типа «злоумышленник в середине», когда злоумышленник перехватывает клиентские учетные данные и отправляет их на сервер.

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

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

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

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

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

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

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

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

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

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

См. также