HTTP Request Smuggling: почему это не про «взлом» — а про систему
Наткнулся на разбор HTTP Request Smuggling — не просто техническая дыра, а способ, как заставить серверы «не понимать» друг друга. И это не про «хакеров, выбранных вами» — это про боты, которые сканируют всё подряд.
О чём речь и почему я считаю это важным для сайта
Речь о том, как серверы могут по-разному читать один и тот же запрос. Фронтенд и бэкенд «считают» длину запроса по-разному — и в этом зазоре встраивается вредоносный код. Я не вижу в этом «крупного хакерства» — это не про взлом из-за уязвимости в коде. Это про то, что боты массово сканируют, и если у вас есть дыра в архитектуре, они в неё влезут.
Сайт может быть чист, но если бэкенд «не понимает» запрос, то вредоносный код — даже не в вашей системе — может быть «приклеен» к чужому запросу. И это не просто уязвимость — это фундаментальная уязвимость в архитектуре.
Как это устроено — что тут вообще происходит
Представьте, что серверы получают поток байтов, а не отдельные запросы. Один — считает, что запрос заканчивается по Content-Length. Другой — по Transfer-Encoding: chunked.
Если в одном запросе есть и то, и другое, и серверы не согласны, где граница — получается десинхрон. Один считает, что тело закончилось, другой — нет. И то, что осталось в буфере, становится «хвостом» — частью следующего запроса.
Атакующий может вставить в этот хвост код, который потом выполнится у другого пользователя. Это не про доступ к админке. Это про то, что кто-то, кто зашёл на ваш сайт, может получить вредоносный скрипт — даже если вы ничего не сломали.
Как понять, что это касается вашего сайта
Я не проверяю это по списку уязвимостей. Я смотрю на архитектуру. Если у вас есть балансировщик, CDN, реверс-прокси — и бэкенд на PHP или Node.js — вероятность есть.
Проверяю: — Есть ли в настройках фронтенда и бэкенда разные правила обработки заголовков? — Поддерживает ли бэкенд Transfer-Encoding в запросах? — Есть ли в логах неожиданные «хвосты» — байты, которые не вписываются в запрос?
Если серверы не согласны в том, как читать длину — это уже тревога. Я не жду, пока взломают. Я проверяю, где может быть десинхрон.
Что с этим делать
Сначала — не паниковать. Это не про «сайт взломали». Это про то, что нужно убрать разногласие в интерпретации.
Я начинаю с того, что проверяю, как обрабатываются заголовки Content-Length и Transfer-Encoding на всех уровнях. Если один сервер игнорирует Transfer-Encoding, а другой — нет — это риск.
Устраняю: — Убираю возможность одновременного использования обоих заголовков. — Настрою фронтенд и бэкенд так, чтобы они «говорили» на одном языке. — Проверяю, не пропускаются ли запросы с неправильной структурой.
Важно: не просто «поставить флаг» — нужно убрать причину. Иначе через неделю снова будет то же самое.
Что здесь даёт поддержка
На нашей поддержке я закрываю эту задачу не разово, а системно. Потому что почистить — мало. Заражают не «хакеры, выбравшие вас», а боты, которые сканируют уязвимости по всему интернету. Если дыра останется — она откроется снова.
Мы мониторинг каждые несколько минут, 24/7. Это значит, что если что-то появится — мы увидим это раньше, чем вы.
А пока — приглашаю на бесплатный аудит безопасности. Проверим, где может быть зазор между серверами. И закроем его, пока не стало поздно.