Открываем серию статей о топ-10 OWASP. Категорию «А04:2021 – Небезопасный дизайн» проект ввел в 2021 году.
В статье рассказываем, что же такое небезопасный дизайн, какие рекомендации дает OWASP
во избежание этой уязвимости.
Разница между безопасным и небезопасным дизайном
Сама категория достаточно широка. В нее входят такие недостатки, как неэффективность управления или его полное отсутствие, недостаточное определение бизнес-логики. Одним
из ключевых факторов, увеличивающих небезопасность дизайна, является невозможность определения правильного уровня защиты из-за отсутствия профилирования бизнес – рисков.
Часто небезопасный дизайн путают с небезопасной реализацией, что не является верным суждением. Ведь проблемы с реализацией могут быть и у безопасного, с точки зрения дизайна, приложения. Это несет риски атаки злоумышленников.
Безопасный дизайн – совокупность культуры и методологии, оценивающих угрозы
и гарантирующих безопасность кода перед известными способами атаки с применением моделирования угроз. При разработке пользовательской части в таком дизайне учтена степень отклонения от заданных норм безопасности, условий поведения пользователя.
1. Восстановление учетной записи путем подтверждения личности через вопросы и ответы. Этот метод не используется, ведь ответы могут быть известны не только одному человеку.
2. Бронирование групповых билетов без внесения предоплаты. Такая возможность может быть использована злоумышленниками для выкупа мест во всей сети. Это приведет
к финансовым проблемам.
3. Отсутствие защиты от ботов на электронной торговой площадке. С помощью таких ботов злоумышленники могут скупать дорогостоящее оборудование и перепродавать
на аукционах, что скажется на репутации компании.
Что делать во избежание небезопасного дизайна
Проект OWASP, с точки зрения бизнеса, рекомендует не экономить на безопасности:
- согласовать требования к приложению, в том числе по защите конфиденциальности;
- определить разграничения доступа;
- спланировать бюджет на все этапы создания продукта, включая обеспечение безопасности.
Если говорить о безопасности с технической точки зрения, то рекомендации выглядят так:
· Установите и используйте утилиты безопасной разработки. С этим вопросом помогут специалисты по кибербезопасности.
· Применяйте собственную библиотеку безопасных шаблонов или сторонних,
но проверенных компонентов.
· Используйте моделирование угроз, в том числе для аутентификации, контроля доступа
и бизнес-логики.
· Включайте элементы управления безопасностью в пользовательские истории.
· Проверяйте каждый уровень вашего приложения: от фронт- до бэкенда.
· Проведите модульные и интеграционные тесты для проверки устойчивости к атакам.
· Разделите уровни Tier в зависимости от требований к защите.
· Разделяйте права доступа на всех уровнях приложения.
· Разграничьте потребление ресурсов пользователем или сервисом.
Ещё одной важной рекомендацией является обеспечение жизненного цикла безопасной разработки. Здесь не обойтись без специалистов по кибербезопасности. Также можно рассмотреть внедрение методологии DevSecOps, что позволит интегрировать задачи безопасности в разработку приложения. Точки риска необходимо отслеживать на всех этапах создания продукта.
OWASP Software Assurance (SAMM)
Также OWASP рекомендуют попробовать OWASP Software Assurance (SAMM).
Это методология, которая помогает построить цикл разработки безопасного приложения. С ней вы узнаете свой текущий уровень разработки и выстроите поэтапный перечень дальнейших действий, сможете оценить эффективность вносимых изменений. Некоторые специалисты сравнивают OWASP SAMM с учебником или пошаговой инструкцией.
Несомненный плюс OWASP SAMM – возможность использовать опыт мировых практик по защите приложений, что сэкономит время и даст новые точки роста в организации системы защиты.
