Автоматизированное сканирование безопасности выявило критическую уязвимость удаленного выполнения кода (RCE) из-за значительной задержки ответа. Полезная нагрузка включала команду приостановить выполнение, что ошибочно указывало на внедрение команды. Было замечено, что эта задержка была непоследовательной при повторных тестах, что подчеркивает ее ненадежность в качестве доказательства уязвимости.Проблема заключалась в том, что межсетевой экран веб-приложений (WAF) требовал больше времени для обработки запросов, содержащих подозрительные символы. Это известный режим сбоя, когда задержки ошибочно интерпретируются как выполнение команды, хотя на самом деле они вызваны другими факторами, такими как проверка WAF или нагрузка на приложение. Многие автоматизированные инструменты и даже опытные специалисты по безопасности могут попасть в эту ловушку, полагаясь исключительно на временные ответы.В тексте подчеркивается лучший подход: вместо того, чтобы просто искать задержки, следует убедиться, что сервер обработал входные данные таким образом, чтобы получить уникальное, неизменяемое значение. Это включает отправку нейтрального управляющего запроса для установления базового уровня. Затем серверу предлагается вычислить что-то новое, например, сумму случайных чисел, и проверить, появляется ли эта конкретная сумма в ответе.Если прямого вывода нет, изменение времени задержки может помочь отличить истинные уязвимости от внешних факторов. DNS-обратные вызовы сами по себе не являются достаточным доказательством RCE, поскольку они могут быть вызваны предварительным просмотром ссылок или другими нейтральными функциями.Ложные срабатывания распространены, особенно когда сканеры используют метасимволы оболочки в средах, которые их не выполняют. Автор выступает за повторяемые, проверяемые результаты, а не за полагание на единичные, непоследовательные наблюдения. Конечная цель — подтвердить, могло ли значение существовать только из-за выполнения входных данных на стороне сервера, а не просто из-за задержки ответа.