HTTP Method Override выглядит почти безобидно. Клиент отправляет обычный POST или даже GET, а приложение на стороне сервера решает считать запрос DELETE, PUT или PATCH. Такой механизм появился не ради «хака», а как технический костыль для форм, старых клиентов, прокси и промежуточных узлов, которые плохо работали с полным набором HTTP-методов.
Для пентестера интересен не сам костыль, а рассинхрон между слоями. Фронтовой прокси считает, что пришел POST. Маршрутизатор фреймворка уже видит DELETE. Кэш запоминает ответ как на GET. Проверка прав сработала для одного метода, а бизнес-логика выполнилась для другого. В такой точке и рождаются обходы контроля доступа, странные ошибки кэширования, сбои в CSRF-защите и просто очень неприятные «теневые» маршруты.
Что такое HTTP Method Override и почему тема вообще жива
Чаще всего переопределение метода встречается в одном из двух видов. Первый вариант использует заголовок вроде X-HTTP-Method-Override, X-HTTP-Method или X-Method-Override. Второй вариант использует параметр формы или строки запроса, обычно _method. В OWASP такой сценарий давно вынесен в отдельную проверку, потому что поддержка override регулярно всплывает в реальных приложениях и API.
Ловушка в том, что разработчики нередко воспринимают механизм как чисто прикладную деталь фреймворка. На практике Method Override почти всегда пересекает границы между компонентами. Запрос проходит через балансировщик, CDN, WAF, обратный прокси, middleware аутентификации, маршрутизатор и только потом добирается до обработчика. Если хотя бы два узла понимают метод по-разному, пентестер получает отличную точку для аудита.
Где Method Override дает реальную находку, а где остается просто особенностью
Сам факт поддержки override еще не делает приложение уязвимым. Если вся цепочка видит одинаковый итоговый метод, проверка прав привязана к уже нормализованному запросу, опасные действия не торчат наружу, а кэш не участвует в маршруте, уязвимости может и не быть. Но такая аккуратная архитектура встречается заметно реже, чем хотелось бы.
| Узел | Что может пойти не так | Симптом для пентестера |
|---|---|---|
| Прокси или WAF | Фильтрует только «настоящий» метод из стартовой строки | DELETE запрещен напрямую, но проходит как POST с override |
| Маршрутизатор фреймворка | Выбирает другой обработчик после нормализации метода | POST и POST + override попадают в разные ветки логики |
| Проверка прав | Смотрит на исходный метод, а не на эффективный | Обычный пользователь выполняет действие, доступное только для PUT или DELETE |
| CSRF-защита | Ожидает POST, а приложение фактически исполняет GET или другой метод | Возникают неожиданные обходы через навигацию или формы |
| Кэш или CDN | Ключ кэша и бизнес-логика расходятся | Появляются странные кешированные ошибки или «отравленные» ответы |
| Логи и мониторинг | Журналы пишут исходный метод, а действие выполнено как другой | Инцидент трудно расследовать, картина в SIEM и в приложении не совпадает |
Как проверять Method Override на стенде без лишнего тумана
Начинать лучше с обычной инвентаризации. Найдите маршрут, который явно ожидает PUT, PATCH или DELETE. Затем проверьте, что происходит при прямом вызове. Если сервер отвечает 405, 403 или 404, это еще не конец. Следующий шаг для authorized-теста уже очевиден: отправить допустимый с точки зрения фронта запрос и попробовать переопределить метод заголовком или параметром.
curl -i -X DELETE https://target.local/api/profilecurl -i -X POST https://target.local/api/profile
-H "X-HTTP-Method-Override: DELETE"curl -i -X POST "https://target.local/api/profile?_method=DELETE"После такого запроса смотреть нужно не только на код ответа. Полезнее сравнить четыре вещи: изменилось ли состояние данных, сменился ли обработчик, поменялся ли набор заголовков и одинаково ли событие попало в журналы. Если прямой DELETE отвергается, а POST с override внезапно удаляет объект, перед вами уже не «особенность фреймворка», а содержательная находка.
На практике имеет смысл перебирать не один, а несколько вариантов. OWASP советует хотя бы три заголовка: X-HTTP-Method, X-HTTP-Method-Override и X-Method-Override. Параметр _method тоже проверяется обязательно. Некоторые приложения слушают только заголовок, некоторые только параметр, а самые неудобные поддерживают оба механизма сразу.
Нетривиальные сценарии, где находка действительно стоит времени
Обход контроля доступа
Классический случай выглядит скучно, но встречается постоянно. Интерфейс или фронтовой узел блокирует DELETE и PUT, потому что «опасные методы запрещены». Разработчик при этом включил override в приложении, чтобы формы работали удобнее. В результате POST с нужным заголовком доходит до ветки удаления. Снаружи система как будто «запрещает» опасный метод, внутри спокойно исполняет.
CSRF и путаница с безопасными методами
Отдельная категория риска появляется там, где команда слишком доверяет различию между GET и POST. В учебных материалах PortSwigger показан важный нюанс: если приложение умеет переопределять метод, а защита завязана на браузерные допущения о «безопасных» запросах, возникают обходы, о которых разработчик вообще не думал. Не каждая такая ситуация дает эксплуатацию, но как минимум требует ручной проверки, а не галочки в чек-листе.
Кэш и CPDoS
Здесь Method Override уже выходит за рамки обычной веб-логики. На SecurityLab разбирали сценарий CPDoS, где заголовки переопределения метода участвовали в отравлении кэша ошибочным ответом. Для пентеста такая ветка особенно интересна там, где спереди стоит CDN или тяжелый reverse proxy, а приложение по-разному обрабатывает исходный и эффективный методы.
Теневые маршруты и странные 200 OK
Иногда разработчик уверен, что защищенный маршрут недоступен, потому что обычный DELETE возвращает 405. Но POST с override внезапно дает 200 и попадает в другой контроллер. Подобные вещи часто всплывают не в «чистом» API, а в смешанных приложениях, где рядом живут HTML-формы, старые административные страницы и REST-маршруты.
Почему одной проверки «сервер принял заголовок» мало
Многие отчеты по пентесту сыплются на одной и той же ошибке. Тестер видит, что приложение реагирует на X-HTTP-Method-Override, и сразу пишет «обход защиты». Но поддержка заголовка без вредного эффекта еще ничего не доказывает. Нужен реальный рассинхрон. Нужно показать, что доступ, состояние, кэширование, журналирование или защитная логика меняются не так, как ожидалось при исходном методе.
Иными словами, хороший отчет по Method Override почти никогда не строится вокруг одной строки запроса. Хороший отчет строится вокруг разницы между ожиданием слоя A и фактом на слое B. Чем яснее показан этот разрыв, тем сильнее находка.
На что смотреть в коде и конфигурации
Если у вас есть white-box или хотя бы доступ к конфигам, проверка становится намного быстрее. Ищите middleware, которое нормализует метод до проверки прав. Ищите роуты, где для POST и DELETE задана разная логика, но один и тот же путь. Ищите привязку ACL к request.method в одном месте и к уже переписанному полю в другом. Ищите обработчики форм, которые принимают _method без явного белого списка.
Отдельно полезно посмотреть, как ведет себя стек по умолчанию. В документации Express прямо указано, что middleware method-override по умолчанию смотрит на заголовок X-HTTP-Method-Override и обычно должен применять override только для POST. Там же отдельно предупреждают, что расширение на другие методы может дать странное поведение и проблемы с кэшами. Такая оговорка хорошо показывает суть риска: опасность рождает не сам механизм, а попытка использовать его слишком широко.
Как чинить без театра безопасности
- Отключать Method Override там, где реальной потребности уже нет.
- Если отключить нельзя, разрешать override только из POST и только для нужного набора методов.
- Проверять права уже после окончательной нормализации метода и одинаково для всех веток маршрута.
- Не полагаться на «запрет опасных методов» только на уровне прокси или WAF.
- Разводить кэширование и чувствительные маршруты так, чтобы переопределение метода не влияло на ключ кэша и обработку ошибок.
- Логировать и исходный, и эффективный метод, иначе расследование инцидента превращается в угадайку.
Проверять Method Override имеет смысл только на собственных стендах, в лаборатории или в системах с явным письменным разрешением на аудит. Нельзя использовать такие техники против чужих ресурсов, для обхода фильтров провайдеров, WAF, CDN, корпоративных ограничений или любых блокировок. При работе из России и с российской инфраструктурой отдельно соблюдайте применимое законодательство и внутренние правила заказчика.
FAQ
Method Override сам по себе считается уязвимостью?
Нет. Уязвимость появляется, когда из-за override расходятся контроль доступа, маршрутизация, кэш, CSRF-защита или журналирование.
Какие индикаторы самые полезные во время ручной проверки?
Разница между прямым вызовом метода и POST с override, изменение состояния данных, другой обработчик, иной код ответа, несовпадение в логах и неожиданные кешированные ответы.
Нужно ли проверять только X-HTTP-Method-Override?
Нет. Обычно тестируют X-HTTP-Method, X-HTTP-Method-Override, X-Method-Override и параметр _method. Иногда работает только один вариант.
Где риск выше всего?
В старых смешанных приложениях, где рядом живут формы, административные страницы, API, внешний прокси, кэш и разросшиеся middleware с историческими настройками.
Когда тему можно считать переоцененной?
Когда приложение строго ограничивает override, вся цепочка видит одинаковый итоговый метод, проверки прав выполняются после нормализации, а опасные действия не зависят от путаницы между GET, POST, PUT и DELETE.
Вывод
HTTP Method Override хорош тем, что быстро показывает зрелость всей цепочки обработки запроса. Если архитектура аккуратная, тест почти ничего не найдет и вы закроете тему за десять минут. Если в системе накопились старые компромиссы между прокси, фреймворком и защитными прослойками, маленький заголовок или параметр _method внезапно вытащит на свет очень большую проблему. Для пентестера это не экзотика и не трюк ради трюка, а простой способ проверить, понимают ли разные слои приложения один и тот же запрос одинаково.
