Вопрос или проблема
Я проводлю аудит веб-приложения, которое предоставляет доступ к финансовому бэкенду. Веб-приложение предоставляет фронтенд в HTTPS-сессии, должным образом зашифрованной, и после аутентификации клиента в системе оно отправляет симметричный ключ, который будет использоваться для дальнейшей коммуникации (между клиентом и сервером), в виде запроса GET обратно на сервер, помещая информацию о ключе в заголовок HTTP. Симметричный ключ используется для обработки другой части обмена трафиком вне веб-фронтенда.
Я знаю, что HTTPS шифрует всё, включая заголовок HTTP, но безопасно ли полагаться только на HTTPS для обмена симметричным ключом для постшифрования? Это хорошая практика? Необходимо ли шифровать значение ключа, прежде чем отправлять его как значение в заголовке HTTP, даже если вы уже имеете установленное безопасное соединение (HTTPS)?
Обмен секретами — включая ключи — по TLS является допустимым и безопасным (если, конечно, соединение TLS безопасно). Однако схема обмена ключами, которую вы описываете, не полагается только на TLS. Для взаимной аутентификации по TLS и сервер, и клиент должны иметь сертификаты X.509. Но вы написали, что клиент аутентифицирован «внутри системы», например, с помощью пароля. Это делает схему гораздо слабее, чем TLS, так как она фактически полагается на безопасность нескольких компонентов:
- Пароль, выбранный пользователем, если используется аутентификация на основе пароля
- Система аутентификации веб-приложения (например, все пароли должны быть безопасно хешированы)
- Защищено ли веб-приложение от распространённых атак, таких как межсайтовый скриптинг
- Система управления сеансами, если пользователи также могут получить обменянный ключ во время сеанса, а не только непосредственно предоставив свой пароль
- Соединение TLS
- … и возможно больше
Любая уязвимость в любом из этих компонентов может скомпрометировать обмен ключами. Например, если веб-приложение уязвимо для атак XSS, злоумышленник может отобразить поддельную форму входа, получить пароль от пользователя и затем получить ключ, предоставив пароль приложению. Более сложные атаки, которые позволяют злоумышленнику считать заголовок ключа с помощью JavaScript (например, через Service Workers), также могут быть возможны.
Таким образом, есть много других рисков помимо уязвимостей, связанных с TLS. Приемлемость этих рисков зависит от конкретных требований безопасности, удобства и технических требований.
HTTPS/TLS шифрует трафик только до узла завершения TLS на стороне сервера. Вот два возможных случая.
-
Узел завершения — само приложение. Это происходит сейчас очень редко. В этом случае обмен дополнительным симметричным ключом безопасен, но дополнительное шифрование с использованием этого ключа не предоставляет никаких дополнительных криптографических преимуществ, если предположить, что сервер расшифровывает трафик перед его обработкой.
-
Узел завершения — это не само приложение, а какой-то обратный прокси, который пересылает трафик на приложение. В этом случае данные будут расшифрованы в узле завершения TLS, а затем (вероятно, зашифрованные с использованием другого соединения TLS) отправлены в приложение. Таким образом, по крайней мере, узел завершения TLS видит открытые данные. И если между узлом завершения TLS и приложением не используется TLS, также и другие стороны в сети могут читать расшифрованный трафик. Даже если сервер приложения использует дополнительный ключ, узел завершения видит этот ключ и все равно может расшифровать трафик и получить открытые данные.
В обоих случаях добавление ещё одного уровня симметричного шифрования не делает шифрование более сильным.
В случае, если узел завершения TLS не является самими приложением, и если узел завершения TLS не доверен, можно использовать другой подход. Приложение предоставляет свой открытый ключ через какой-то открытый канал. Для симметричного шифрования клиент использует его для инициирования обмена ключами для сквозного шифрования.
Ответ или решение
Безопасен ли обмен симметричным ключом по HTTPS?
При проведении аудита веб-приложения, предоставляющего доступ к финансовому backend, одним из ключевых вопросов является безопасность обмена симметричным ключом в сеансе HTTPS. Важно тщательно рассмотреть различные аспекты данной ситуации.
1. Основы протокола HTTPS
Протокол HTTPS (HTTP Secure) использует TLS (Transport Layer Security) для шифрования данных, передаваемых между клиентом и сервером. Это означает, что все данные, включая заголовки HTTP, передаваемые по защищенному соединению, шифруются, что теоретически минимизирует возможность перехвата или модификации информации злоумышленниками.
2. Установка симметричного ключа
Ваша схема предполагает, что после аутентификации клиент отправляет симметричный ключ через GET-запрос, помещая ключ в заголовок HTTP. На первый взгляд, это кажется безопасным, учитывая, что используется HTTPS, однако возникают важные моменты, которые необходимо учесть.
3. Сложности безопасности
Несмотря на использование HTTPS, полагаться исключительно на него для передачи симметричного ключа не является лучшей практикой по следующим причинам:
-
Аутентификация: Вы упомянули, что клиент аутентифицируется внутри системы, например, через пароль. Это создает проблемы, так как безопасность данной схемы будет зависеть от надежности паролей и механизма аутентификации. Если система уязвима для атак, таких как XSS (межсайтовый скриптинг), злоумышленники могут получить доступ к ключу.
-
Точка завершения TLS: Опасность также заключается в том, где завершается TLS. Если TLS завершается на прокси-сервере, который не защищен, то передаваемые данные могут быть расшифрованы и доступны другим узлам в сети. В этом сценарии добавление симметричного шифрования не увеличит уровень безопасности, так как сама точка завершения TLS будет видеть чистые данные.
4. Рекомендации по улучшению безопасности
Для повышения уровня безопасности при обмене симметричным ключом можно рассмотреть следующие подходы:
-
Дополнительное шифрование: Несмотря на то, что использование дополнительного шифрования может показаться избыточным при уже установленном HTTPS, это может повысить безопасность, если конечной точкой является ненадежный прокси. Использование опубликованного открытого ключа приложения для шифрования симметричного ключа перед его передачей может предотвратить его перехват.
-
Согласование безопасного канала: Рассмотрите возможность использования протоколов, предлагающих более высокий уровень защиты для обмена ключами, таких как диффи-Хеллман. Это обеспечит более надежное согласование ключей, даже если приложение оконечное не полностью защищено.
5. Вывод
Таким образом, хотя HTTPS обеспечивает шифрование канала, передача симметричного ключа через него без дополнительных мер предосторожности — не лучший вариант. Процесс обмена ключами зависит не только от надежности HTTPS, но также от других факторов, таких как уровень аутентификации, уязвимости приложения и используемая архитектура сети. Рекомендуется внедрять дополнительные меры безопасности для защиты критически важной информации, такой как симметричные ключи, чтобы минимизировать риски и повысить защиту данных.