A04: Insecure Design

Некоторые уязвимости заложены не в коде, а в самой задумке системы — и патчем их не исправить.

Insecure Design — небезопасный дизайн: дефекты, возникшие на этапе проектирования из-за отсутствия или слабости защитных механизмов в самой логике приложения.

Важно различать: дефект реализации — это правильная идея, плохо закодированная (и её можно пропатчить). Дефект дизайна — это изначально неверная идея; даже идеальный код её не спасёт.

Пример небезопасного дизайна

Форма восстановления пароля задаёт «секретный вопрос» вроде «девичья фамилия матери». Ответ часто можно найти в соцсетях — значит, сам механизм слаб независимо от качества кода. Другой пример: магазин разрешает заказать товар, а оплату проверяет только асинхронно через час — за это время можно успеть получить товар бесплатно. Логика дырявая по замыслу.

Бизнес-логика и злоупотребления

Небезопасный дизайн часто проявляется как злоупотребление бизнес-логикой: бесконечное применение промокода, отрицательное количество товара в корзине (возврат «лишних» денег), обход лимитов через гонку запросов. Код «работает как написано», но сценарий злоупотребления не предусмотрен.

Как защищаться

Проводите моделирование угроз на этапе проектирования (см. урок про модель угроз).
Закладывайте в дизайн ограничения: лимиты, проверки последовательности шагов, идемпотентность платежей.
Используйте проверенные защитные паттерны вместо самодельной логики.
Пишите «злоупотребительные» сценарии (abuse cases) рядом с обычными пользовательскими историями: «как этим можно злоупотребить?».
Закрывайте гонки (race conditions) на уровне транзакций и блокировок.

Пользовательская история: покупатель применяет промокод и получает скидку.
Abuse case: покупатель применяет один промокод многократно за счёт гонки запросов.
Мера: промокод одноразовый, проверка и списание в одной транзакции.

Частые ошибки разработчиков

Думают, что безопасность — это только «защита от хакеров», и забывают про злоупотребление честной логикой.
Пытаются «пропатчить» дизайн-дефект точечной заплаткой вместо пересмотра механизма.
Не проверяют последовательность шагов: можно ли пропустить оплату и сразу попасть на «спасибо за заказ».

Итог

Insecure Design — это дефект замысла, а не кода; патчем не лечится.
Закладывайте безопасность в архитектуру через threat modeling и abuse cases.
Особое внимание — злоупотреблениям бизнес-логикой и гонкам.