Тестировщик получает поле, проверяемое регулярным выражением; как установить, что специально сформированное значение вызывает чрезмерное время обработки?
Нужно проверить риск ReDoS: подобрать входы, которые провоцируют экспоненциальный или существенно замедленный перебор вариантов в регулярном выражении, и сравнить время обработки с безопасными контрольными значениями. Тест считается подтверждённым, если рост длины входа вызывает непропорциональный рост времени или исчерпание ограниченных ресурсов сервиса.
Проверку следует выполнять в изолированной среде, с тайм-аутом, ограничением длины входа и мониторингом загрузки CPU. Нельзя оценивать риск только по тому, что регулярное выражение выглядит сложным: важны фактическое поведение движка и доступность этого пути обработки извне.
Регулярные выражения появились как компактный способ поиска и проверки текстовых шаблонов. Многие популярные движки используют обратный перебор: при неоднозначном совпадении они пробуют разные варианты, возвращаясь к предыдущим позициям.
Такой механизм удобен для выразительных шаблонов, но некоторые сочетания повторяющихся групп и альтернатив создают огромное количество вариантов. На специально сформированном вводе проверка может занять значительное время, поэтому проблема стала рассматриваться как разновидность отказа в обслуживании на уровне приложения.
Уязвимость возникает, когда недоверенный ввод передаётся в регулярное выражение без достаточных ограничений, а движок способен долго перебирать варианты. Особенно опасны неоднозначные конструкции с вложенными повторениями или альтернативами, когда большая часть строки подходит, но совпадение ломается в самом конце.
Последствия зависят от архитектуры. Один запрос может надолго занять поток, процессор или рабочий слот; параллельные запросы способны снизить пропускную способность, вызвать рост очередей, тайм-ауты и отказ в обслуживании. Если регулярное выражение строится из пользовательских данных, риск дополнительно включает возможность внедрения опасной структуры самого шаблона.
Сначала нужно определить точку обработки: какой endpoint принимает значение, какая операция применяет регулярное выражение, запускается ли она синхронно и ограничено ли время её выполнения. Затем формируют серии входов: корректные, некорректные и почти совпадающие с шаблоном, постепенно увеличивая длину и сохраняя одинаковую структуру.
Важно сравнивать результаты с контрольным шаблоном или обычным входом такой же длины. Измеряются время ответа, загрузка CPU, число занятых рабочих потоков, тайм-ауты и влияние одного запроса на параллельные запросы. Один медленный ответ ещё не доказывает ReDoS: причиной могут быть сеть, база данных или холодный запуск, поэтому измерения повторяют и локализуют участок обработки.
Безопасные меры включают отказ от неоднозначных шаблонов, разбиение сложной проверки на простые этапы, ограничение длины и структуры входа, применение движка с гарантированно линейным временем для подходящего подмножества регулярных выражений и жёсткий тайм-аут. Тайм-аут снижает ущерб, но не устраняет расход CPU полностью; ограничение длины помогает только при разумно выбранном пределе и не заменяет анализ шаблона.
Если шаблон задаёт пользователь, его нельзя считать безопасным только после экранирования обычных символов: экранирование предотвращает изменение смысла данных, но не обязательно ограничивает вычислительную сложность самого шаблона. В таком случае нужны разрешённый синтаксис, лимиты сложности, безопасный движок или отказ от пользовательских регулярных выражений.
В сервисе поиска фильтр по имени проверялся регулярным выражением. Обычные запросы завершались быстро, но длинные строки, почти соответствующие шаблону и заканчивающиеся несовпадающим символом, резко увеличивали время ответа; при нескольких параллельных запросах росла загрузка CPU и начинали истекать тайм-ауты.
Рассматривались три варианта. Простое увеличение тайм-аута не решало проблему и увеличивало время удержания ресурсов. Полный запрет регулярных выражений снижал риск, но ломал востребованный сценарий. Переписывание шаблона на однозначные последовательные проверки вместе с ограничением длины сохранило функциональность и сделало время обработки предсказуемым.
Выбрали третий вариант, а для дополнительной защиты добавили лимит времени операции и метрики медленных совпадений. После исправления увеличение длины входа не приводило к резкому росту времени, а запросы с превышением лимитов отклонялись до дорогостоящей обработки.
Нет. Нужна серия входов с постепенным увеличением длины и разными точками несовпадения. ReDoS проявляется как характерная зависимость времени от размера и структуры строки; единичная задержка не отличает его от случайного сбоя или внешней нагрузки.
Нет. Тайм-аут ограничивает продолжительность отдельной операции, но до его срабатывания процессор уже расходуется. При большом числе параллельных запросов можно исчерпать рабочие потоки, очередь или CPU, поэтому тайм-аут должен сочетаться с ограничением размера входа, rate limiting и безопасной структурой проверки.
Нет. Риск зависит от конкретного движка, шаблона, входа и способа выполнения. Движки с гарантированными ограничениями времени или линейной обработкой определённого класса шаблонов могут не иметь такого поведения, но это нужно подтвердить документацией и тестами, а не предполагать по названию технологии.