Статья Заражение соединения HTTP/3: грядущая угроза?

[вавилонец]

ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов

Недавно я задокументировал опасное поведение обратного прокси-сервера, называемое маршрутизацией по первому запросу, которое позволяет проводить атаки с использованием заголовков хоста на серверные системы. В этом посте я покажу, как маршрутизация по первому запросу также делает возможной атаку на стороне клиента, основанную на браузере, называемую заражением HTTP-соединения. Этот метод работает в системах, использующих HTTP/2, и, вероятно, станет более серьезной угрозой с появлением HTTP/3. Веб-браузеры имеют блестящую функцию, называемую объединением HTTP-соединений , которая позволяет им повторно использовать одно соединение HTTP/2+ для запросов, направляемых на разные веб-сайты, при условии, что сайты разрешаются на один и тот же IP-адрес и используют сертификат TLS, действительный для обоих имен хостов. Маршрутизация по первому запросу — это опасное поведение обратного прокси-сервера, когда прокси-сервер анализирует первый запрос на соединение, чтобы определить, к какой серверной части его направить, а затем отправляет все последующие запросы по этому соединению на ту же серверную часть. Объединение соединений и маршрутизация по первому запросу плохо сочетаются друг с другом. Например, представьте, что secure.example.com и wordpress.example.com находятся за обратным прокси-сервером с использованием сертификата, действительного для *.example.com:

nslookup wordpress.example.com
52.16.179.7 // reverse proxy that supports HTTP/2 and does first-request routing

$ nslookup secure.example.com
52.16.179.7  // same reverse proxy

$ openssl s_client -connect x.portswigger-labs.net:443
subject=/CN=*.example.com // wildcard TLS certificate

Если браузер попытается отправить запрос на wordpress.example.com, а затем на secure.example.com, объединение соединений браузера приведет к тому, что оба запроса будут отправлены через одно соединение с внешним интерфейсом. Маршрутизация первого запроса приведет к тому, что запрос на secure.example.com будет неправильно перенаправлен на серверную часть WordPress. Это означает, что если вы найдете XSS на wordpress.example.com, вы можете использовать его для компрометации secure.example.com!

// create HTTP/2+ connection
fetch('https://wordpress.example.com/', {credentials: 'include'})

// connection coalescing will force this down the same connection...
// ...leading to the front-end misrouting it to WordPress
// the browser thinks our injected JS is coming from secure.example.com
// exposing saved passwords, cookies, etc.
location='https://secure.example.com/plugin/x?q=<script>stealPasswords()'

Вы можете изучить объединение соединений самостоятельно, используя график синхронизации на вкладке «Сеть» в инструментах разработчика Chrome (или используя WireShark, если вы мазохист). Выполните пару запросов с помощью fetch() и посмотрите, показывает ли график время, затраченное на «инициацию подключения» для второго запроса, и соответствует ли столбец идентификатора подключения:

fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })

Я не стал тратить время на глубокое изучение этой угрозы или ее сканирование в дикой природе, поскольку считаю, что в настоящее время она встречается редко по двум причинам.
Во-первых, маршрутизация первого запроса встречается относительно редко, а сложность реализации HTTP/2 означает, что существует лишь небольшой пул уникальных серверов HTTP/2 по сравнению с HTTP/1.1.
Во-вторых, коалесценция соединений означает, что HTTP/2-серверы, выполняющие маршрутизацию первого запроса, могут периодически ломаться для настоящих посетителей, поэтому владельцы могут в конечном итоге устранить уязвимость без поддержки злоумышленников.
Тем не менее, это не все плохие новости для злоумышленников. HTTP/3 предлагает отменить требование о совпадении IP-адресов, что подвергнет опасности всех, у кого есть front-end, использующий маршрутизацию первого запроса и имеющий сертификат, действительный для нескольких хостов.
Это также создает второй риск, который не связан с маршрутизацией первого запроса - это означает, что взломанный сервер с сертификатом wildcard больше не требует MITM для эксплуатации. По сути, это значительно увеличивает число злоумышленников, которые могут извлечь из этого выгоду. Чтобы избежать этих рисков до того, как они станут реальностью, убедитесь, что ваши обратные прокси не выполняют маршрутизацию по первому запросу. Вы можете проверить это вручную в Repeater, включив повторное использование соединений HTTP/1 и HTTP/2, а также проверить это с помощью атаки 'Connection-State' в HTTP Request Smuggler. Также имейте в виду, что хотя сертификаты TLS с диким знаком никогда не были идеальным решением, HTTP/3 означает, что взломанный сервер с сертификатом теперь может быть использован для атаки на соседние домены без активного MITM.
Эти новые угрозы продолжают тенденцию превращения веб-инфраструктуры в сильно переплетенный беспорядок, где слабость любого отдельного сайта имеет множество неочевидных последствий для безопасности всей системы. Будет интересно посмотреть, как эти риски проявятся на практике.