Учетные данные сеанса, привязанные к устройству (DBSC)

Учетные данные сеанса, привязанные к устройству (DBSC), усиливают аутентификацию, добавляя аппаратную поддержку безопасности сеанса.

Daniel Rubery

José Luis Zapata

Введение

Многие веб-сайты используют долгоживущие файлы cookie для аутентификации пользователей, но они подвержены перехвату сеансов. Учётные данные сеанса, привязанные к устройству (DBSC), добавляют аппаратный уровень безопасности для снижения этого риска, обеспечивая привязку сеансов к определённым устройствам.

Это руководство предназначено для разработчиков, которые поддерживают процессы аутентификации в веб-приложениях. В нём объясняется, как работает DBSC и как интегрировать его в свой сайт.

Как работает DBSC

На высоком уровне DBSC представляет собой пару криптографических ключей, связанную с устройством пользователя. Chrome генерирует эту пару ключей при входе в систему и сохраняет закрытый ключ на защищённом оборудовании, например, в доверенном платформенном модуле (TPM) , если он доступен. Сеансы используют кратковременные файлы cookie. По истечении срока действия одного из этих файлов cookie Chrome подтверждает владение закрытым ключом перед их обновлением. Этот процесс обеспечивает непрерывность сеанса с исходным устройством.

Если устройство пользователя не поддерживает безопасное хранение ключей, DBSC корректно возвращается к стандартному поведению, не прерывая процесс аутентификации.

Обзор реализации

Чтобы интегрировать DBSC в ваше приложение, вам необходимо внести следующие изменения:

• Измените процесс входа в систему, включив заголовок Secure-Session-Registration .
• Добавьте конечную точку регистрации сеанса, которая:
  • Связывает открытый ключ с сеансом пользователя.
  • Обслуживает конфигурацию сеанса.
  • Переход на кратковременные файлы cookie.
• Добавьте конечную точку обновления для обработки обновления файлов cookie и проверки владения ключами.

Большинство ваших существующих конечных точек не требуют никаких изменений. DBSC разработан с учётом принципа аддитивности и не нарушает работу.

Если требуемый краткосрочный cookie-файл отсутствует или истёк, Chrome приостанавливает запрос и пытается обновить cookie-файл. Это позволяет приложению продолжать использовать обычные проверки cookie-файлов сеанса для подтверждения входа пользователя. Поскольку это соответствует типичным процессам аутентификации, DBSC работает с минимальными изменениями в логике входа.

Шаги реализации

В этом разделе подробно описываются необходимые изменения в вашей системе аутентификации, включая изменение процесса входа, обработку регистрации сеансов и управление кратковременными обновлениями файлов cookie. Каждый шаг разработан для плавной интеграции с вашей существующей инфраструктурой.

Шаги реализации соответствуют стандартной схеме, которая используется зарегистрированным пользователем при активном DBSC: регистрация при входе в систему, а затем регулярное кратковременное обновление файлов cookie. Вы можете протестировать и реализовать каждый шаг независимо, в зависимости от уровня чувствительности сеанса вашего приложения.

1. Измените процесс входа в систему

После входа пользователя в систему отправьте ему долговременный cookie-файл и заголовок Secure-Session-Registration . Например:

После успешной регистрации сеанса возвращается следующий заголовок HTTP-ответа:

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Если устройство поддерживает безопасное хранение ключей, Chrome связывается с конечной точкой /StartSession с открытым ключом в JSON Web Token (JWT).

В этом примере auth_cookie представляет собой токен вашего сеанса. Вы можете назвать этот cookie-файл как угодно, главное, чтобы имя совпадало с name в конфигурации сеанса и использовалось единообразно во всем приложении.

2. Реализуйте конечную точку регистрации сеанса.

В /StartSession ваш сервер должен:

• Свяжите полученный открытый ключ с сеансом пользователя.
• Ответьте конфигурацией сеанса.
• Замените долгоживущий файл cookie на короткоживущий.

В следующем примере кратковременный cookie-файл настроен на срок действия 10 минут:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Реализуйте конечную точку обновления.

По истечении срока действия краткосрочного cookie-файла Chrome инициирует процесс обновления, чтобы подтвердить владение закрытым ключом. Этот процесс включает в себя скоординированные действия Chrome и вашего сервера:

1. Chrome перенаправляет запрос пользователя в ваше приложение и отправляет запрос на обновление в /RefreshEndpoint :

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   

2. Ваш сервер отвечает вызовом:

   HTTP/1.1 403 Forbidden
   Secure-Session-Challenge: "challenge_value"
   

3. Chrome подписывает запрос, используя сохраненный закрытый ключ, и повторяет попытку:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   Secure-Session-Response: <JWT proof>
   

4. Ваш сервер проверяет подписанное доказательство и выдает обновленный кратковременный файл cookie:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome получает обновленный cookie-файл и возобновляет исходный отложенный запрос.

Альтернативная модель интеграции

Для повышения устойчивости сайты могут добавлять второй cookie-файл, не относящийся к DBSC, наряду с кратковременным cookie-файлом. Этот долговременный cookie-файл используется только для выпуска новых кратковременных токенов и помогает различать действительно неаутентифицированные запросы и временные сбои DBSC.

• Долговременный файл cookie сохраняется даже в случае сбоя DBSC.
• Краткосрочный cookie-файл обновляется с помощью DBSC и требуется для конфиденциальных операций.

Этот шаблон дает сайтам больше контроля над обработкой крайних случаев.

Предостережения и запасной вариант поведения

Chrome может пропускать операции DBSC и отправлять запросы без кратковременного cookie-файла, управляемого DBSC, в следующих сценариях:

• Конечная точка обновления недоступна из-за сетевых ошибок или проблем с сервером.
• Модуль TPM занят или обнаружил ошибки подписи. Поскольку модуль TPM используется несколькими системными процессами, чрезмерное количество обновлений может превысить его ограничения.
• Краткосрочный cookie-файл, управляемый DBSC, является сторонним cookie-файлом, а пользователь заблокировал сторонние cookie-файлы в настройках своего браузера.

В таких ситуациях Chrome возвращается к использованию долгоживущего cookie, если он всё ещё присутствует. Этот вариант работает только в том случае, если ваша реализация включает как долгоживущий, так и кратковременный cookie. В противном случае Chrome отправляет запрос без cookie.

Краткое содержание

Учётные данные сеанса, привязанные к устройству, повышают безопасность сеанса, позволяя вносить минимальные изменения в приложение. Они обеспечивают надёжную защиту от перехвата сеанса, привязывая сеансы к определённым устройствам. Большинство пользователей получают преимущества без каких-либо сбоев, а DBSC корректно отключается на неподдерживаемом оборудовании.

Более подробную информацию см. в спецификации DBSC .