📚 Теория: ReDoS в списках (раскрыть)
Сложные регекспы × большой объём
Регексп ^([\\w\\.-]+)+@[\\w\\.-]+$ содержит вложенные квантификаторы. При длинном email’е он работает экспоненциально долго.
⚠️ Умножь это на 1000 email’ов — DoS гарантирован.
Как защититься?
Выставь лимиты (@Size на списки/строки, hard cap в конфиге), используй @Email + простые whitelist-правила, добавь прогрев queue.
🔐 Категорически необходимо pre-валидация и идемпотентная очередь.
Нападающий отправляет 500 адресов с огромными строками.
Каждый email прогоняется через тяжёлый регексп → CPU 100%.
Очередь зависает, воркеры не отвечают, SLA падает.
Как надо: лимитируй входные данные, используй `@Email`, precompiled `Pattern`, ограничения на размер списка, а также стресс-тесты с ReDoS-пэйлоадами.
Контекст
CRM команда решила, что email должен быть «гибким», и вставила тяжёлый регексп. Rate-limitов и батч-лимитов нет, валидация синхронная. Одна атака — и очередь падает.
- Укажи строку с уязвимым
@Pattern. - Рекомендуй:
@Email,@Size(max=320), лимит списка@Size(max=100), streaming queue. - Предложи тест: JUnit с 100 email’ами длиной 10k символов → ожидать 400 за секунду.
Сниппет
Code Review
Референс-исправление
Используй безопасные валидаторы и лимиты.
Флаг ревью: FLAG{java-redos-invite}
public record InviteRequest(
@NotNull
@Size(max = 100)
List<@Email @Size(max = 320) String> emails
) {}Добавь batch limiter, асинхронную очередь, тесты с ReDoS строками и мониторинг времени обработки.
Проверка флага
После ревью зафиксируй флаг, чтобы дашборд засчитал лабораторию.