A06:2025 Небезопасное проектирование

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

Небезопасное проектирование сместилось на две позиции — с 4-го на 6-е место — в связи с тем, что A02:2025-Небезопасная конфигурация и A03:2025-Уязвимости цепочки поставок ПО вышли на более высокие позиции. Категория введена в 2021 году, и с тех пор мы наблюдаем заметное улучшение в отрасли в части моделирования угроз и акцента на безопасном проектировании. Категория охватывает риски, связанные с дефектами проектирования и архитектуры, с призывом к более широкому использованию моделирования угроз, паттернов безопасного проектирования и эталонных архитектур. Сюда входят дефекты бизнес-логики приложения, например отсутствие определения нежелательных или неожиданных изменений состояния внутри приложения. Как сообщество нам необходимо выйти за рамки «сдвига влево» в области кодирования к действиям до написания кода — разработке требований и проектированию приложений, которые критически важны для принципов «безопасность по умолчанию» (см. Создание современной программы AppSec: фаза планирования и проектирования). Среди значимых CWE: CWE-256: Незащищённое хранение учётных данных, CWE-269 Неправильное управление привилегиями, CWE-434 Неограниченная загрузка файлов опасного типа, CWE-501: Нарушение границы доверия и CWE-522: Недостаточно защищённые учётные данные.

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

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
39	22,18%	1,86%	88,76%	35,18%	6,96	4,05	729 882	7 647

Описание.

Небезопасное проектирование — широкая категория, представляющая различные уязвимости, выраженные как «отсутствие или неэффективный дизайн средств контроля». Небезопасное проектирование — не источник всех других категорий рисков Top Ten. Важно различать небезопасное проектирование и небезопасную реализацию. Мы разграничиваем дефекты проектирования и дефекты реализации намеренно: у них разные первопричины, они проявляются на разных этапах разработки и требуют разных методов устранения. Безопасный дизайн всё же может содержать дефекты реализации, ведущие к уязвимостям. Небезопасный дизайн невозможно исправить идеальной реализацией, поскольку необходимые средства контроля безопасности изначально не были созданы для защиты от конкретных атак. Один из факторов небезопасного проектирования — отсутствие профилирования бизнес-рисков при разработке программного обеспечения или системы и, следовательно, неопределённость требуемого уровня защиты.

Три ключевых составляющих безопасного проектирования:

Сбор требований и управление ресурсами
Создание безопасного дизайна
Наличие безопасного жизненного цикла разработки

Сбор требований и управление ресурсами

Согласуйте с бизнесом функциональные требования к приложению, включая требования к защите конфиденциальности, целостности, доступности и подлинности всех активов данных и ожидаемую бизнес-логику. Учитывайте открытость приложения и необходимость разделения арендаторов. Составьте технические требования, включая функциональные и нефункциональные требования безопасности. Спланируйте и согласуйте бюджет на проектирование, разработку, тестирование и эксплуатацию, включая мероприятия по безопасности.

Безопасный дизайн

Безопасный дизайн — это культура и методология, постоянно оценивающая угрозы и обеспечивающая надёжное проектирование и тестирование кода для защиты от известных методов атак. Моделирование угроз должно быть интегрировано в сессии уточнения (или аналогичные мероприятия); отслеживайте изменения в потоках данных и контроле доступа или других средствах безопасности. При разработке пользовательских историй определяйте правильные потоки и состояния сбоев, убедитесь, что они хорошо поняты и согласованы со всеми ответственными и затронутыми сторонами. Анализируйте допущения и условия для ожидаемых потоков и потоков сбоев. Безопасный дизайн — это не надстройка и не инструмент, который можно добавить к программному обеспечению.

Безопасный жизненный цикл разработки

Безопасное программное обеспечение требует безопасного жизненного цикла разработки, паттернов безопасного проектирования, методологии «проторенных дорожек», библиотеки безопасных компонентов, соответствующих инструментов, моделирования угроз и анализа после инцидентов. Обращайтесь к специалистам по безопасности в начале проекта, на протяжении всего проекта и при текущем обслуживании программного обеспечения. Рассмотрите использование OWASP SAMM для структурирования усилий по безопасной разработке.

Самоответственность разработчиков нередко недооценивается. Формируйте культуру осведомлённости, ответственности и проактивного снижения рисков. Регулярное обсуждение вопросов безопасности (например, на сессиях моделирования угроз) формирует образ мышления, включающего безопасность во все важные решения по проектированию.

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

Создайте и используйте безопасный жизненный цикл разработки с привлечением специалистов AppSec для оценки и проектирования средств контроля безопасности и конфиденциальности.
Создайте и используйте библиотеку паттернов безопасного проектирования или компонентов «проторенных дорожек».
Используйте моделирование угроз для критически важных частей приложения: аутентификации, контроля доступа, бизнес-логики и ключевых потоков.
Используйте моделирование угроз как образовательный инструмент для формирования мышления о безопасности.
Интегрируйте язык и средства контроля безопасности в пользовательские истории.
Интегрируйте проверки правдоподобности на каждом уровне приложения (от фронтенда до бэкенда).
Пишите модульные и интеграционные тесты для проверки устойчивости всех критических потоков к модели угроз. Составляйте варианты использования и злоупотребления для каждого уровня приложения.
Разделяйте уровни на системном и сетевом уровнях в зависимости от открытости и потребностей в защите.
Надёжно разделяйте арендаторов по всем уровням.

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

Сценарий №1: Процесс восстановления учётных данных может включать «вопросы и ответы», что запрещено NIST 800-63b, OWASP ASVS и OWASP Top 10. Вопросы и ответы не могут служить доказательством личности, поскольку ответы может знать более одного человека. Такая функциональность должна быть удалена и заменена более безопасным решением.

Сценарий №2: Сеть кинотеатров предлагает скидки на групповые бронирования с максимальным числом 15 участников до внесения депозита. Злоумышленники могут смоделировать этот поток и проверить, можно ли найти вектор атаки в бизнес-логике приложения, например забронировав 600 мест и все кинотеатры одновременно в нескольких запросах, что приведёт к огромным потерям дохода.

Сценарий №3: Интернет-магазин розничной сети не защищён от ботов, используемых перекупщиками для скупки видеокарт высокого класса с целью перепродажи на аукционах. Тщательный дизайн антибот-системы и правила бизнес-логики (например, покупки в течение нескольких секунд после появления товара) могли бы помочь выявить неподлинные покупки и отклонить такие транзакции.