Comments 4
Уязвимостями бизнес-логики можно также заниматься на этапе разработки сценариев тестирования для новых фич. Если применяется TDD (или BDD), то это делается до начала разработки. Т.е. сразу думать не только о том как проверить работоспособность фичи, но и как ее сломать (abuse) и использовать не по назначению (misuse). Сценарии можно посмотреть в соответствующем разделе WSTG.
По сути, мы этим занимаемся на уровне use-case.
На этапе разработки сценариев тестирования, AppSec должен прийти в команду и помочь составить все необходимые тест-кейсы. Или же, надо научить разработчиков/тестировщиков писать тесты на abuse или misuse. Это отдельное направление, которое частично тоже внедряется.
Внедрить более глубокое тестирование можно после внедрения моделей угроз выливающихся в список задач. Каждая задача уже будет приведена в форму тест-кейса.
Как решить проблему дыры в кармане? Зашить!
Ну не совсем так. Мы не говорим что надо "зашить карман" и не делать ту или иную функциональность, мы говорим что в карман могут полезть, поэтому сверху лучше пришить клапан, или в кармане не держать деньги.
По поводу сессий - да, такой потребности не было. Не поверите, но многие просто удаляют сессии на фронте (удаляют из куки или памяти), без инвалидации самого токена/сессии.
Про 3 кейс скажу так - различных типов доставок более 5 штук. Для каждой надо расписать базовые кейсы такие как успешная доставка, опоздание, перенос, отмена, возврат, частичный возврат, доставка частями.
В данном случае, не учли рассогласованность систем (так как есть внешние системы, которые мы никак не контролируем). Сложность систем требует повышенного внимания. А делать хочется быстрл, вот и некоторые углы срезаются.
Ну и по поводу белого хакера, а не менеджера. Архитектура - это только одна часть работы. Приложения мы так же ломаем на стейдже, так же ищем баги на проде.
Но исправить проблему на архитектуре в разы дешевле чем фиксить баг на проде.
Как решить проблему уязвимостей бизнес-логики? Поломать приложение еще до написания кода