В настоящее время я пытаюсь настроить небольшую витрину и доказательство концепции атаки HTTP-запроса-контрабанды (https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn) с уязвимостью Content-Length.Transfer-Encoding. Чтобы это работало, я хочу создать обратный прокси, такой как HAProxy или nginx, и еще один HTTP-сервер в бэкэнде, предпочтительно в докере, и связать оба с помощью docker-compose. Все запросы, которые поступают на прокси во внешнем интерфейсе, должны использовать заголовок Content-Length для определения длины тела HTTP. (это относится к большинству современных HTTP-серверов и прокси) и бэкэнду заголовок «Transfer-Encoding».
Сценарий такой:
1) Я отправляю запрос на прокси с установленными заголовками «Content-Length» и «Transfer-Encoding: chunked». Прокси-сервер устанавливает приоритет длины содержимого (или игнорирует кодировку передачи, потому что она не включена для прокси), проверяет, правильна ли длина содержимого для соответствующего тела HTTP, и, если это так, он просто перенаправляет этот запрос в бэкэнд. .
2) Серверная часть получает этот запрос, но проверяет только заголовок «Transfer-Encoding: chunked» и игнорирует Content-Length.
У меня вопрос: какие известные HTTP-серверы отдают предпочтение Transfer-Encoding над Content-Length в своей конфигурации по умолчанию? Я слышал, что Gunicorn делает это по умолчанию, но я пытаюсь найти альтернативу, желательно образ Docker, который я могу найти на Docker Hub.
Заранее спасибо за помощь