HTTP Connection Contamination

Reading time: 2 minutes

To jest podsumowanie posta: https://portswigger.net/research/http-3-connection-contamination. Sprawdź go, aby uzyskać więcej szczegółów!

Przeglądarki internetowe mogą ponownie używać pojedynczego połączenia HTTP/2+ dla różnych stron internetowych dzięki HTTP connection coalescing, pod warunkiem, że mają wspólne adresy IP i wspólny certyfikat TLS. Jednak może to kolidować z routingiem pierwszego żądania w reverse-proxy, gdzie kolejne żądania są kierowane do zaplecza określonego przez pierwsze żądanie. To błędne kierowanie może prowadzić do luk w zabezpieczeniach, szczególnie w połączeniu z certyfikatami TLS typu wildcard i domenami takimi jak *.example.com.

Na przykład, jeśli wordpress.example.com i secure.example.com są obsługiwane przez to samo reverse proxy i mają wspólny certyfikat wildcard, koalescencja połączeń w przeglądarce może spowodować, że żądania do secure.example.com będą błędnie przetwarzane przez zaplecze WordPressa, wykorzystując luki takie jak XSS.

Aby zaobserwować koalescencję połączeń, można użyć zakładki Sieć w Chrome lub narzędzi takich jak Wireshark. Oto fragment do testowania:

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

Zagrożenie jest obecnie ograniczone z powodu rzadkości routingu pierwszego żądania i złożoności HTTP/2. Jednak proponowane zmiany w HTTP/3, które łagodzą wymagania dotyczące dopasowania adresu IP, mogą poszerzyć powierzchnię ataku, czyniąc serwery z certyfikatem dzikiej karty bardziej podatnymi bez potrzeby ataku MITM.

Najlepsze praktyki obejmują unikanie routingu pierwszego żądania w odwrotnych proxy oraz ostrożność w przypadku certyfikatów TLS z dziką kartą, szczególnie w obliczu nadejścia HTTP/3. Regularne testowanie i świadomość tych złożonych, powiązanych luk są kluczowe dla utrzymania bezpieczeństwa w sieci.