Автоматизированное сканирование безопасности процесса оформления заказа не выявило традиционных уязвимостей, таких как SQL-инъекции или межсайтовый скриптинг. Младший пентестер был готов признать, что тестирование не выявило значительных проблем, основываясь на результатах сканера. Однако член команды заметил, что конечная точка для применения промокодов не аннулировала код до подтверждения заказа. Этот недостаток дизайна означал, что одноразовый код мог быть использован несколько раз одновременно.Отправляя один и тот же запрос одновременно, одноразовый промокод на 50% скидку был использован сорок раз за несколько секунд. Этот тип уязвимости, состояние гонки, возникает из-за разрыва между проверкой действительности кода и его пометкой как использованного. Автоматизированные сканеры не могут обнаружить состояния гонки, потому что они тестируют запросы последовательно, а не одновременно. Уязвимые конечные точки часто включают шаблон "проверить, затем действовать", такой как погашение купонов или снятие средств.Для эксплуатации состояний гонки запросы должны отправляться одновременно, а не просто быстро, чтобы минимизировать сетевые помехи. Инструменты, такие как вкладка "состояние гонки" в Burp или Turbo Intruder, предназначены для этой цели. Доказательством состояния гонки является конечное состояние системы, такое как количество раз, когда код был применен, а не просто коды успешных ответов. Этот тип ошибки бизнес-логики пропускается сканерами и требует ручного исследования поведения одновременного применения. Ресурсы и лаборатории Codelivly сосредоточены на этих продвинутых уязвимостях, которые выходят за рамки возможностей автоматического сканирования.