Заметки по безопасности: RegEx

Может ли RegEx быть уязвимым?

Photo by Markus Spiske on Unsplash

Denial-of-Service с помощью регулярных выражений: ReDOS

Одна из самых неожиданно, но трудно обнаруживаемых уязвимостей, с которыми я сталкивался, связана с регулярными выражениями.
То — плохо написанные, то — плохо реализованные.

Большие или специально сформированные пользовательские данные могут исчерпать память или процессор.

Это уязвимость типа отказа в обслуживании, а не просто «запах» производительности. Если враждебный ввод может удерживать процессор достаточно долго, чтобы лишить реальных пользователей ресурсов, его следует включить в модель угроз безопасности.

Признаки предупреждения

1. Вложенные квантификаторы, повторяющиеся группы или перекрывающиеся альтернативы
2. Движки с интенсивным откатом без тайм‑аутов или ограничений длины ввода
3. Выражение применяется к непроверенным пользовательским данным
4. Проверка регуляркой выполняется в горячем пути запроса

Смягчение / Решение

1. Регулярные выражения — сложная тема.
   1. Например, вот как «по‑умному» советуют работать с проверкой IP‑адресов в [OWASP][owasp]: ^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$
   2. Это длиннее, чем (старый) твит, для всего лишь 4‑байтового IP‑адреса!!!
2. Ограничьте длину ввода до применения регулярного выражения.
3. Добавьте тайм‑ауты, статический анализ или используйте движок без отката, если платформа это поддерживает.
4. Это касается почти всех языков и платформ: .NET, Node, Python, PERL, Java.

Ссылки

• OWASP ReDoS