A04:2025 Криптографические сбои

Общие сведения.

Опустившись на две позиции на 4-е место, эта категория охватывает сбои, связанные с отсутствием криптографии, использованием недостаточно стойкой криптографии, утечкой криптографических ключей и сопутствующими ошибками. Три наиболее распространённых CWE в этой категории рисков связаны с использованием слабого генератора псевдослучайных чисел: CWE-327 Использование ненадёжного или опасного криптографического алгоритма, CWE-331: Недостаточная энтропия, CWE-1241: Использование предсказуемого алгоритма в генераторе случайных чисел и CWE-338 Использование криптографически слабого генератора псевдослучайных чисел (PRNG).

Таблица оценок.

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
32	13,77%	3,80%	100,00%	47,74%	7,23	3,90	1 665 348	2 185

Описание.

В целом все данные при передаче должны шифроваться на транспортном уровне (уровень OSI 4). Прежние препятствия, такие как производительность процессора и управление закрытыми ключами и сертификатами, теперь решены благодаря аппаратным инструкциям процессора для ускорения шифрования (например, поддержка AES) и упрощению управления ключами и сертификатами посредством таких сервисов, как LetsEncrypt.org, а крупные облачные провайдеры обеспечивают ещё более тесно интегрированные сервисы управления сертификатами.

Помимо защиты транспортного уровня, важно определить, какие данные требуют шифрования в состоянии покоя, а какие — дополнительного шифрования при передаче (на прикладном уровне, уровень OSI 7). Например, пароли, номера кредитных карт, медицинские записи, персональные данные и коммерческие тайны требуют дополнительной защиты, особенно если эти данные подпадают под законодательство о конфиденциальности, например GDPR ЕС, или нормативные требования, такие как PCI DSS. Для всех таких данных проверьте:

Используются ли старые или слабые криптографические алгоритмы или протоколы — по умолчанию или в старом коде?
Используются ли стандартные криптографические ключи, генерируются ли слабые ключи, повторно ли используются ключи, или отсутствует надлежащее управление ключами и их ротация?
Зафиксированы ли криптографические ключи в репозиториях исходного кода?
Не принудительно ли применяется шифрование, например отсутствуют ли директивы или заголовки безопасности HTTP (браузера)?
Корректно ли проверяются полученный сертификат сервера и цепочка доверия?
Игнорируются ли инициализирующие векторы, используются ли они повторно или недостаточно безопасно для данного режима криптографической операции? Используется ли небезопасный режим, например ECB? Используется ли шифрование там, где более уместно аутентифицированное шифрование?
Используются ли пароли в качестве криптографических ключей без функции выработки ключа на основе пароля?
Используется ли случайность, не предназначенная для криптографических требований? Даже если выбрана правильная функция — нужно ли её инициализировать разработчику, и если нет, не перезаписал ли разработчик встроенную функцию сильной инициализации?
Используются ли устаревшие хеш-функции, такие как MD5 или SHA1, или некриптографические хеш-функции там, где нужны криптографические?
Могут ли криптографические сообщения об ошибках или информация по боковым каналам быть использованы в атаках, например атаках на основе оракула дополнения?
Может ли криптографический алгоритм быть понижен или обойдён?

См. ссылки ASVS: Cryptography (V11), Secure Communication (V12) и Data Protection (V14).

Как предотвратить.

Выполните как минимум следующее и обратитесь к ссылкам:

Классифицируйте и маркируйте данные, обрабатываемые, хранимые или передаваемые приложением. Определите, какие данные являются конфиденциальными согласно законодательству о конфиденциальности, нормативным требованиям или бизнес-потребностям.
Храните наиболее чувствительные ключи в аппаратном или облачном HSM.
Используйте проверенные реализации криптографических алгоритмов везде, где это возможно.
Не храните конфиденциальные данные без необходимости. Уничтожайте их как можно скорее или используйте совместимую с PCI DSS токенизацию или усечение. Данные, которые не хранятся, не могут быть похищены.
Обязательно шифруйте все конфиденциальные данные в состоянии покоя.
Используйте актуальные и стойкие стандартные алгоритмы, протоколы и ключи; применяйте надлежащее управление ключами.
Шифруйте все данные при передаче только с протоколами >= TLS 1.2, с шифрами с прямой секретностью (FS), откажитесь от шифров CBC, поддерживайте алгоритмы постквантового обмена ключами. Для HTTPS принудительно применяйте шифрование с помощью HTTP Strict Transport Security (HSTS). Проверяйте всё инструментом.
Отключите кэширование ответов, содержащих конфиденциальные данные, включая кэширование в CDN, веб-сервере и любом прикладном кэше (например, Redis).
Применяйте необходимые меры контроля безопасности в соответствии с классификацией данных.
Не используйте незашифрованные протоколы, такие как FTP и STARTTLS. Избегайте использования SMTP для передачи конфиденциальных данных.
Храните пароли с использованием стойких адаптивных хеш-функций с солью и рабочим коэффициентом, таких как Argon2, yescrypt, scrypt или PBKDF2-HMAC-SHA-512. Для устаревших систем на bcrypt обратитесь к OWASP Cheat Sheet: Password Storage.
Инициализирующие векторы должны выбираться в соответствии с режимом операции. Это может потребовать использования CSPRNG (криптографически стойкого генератора псевдослучайных чисел). Для режимов с nonce IV не требует CSPRNG. В любом случае IV никогда не должен использоваться дважды для фиксированного ключа.
Всегда используйте аутентифицированное шифрование вместо простого шифрования.
Ключи должны генерироваться криптографически случайно и храниться в памяти в виде байтовых массивов. Если используется пароль, он должен быть преобразован в ключ с помощью соответствующей функции выработки ключа на основе пароля.
Убедитесь, что там, где это необходимо, используется криптографическая случайность, и что она не была инициализирована предсказуемым образом или с недостаточной энтропией. Большинство современных API не требуют, чтобы разработчик инициализировал CSPRNG.
Избегайте устаревших криптографических функций, методов блочного построения и схем дополнения, таких как MD5, SHA1, Cipher Block Chaining Mode (CBC), PKCS #1 v1.5.
Проверяйте настройки и конфигурации на соответствие требованиям безопасности с привлечением специалистов, специализированных инструментов или и того, и другого.
Необходимо уже сейчас готовиться к постквантовой криптографии (PQC), см. ссылку (ENISA), чтобы системы высокого риска были защищены не позднее конца 2030 года.

Примеры сценариев атак.

Сценарий №1: Сайт не использует или не принудительно применяет TLS для всех страниц или поддерживает слабое шифрование. Злоумышленник перехватывает сетевой трафик (например, в незащищённой беспроводной сети), понижает соединения с HTTPS до HTTP, перехватывает запросы и похищает сессионный cookie пользователя. Затем злоумышленник воспроизводит этот cookie и захватывает (аутентифицированную) сессию пользователя, получая доступ к личным данным или изменяя их. Альтернативно злоумышленник может изменить все передаваемые данные, например получателя денежного перевода.

Сценарий №2: База данных паролей хранит пароли в виде несолёных или простых хешей. Уязвимость загрузки файлов позволяет злоумышленнику получить базу данных паролей. Все несолёные хеши могут быть раскрыты с помощью таблицы хешей заранее вычисленных значений. Хеши, сгенерированные простыми или быстрыми хеш-функциями, могут быть взломаны с помощью GPU, даже если они были солёными.