Мы возвращаемся к серии статей про рейтинг топ 10 OWASP 2021. Сегодня рассказываем про криптографический сбой A02:2021.
В предыдущем рейтинге уязвимость занимала 3-ю строку и относилась к раскрытию конфиденциальных данных как одна из причин. Всё изменилось и этой уязвимости выделили отдельное место в рейтинге.
ОписаниеТакие данные, как номера кредитных карт, логины и пароли от веб-ресурсов и приложений, персональные данные или коммерческие данные организаций требуют особого уровня защиты. Важно следить чтобы такая информация не передавалась открыто. Поэтому при передаче данных применяются криптографические методы и хэш-функции.
При работе с криптографией могут совершаться следующие ошибки:
передача данных происходит по незащищенным протоколам HTTP, SMTP, FTP, а также использующих TLS без шифрования;
использование устаревших или слабых алгоритмов шифрования, протоколов по умолчанию;
повторное использование слабых криптографических ключей, отсутствие корректного управления ключами и их проверка;
не проверяется сертификат сервера;
игнорирование векторов инициализации или их безопасности;
применение простых паролей;
ненадежный исходный код продукта;
устаревшие хэш-функции или их полное отсутствие.
И это еще не все случаи, связанные с криптографией.
Как предотвратитьЧтобы не допустить уязвимость, необходимо:
Правильно классифицировать конфиденциальные данные, с которыми работает приложение или веб-ресурс.
Осуществлять хранение таких данных только в случае необходимости и с обязательным шифрованием.
Использовать современные способы шифрования данных.
Правильно управлять ключами.
Отключить кэширование ответов сервера, содержащих конфиденциальную информацию.
Исключить использование устаревших протоколов. Таких, как FTP и SMTP при передаче данных.
Обеспечить хранение паролей с использованием надежных и адаптивных функций хэширования.
Использовать аутентифицированное шифрование.
Генерировать ключи шифрования криптографически случайным образом и хранить в памяти в виде массивов байтов.
Если используется пароль, то он должен быть преобразован в ключ с помощью соответствующей функции .
Проверять эффективность конфигурации и настроек.
Может возникнуть такая уязвимость в банковских приложениях. Приложение автоматическеи шифрует номера кредитных карт в базе данных. Но при извлечении данные расшифровываются также автоматически, что дает «возможность» применить другую уязвимость - SQL-инъекцию. Злоумышленники могут с легкостью получить номера кредитных карт.
Если на сайте не применяется TLS для всех страниц или шифрование слабое, то это дает возможность злоумышленнику, при отслеживании сетевого трафика, снизить соединение с HTTPS на HTTP и получить файлы cookie сеанса пользователя. Затем злоумышленник перехватывает сеанс пользователя, прошедший проверку подлинности. Далее меняются данные пользователя, например, получателя денежного перевода.
Некая база данных использует несоленые (без salt) или простые хэши для хранения пользовательских паролей. Ошибка при загрузке файла позволяет злоумышленнику её. Все несоленые хэши могут быть представлены с помощью радужной таблицы. То есть хэши, созданные простыми или быстрыми хэш-функциями, можно взломать с помощью графических процессоров.
Конечно, для предотвращения этой уязвимости существует множество методов. Но главное - соблюдать базовые правила, которые мы описали в статье. И не стоит забывать, что необходимо обеспечить комплексную безопасность ваших ресурсов. Ведь устраняя одну уязвимость вы можете не заметить другую.
