Сервис расшифровывает данные, полученные от клиента, но не проверяет их целостность. Какой механизм атаки становится возможным?
Становится возможной атака модификации шифротекста: злоумышленник может изменить зашифрованные данные так, чтобы после расшифровки результат отличался от исходного. Для защиты нужна проверка подлинности шифротекста — например, режим аутентифицированного шифрования AEAD, который проверяет тег до использования расшифрованных данных.
Ранние схемы шифрования часто решали только задачу конфиденциальности: без ключа нельзя прочитать сообщение. Однако конфиденциальность сама по себе не гарантирует, что сообщение не было изменено по дороге.
Практическая потребность одновременно защищать содержимое и подтверждать его целостность привела к использованию MAC вместе с шифрованием и к режимам AEAD. Эти подходы формализуют две разные гарантии: данные скрыты и данные не были незаметно подменены.
Если сервис доверяет результату расшифровки без проверки целостности, атакующий может менять шифротекст, не зная ключа. В зависимости от алгоритма и формата данных это может привести к изменению отдельных полей, повреждению структуры или управляемому влиянию на расшифрованный результат.
Особенно опасно, если расшифрованные данные затем используются как права доступа, идентификатор операции, сумма платежа или команда. Дополнительный риск возникает, когда сервис сообщает разные ошибки для неверного тега, padding и формата: такие различия могут превратить его в оракул расшифровки.
Шифротекст должен сопровождаться проверяемым тегом аутентичности. Сервис сначала проверяет тег с использованием секретного ключа и только при успешной проверке принимает расшифрованные данные; при ошибке нужно отклонить весь контейнер.
Предпочтительный вариант — AEAD, например AES-GCM или ChaCha20-Poly1305. Такой режим защищает шифротекст от незаметной модификации и позволяет включить в проверку открытые, но неизменяемые метаданные — associated data, например версию формата или идентификатор контекста.
Для AEAD критична уникальность nonce для каждого шифрования с одним ключом. Повторное использование nonce, особенно в некоторых режимах, может разрушить гарантии конфиденциальности и целостности. Поэтому nonce обычно хранят вместе с шифротекстом, но генерируют или распределяют так, чтобы повторения не происходили.
Альтернатива — отдельный MAC с корректным порядком операций, обычно «сначала шифрование, затем вычисление MAC». Нельзя подменять проверку целостности простым хешем: открытый хеш не доказывает, что данные создал обладатель секретного ключа.
Проверка должна выполняться до разбора критичных полей и до передачи данных в бизнес-логику. Ошибки проверки не должны раскрывать, какая именно часть контейнера оказалась неверной; это уменьшает риск использования сервиса как оракула, хотя не заменяет правильную криптографическую схему.
Сервис хранил в cookie зашифрованный объект с идентификатором пользователя и сроком действия. Шифрование скрывало поля, но схема не включала тег целостности. Команда рассматривала три варианта: оставить схему как есть, добавить открытый хеш или перейти на AEAD.
Сохранение схемы не устраняло подмену. Открытый хеш также не решал проблему: атакующий мог пересчитать его после изменения cookie. Выбран был AEAD с уникальным nonce, проверкой тега до разбора объекта и немедленным отклонением контейнера при ошибке.
Дополнительно старые cookie сделали несовместимыми с новым форматом и ограничили срок их действия. В результате перехватчик мог увидеть или удалить cookie, но не мог незаметно изменить её содержимое так, чтобы сервис принял подделанные данные.
Нет. Проверка формата обнаруживает только часть повреждений и не подтверждает происхождение данных. Злоумышленник может изменить значение так, чтобы оно осталось синтаксически корректным, например заменить одно допустимое поле другим. Нужна криптографическая проверка целостности, основанная на секретном ключе.
Так делать нельзя, если промежуточный открытый текст уже влияет на логику, ошибки, обращения к базе или внешние запросы. Даже если окончательный результат будет отклонён, обработка может создать побочный эффект или раскрыть информацию. Безопасная граница — проверить тег и только затем передать открытый текст в бизнес-логику.
Нет. AEAD подтверждает целостность и подлинность конкретного контейнера, но не гарантирует его свежесть. Для защиты от replay нужны отдельные данные протокола: одноразовый идентификатор, счётчик, допустимое время действия или серверное хранение уже использованных идентификаторов. Эти значения также следует связывать с аутентифицированными данными.