Что такое Top 10 на самом деле
OWASP — Open Worldwide Application Security Project — публикует ранжированный список категорий риска для веб-приложений, который пересматривается раз в несколько лет на основе данных о реальных инцидентах и сканированиях. Текущий список возглавляют broken access control, cryptographic failures и injection.
Из того, как он устроен, следуют две вещи, и обе теряются в маркетинговых текстах вендоров.
Это категории, а не уязвимости. «Injection» охватывает SQL-инъекции, инъекции команд, LDAP-инъекции и инъекции шаблонов. Продукт не может «поддерживать» категорию — он может лишь обнаруживать отдельные техники внутри неё.
Это инструмент расстановки приоритетов для тех, кто разрабатывает приложение. Он показывает, куда тратить время на ревью. Это никогда не было чек-листом для комплаенса, и файрвол перед приложением не заставляет список исчезнуть.
Что такое WAF, одним абзацем
Веб-файрвол приложений располагается перед вашим приложением и проверяет каждый запрос — путь, строку запроса, заголовки, cookie и тело — на соответствие набору правил. Если правило совпало, запрос блокируется, логируется или и то и другое — ещё до того, как ваше приложение вообще запустится.
Открытый набор правил, на котором построено большинство WAF, — это OWASP Core Rule Set (CRS), набор универсальных правил обнаружения, который поддерживает тот же фонд. Именно этот набор правил мы используем на edge, поверх ModSecurity. CRS группирует свои правила в семейства с числовыми диапазонами — 941 для межсайтового скриптинга, 942 для SQL-инъекций, 930 для локального включения файлов, 931 для удалённого включения файлов, 932 для удалённого выполнения команд, 933 для PHP-инъекций, — поэтому заблокированный запрос можно проследить до точного номера правила, а не до расплывчатой «политики безопасности».
Категория за категорией: что файрвол делает на самом деле
Injection — здесь WAF действительно силён. SQL-инъекции, инъекции команд и инъекции шаблонов оставляют узнаваемые следы в данных запроса. Именно это умеет сопоставление паттернов, и правила прямо ловят большинство оппортунистических попыток. Это не делает параметризованные запросы необязательными — это покупает вам время и останавливает автоматизированное большинство атак.
Cross-site scripting — силён, но с оговорками. Скриптовые полезные нагрузки в параметрах обнаруживаются. Хранимый XSS, приходящий через путь, который файрвол не проверяет, или проблема на уровне DOM, вообще не касающаяся вашего сервера, — вне досягаемости.
Security misconfiguration — частично. WAF может скрыть баннер сервера, заблокировать доступ к .git и резервным файлам, отказать в опасных методах. Он не может исправить слишком разрешительную политику CORS или админ-панель с паролем по умолчанию.
Vulnerable and outdated components — частично и временно. Когда CVE становится публичным, универсальные правила часто ловят опубликованную форму эксплойта, и в этом вся ценность «виртуального патчинга»: он покупает дни между раскрытием уязвимости и вашим окном на обновление. Это не замена самому обновлению.
Broken access control — по большей части нет. Если ваше приложение позволяет пользователю A получить счёт пользователя B, поменяв ID в URL, оба запроса выглядят для файрвола одинаково. Он понятия не имеет, кому принадлежит счёт 4711. Это первая категория в текущем списке, и это баг авторизации в вашем коде.
Identification and authentication failures — частично. Rate limiting на эндпоинтах логина притупляет credential stuffing и перебор паролей, и это реальная, стоящая внимания польза. Слабую обработку сессий или процесс сброса пароля, который утекает токенами, файрвол не видит.
Insecure design and software integrity failures — нет. Это архитектурные проблемы. Никакой паттерн запроса их не выражает.
Проблема ложных срабатываний и почему она решает всё
Любой набор правил, достаточно агрессивный, чтобы ловить инъекции, время от времени будет блокировать живого человека. Классический случай — редактор контента сохраняет статью с примером кода, или в форме поддержки кто-то вставляет сообщение об ошибке, содержащее SQL. Запрос легитимен — он просто похож на атаку.
Именно здесь WAF операционно выигрывают или проигрывают. Если ложное срабатывание означает «сайт сломан для этого человека, и никто не может объяснить почему», WAF отключат в течение месяца — и это худший исход, потому что защита исчезает тихо, пока все считают, что она включена.
Выживаемость обеспечивает прослеживаемость. На нашем edge заблокированный запрос возвращает брендированную страницу 403 с ID запроса, и этот ID сопоставляется с записью в журнале аудита с правилом, которое сработало, и полем, на котором оно сработало. Разговор в поддержке превращается из «сайт иногда меня блокирует» в «правило 942100 сработало на поле content на URL редактора». Решение тогда — узкое исключение: это правило, это поле, этот путь. Не семейство правил и не весь сайт.
Уровни паранойи: регулятор, который никто не объясняет
Core Rule Set поставляется с уровнями паранойи от 1 до 4. Уровень 1 ловит очевидное и редко блокирует живого человека. Каждый следующий уровень добавляет более строгие и более склонные к ложным срабатываниям правила, пока на уровне 4 файрвол не начинает отказывать в том, что обычное приложение делает каждый день.
Честный совет звучит скучно. Начните со значения по умолчанию, понаблюдайте за логом неделю и поднимайте уровень только если защищаете что-то, что оправдывает операционные издержки, — и сначала делайте это в staging-окружении. Большинству сайтов лучше служит хорошо настроенный уровень 1, чем уровень 3, который кто-то молча отключил после третьей жалобы.
Как оценить «покрытие OWASP Top 10» у вендора
Четыре вопроса пробивают большую часть маркетинга.
1. Какой набор правил и какой версии? «На основе OWASP» может означать Core Rule Set, а может — собственные правила вендора с названиями в стиле OWASP. Версия тоже важна: наборы правил пересматриваются, и использование устаревшей версии — это реальный компромисс, а не мелкая деталь. Мы используем CRS и обновляем его осознанно, тестируя на паттернах ложных срабатываний, с которыми сталкиваются наши собственные клиенты, а не отслеживаем апстрим автоматически.
2. Что я вижу, когда запрос заблокирован? Если ответ — это стандартная страница ошибки и лог, который нельзя искать по правилу, настройка превратится в гадание.
3. Как исключить одно поле на одном пути? Если наименьшее доступное исключение — это «отключить семейство правил для этого сайта», продукт подталкивает вас к тому, чтобы просто выключить защиту.
4. Что не покрыто? Вендор, который отвечает «контроль доступа и бизнес-логика — это ваш код, а не наши правила», говорит вам правду. Тот, кто заявляет о полном покрытии Top 10, описывает список категорий, а не реальную возможность.
Частые вопросы
Делает ли WAF моё приложение соответствующим OWASP?
Такой вещи, как «соответствие OWASP», не существует. Top 10 — это документ для повышения осведомлённости и расстановки приоритетов, а не стандарт, на соответствие которому сертифицируют. WAF снижает риск в одних категориях и ничего не делает в других; приложение всё равно нужно писать аккуратно.
OWASP Core Rule Set — это то же самое, что OWASP Top 10?
Нет. Top 10 — это список рисков. Core Rule Set — это набор универсальных правил обнаружения, который поддерживает тот же фонд и который используют ModSecurity и совместимые движки. Набор правил затрагивает несколько категорий из Top 10, но не реализует список целиком.
Может ли WAF полностью остановить SQL-инъекции?
Он останавливает подавляющее большинство оппортунистических попыток и поднимает планку усилий для целевых атак. Это не замена параметризованным запросам, потому что настроенный на цель атакующий подгонит полезную нагрузку так, чтобы обойти сопоставление паттернов. Относитесь к нему как к дополнительному слою защиты, а не как к решению проблемы.
Что такое виртуальный патчинг?
Блокировка формы эксплойта известной уязвимости на файрволе, пока вы ждёте возможности выкатить настоящее исправление. Это по-настоящему полезно в промежутке между публикацией CVE и наступлением вашего окна на обслуживание, и это опасно, если становится постоянным решением.
О какой категории из Top 10 стоит беспокоиться больше всего?
О Broken access control — потому что она на первом месте в текущем списке, встречается часто, и именно в этом случае файрвол вам не поможет. Проверяйте, что каждый объект, который возвращает ваш API, — это объект, на который у авторизованного пользователя действительно есть право; в основе большинства таких багов лежит отсутствующая проверка владения объектом в контроллере.