Cookie живут на клиенте — незащищённые, они становятся самым слабым звеном сессии.
Веб-приложения переносят состояние сессии, пользовательские предпочтения, контекст транзакций и иногда подсказки авторизации внутри cookie. Проблема проста: cookie хранятся на клиенте, видны в инструментах разработчика браузера, копируемы и редактируемы. Когда значение является открытым текстом или предсказуемым форматом, cookie — это не просто носитель для атакующего, а управляемая поверхность контроля.
Традиционный подход пытается решить это внутри кода приложения. Каждый разработчик подписывает, шифрует, проверяет и обрабатывает ошибки для каждого критического cookie. Однако в крупных организациях приложения охватывают разные команды, разные технологические стеки и кодовые базы разного возраста. Ретроактивное применение одинаковой дисциплины безопасности ко всем приложениям нецелесообразно.
Флаги безопасности также недостаточны. Настройки Secure, HttpOnly и SameSite управляют тем, как cookie передаётся и в каком контексте он доступен, но сами по себе не предотвращают чтение или значимое изменение значения cookie на стороне клиента. Если значение не защищено, безопасность транспорта и безопасность содержимого смешаны.
Правильная модель — сделать критические значения cookie бессмысленными на клиенте, сохраняя поведение приложения на стороне бэкенда нетронутым. Правило должно уметь выбирать, какие cookie защищены по имени, и прозрачно шифровать на пути ответа и расшифровывать на пути запроса.
TR7 Cookie Encryption Rule устраняет этот пробел: без изменений кода бэкенда оно делает выбранные значения cookie нечитаемыми и устойчивыми к подделке для клиента.
Наш подход
TR7 рассматривает шифрование cookie как централизованную политику трафика и безопасности — а не функцию, зарытую в коде приложения.
Значения cookie защищены от клиента с помощью AES-256
Поле value выбранных cookie шифруется на пути ответа; клиент получает только шифрованный текст. На пути запроса значение расшифровывается, и бэкенд получает cookie в ожидаемом формате.
Выбор шифруемых cookie осуществляется по именному списку
Вместо слепой обработки всех cookie оператор явно перечисляет имена cookie для защиты. Под политику попадают только cookie, несущие сессионный, авторизационный или конфиденциальный бизнес-контекст.
Работает без каких-либо изменений кода бэкенда
Шифрование и расшифровка выполняются полностью на уровне TR7. Бэкенд видит cookie в ожидаемом формате; реальное значение скрыто от клиентской стороны.
Подделанные cookie безопасно исключаются из сессионного потока
Если клиент повреждает или заменяет зашифрованное значение, поток расшифровки и проверки не удаётся. Попытки подделки cookie поэтому не пересылаются бэкенду как допустимые сессионные данные.
Возможности
Cookie Encryption Rule укрепляет конфиденциальность и целостность выбранных cookie на стороне клиента через централизованную политику ADC/WAAP.
Шифрование AES-256 скрывает значение cookie от клиента
TR7 шифрует поле value выбранных cookie с AES-256, делая их нечитаемыми на стороне клиента. Браузер, инструмент безопасности или конечный пользователь видят только шифрованный текст. Это снижает риск утечки идентификаторов сессий или контекста приложения в открытом тексте. Поскольку шифрование применяется на edge-уровне, разработчикам приложений не нужно писать отдельный код шифрования для каждого cookie.
Подписанные cookie — подделка отклоняется, а не обнаруживается потом
Cookie, которому доверяет приложение, подписывается на выходе и проверяется на возврате. Измените в нём один символ — и запрос будет отклонён ещё до того, как приложение его увидит, а попытка попадёт в журнал вместе с остальной частью запроса. Подпись выбрана вместо шифрования намеренно: здесь нужна целостность, а не секретность, и подписанный cookie остаётся читаемым — инженер, разбирающий сессию, по-прежнему видит его содержимое. Какие cookie защищать — список, который ведёте вы, а ключ можно ротировать, не обесценивая то, что уже в пути.
Прозрачная трансформация cookie на путях запроса и ответа
На пути ответа выбранные cookie от бэкенда шифруются перед отправкой клиенту. На пути запроса зашифрованные cookie, возвращённые клиентом, расшифровываются и пересылаются бэкенду с ожидаемым значением открытого текста. Эта двунаправленная модель защищает значение на стороне клиента без изменения поведения приложения. Пользовательский опыт остаётся неизменным, пока контроль над содержимым cookie централизован в TR7.
Именной список cookie ограничивает защиту только критическими значениями
Оператор определяет, какие cookie шифруются, перечисляя их имена. Выбираются cookie, несущие состояние сессии, пользовательский контекст, статус транзакций или конфиденциальные данные приложения; обычные cookie предпочтений могут быть исключены. Эта контролируемая область снижает ненужные затраты на обработку и делает поведение политики предсказуемым. Разные vService или пулы могут иметь разные списки cookie.
Идемпотентное применение на пул предотвращает ошибки двойного шифрования
Правило разработано для применения один раз на пул. Это предотвращает операционные ошибки, такие как многократное шифрование одного и того же значения cookie при прохождении через цепочку правил. Это также обеспечивает детерминированное поведение в архитектурах, где активны несколько правил или уровней. Команды операций имеют более чёткое представление о том, какая политика cookie применяется к какому пулу.
Попытки подделки cookie не достигают бэкенда как чистые сессионные данные
Если клиент модифицирует зашифрованное значение cookie, расшифровка не даёт ожидаемого результата. В этом случае cookie не пересылается бэкенду как допустимое, доверенное сессионное значение. Это значительно затрудняет для атакующего манипуляцию поведением приложения путём ручного изменения полей роли, тенанта, сессии или контекста транзакции. Политика обеспечивает целостность cookie на edge-уровне без передачи этой ответственности коду приложения.
Одна и та же модель защиты работает в сценариях ADC и WAAP
Cookie Encryption Rule вписывается в случаи использования как доставки приложений, так и защиты веб-приложений и API. В режиме ADC трансформация cookie выполняется без нарушения потока трафика; в режиме WAAP она может оцениваться совместно с контролями безопасности сессий и запросов. Эта общая модель убирает безопасность cookie из области отдельных продуктов или отдельного кода. Политика определяется централизованно в TR7 и последовательно применяется перед соответствующими сервисами.
Legacy-сервисы защищены без ожидания модернизации приложений
В legacy-приложениях добавление безопасности cookie обычно требует изменений кода, тестовых циклов и релиза. TR7 снижает эту нагрузку, защищая значения cookie вне приложения. Поскольку бэкенд продолжает получать cookie в ожидаемом формате, серьёзных переработок не требуется. Это обеспечивает практический прирост безопасности — особенно в таких средах, как финансовые услуги, здравоохранение и государственные структуры, где стоимость изменений высока.
Операционная глубина
Правило шифрования cookie работает с учётом управления ключами, поведения при ошибках, видимости аудита, высокой доступности и совместимости приложений.
Управление ключами
Безопасность политики шифрования зависит от защиты используемых ключей. Ключи должны управляться в TR7 централизованно, контролируемым образом с доступом, ограниченным авторизованным персоналом. Планирование ротации ключей должно учитывать активные сессии, поэтапный переход и сценарии отката.
Соответствие высокой доступности
В развёртываниях с несколькими узлами TR7 одинаковые политика и ключевой материал должны быть согласованы по всем узлам. В противном случае cookie, зашифрованный одним узлом, может быть нерасшифруемым другим. Шифрование cookie должно поэтому планироваться совместно с конфигурацией кластера и синхронизацией конфигурации.
Поведение при ошибках и fallback
Поведение системы при повреждённом, отсутствующем или нерасшифруемом cookie должно быть определено на уровне политики. Для критических сессионных cookie безопасный выбор — отклонить запрос или принудительно переустановить сессию. Для cookie с меньшим риском в зависимости от потребностей приложения может быть предпочтительным удаление cookie или переход к потоку по умолчанию.
Аудит и видимость
Какие имена cookie защищены на каком vService, должно быть операционно наблюдаемым. Ошибки расшифровки, повреждённые значения и совпадения политик — ценные сигналы для проверок безопасности. В SIEM-интеграции эти события могут коррелироваться с контролями защиты сессий и предотвращения утечки данных.
Совместимость приложений
Некоторые приложения пытаются читать значения cookie через клиентские скрипты. Шифрование таких cookie может нарушить клиентскую логику. Поэтому политику следует сначала применять к cookie, потребляемым на стороне сервера; cookie, которые должны быть читаемы клиентским кодом, необходимо оценивать отдельно.
Контроль области политики
Шифрование cookie не следует рассматривать как грубую настройку, автоматически применяемую ко всем cookie. Правильная область определяется путём совместного анализа имени cookie, vService, пула и поведения приложения. Этот подход максимизирует влияние на безопасность, минимизируя ненужные проблемы совместимости.
Когда это использовать
Защита cookie, несущих идентификаторы сессий
Финансовые и медицинские приложения могут сделать cookie с идентификаторами сессий нечитаемыми на стороне клиента. Код бэкенда продолжает работать без изменений, пока снижается риск утечки cookie и ручной подстановки значений.
Остановка попыток подделки cookie на edge
Команды безопасности могут контролировать модификацию cookie, несущих роль пользователя или контекст транзакции, на уровне TR7. Повреждённые значения не пересылаются бэкенду как допустимые сессионные данные.
Быстрые выигрыши безопасности для legacy-корпоративных приложений
Шифрование cookie может быть активировано для трудно изменяемых legacy-приложений без изменений кода приложения. Организация снижает видимость cookie на стороне клиента без прохождения долгого цикла модернизации.
Скрытие конфиденциального контекста приложения от клиента
Cookie с конфиденциальным контекстом, таким как тенант, роль или статус транзакции, не раскрываются как значимые данные на клиенте. Это значительно затрудняет для атакующего извлечение логики приложения из содержимого cookie и проведение зондирующих атак.
Часто задаваемые вопросы
Какой алгоритм шифрования использует правило шифрования cookie?
Все ли cookie шифруются, или можно выбрать конкретные?
Нужно ли менять код бэкенда?
Что происходит, если клиент изменяет зашифрованное значение cookie?
Как обеспечивается согласованность шифрования на нескольких узлах TR7?
Можно ли шифровать cookie, читаемые клиентскими скриптами?
Перенесите безопасность cookie на edge-уровень
Шифрование AES-256, именной выбор cookie и ноль изменений кода бэкенда. Давайте разберём живую настройку на ваших собственных сервисах.