Written by

Cyber Team

in

,

HTTP/1.1 mora umreti: zakaj desinhronizacija ubija varnost in zakaj je čas za HTTP/2

1) Zakaj je HTTP/1.1 tako ranljiv

HTTP/1.1 trpi zaradi “dvoumnih” zahtevkov: različne naprave (CDN-ji, WAF-i, reverse proxyj-i, aplikacijski strežniki) lahko različno razčlenjujejo glave in telo (Content-Length vs. Transfer-Encoding, presledki, CR/LF odstopanja). Napadalci to izkoristijo za request smuggling/desync – prisilijo “front-end” in “back-end” v nesoglasje o tem, kje se en zahtevek konča in začne naslednji, kar odpre vrata za zastrupljanje predpomnilnikov, krajo sej, SSRF in obvode WAF-a. PortSwigger je letos pokazal nove razrede teh napadov in jasno sporočilo z Black Hat: desync je še vedno povsod, še posebej tam, kjer se HTTP/2 potiho pretvarja v HTTP/1.1 zadaj.

Dodaten problem je “nevidno zniževanje protokola”: mnogi robni sistemi sprejemajo HTTP/2 od brskalnika, nato pa tiho pretvorijo promet v HTTP/1.1 proti aplikaciji. Ta dodatna plast kompleksnosti spet odpre stara vrata za desync, če parserji na poti niso popolnoma skladni.

Opomba: tudi HTTP/2 ni čarobna krogla – v 2023 smo videli Rapid Reset (CVE-2023-44487), kjer napadalec zlorabi multiplexing in s hitrim pošiljanjem/preklicevanjem streamov povzroči nesorazmeren porast porabe CPU (DoS). To je treba zakrpati in omejevati, a ranljivost je drugačnega tipa kot klasični desync v HTTP/1.1.

2) Kako napadalci pristopijo (na visoki ravni – za modre ekipe)

  • Iščejo neskladja parserjev: primerjajo, kako rob (CDN/reverse proxy) in aplikacijski strežnik obravnavata CL/TE, neobičajne presledke, glave “TE: trailers” ipd. Razlike nakazujejo potencial za desync.
  • Izrabljajo “HTTP/2 → HTTP/1.1” znižanja: ciljajo poti, kjer front-end sprejme h2, back-end pa pričakuje h1. Če se pravila razmejitve razlikujejo, lahko s “fantomskim” delom zahteve manipulirajo naslednji zahtevek žrtve.
  • Posledice uspešnega desynca: zastrupljanje cache-a (stran A vrne vsebino B), kraja sej ali prijavnih tokov, obvoz WAF-a in interni “pivot” (SSRF).
  • Za DoS na h2: poskušajo “Rapid Reset” – množično odpiranje in takojšnje resetiranje streamov, kar ceneje izčrpava strežnik. Obramba: posodobitve in omejitve stopnje/streamov.

3) Remediacija: prehod na HTTP/2 + varne nastavitve (Apache & Nginx)

Ključna načela

  • TLS + ALPN: za brskalnike se HTTP/2 pogaja prek ALPN pri TLS; ne zanašajte se na Upgrade: h2c. Onemogočite h2c (cleartext).
  • Doslednost na poti: zmanjšajte ali odstranite “nevidna znižanja” (CDN/reverse proxy → origin). Če znižanje ostane, poskrbite za enoten, strogo skladen parsing na vseh točkah.
  • Posodobitve: namestite popravke proti CVE-2023-44487 in uvedite omejitve (rate limiting, max concurrent streams, request buffering).

Apache (2.4+)

  1. Omogočite module in ALPN h2 v TLS vhostu (443):
a2enmod http2 ssl headers
<VirtualHost *:443>
    ServerName example.com
    SSLEngine On
    SSLCertificateFile /pot/do/fullchain.pem
    SSLCertificateKeyFile /pot/do/privkey.pem

    # HTTP/2 prek ALPN, brez h2c
    Protocols h2 http/1.1

    # (priporočeno) MPM event + PHP-FPM namesto prefork+mod_php
    # in redni varnostni headerji ...
</VirtualHost>

Za stabilnost/zmogljivost preklopite na mpm_event + PHP-FPM (HTTP/2 in prefork se slabše razumeta). Uradna dokumentacija: mod_http2 in vodič za HTTP/2.

Dodatno:

  • Onemogočite h2c, zanašajte se na h2 (TLS/ALPN).
  • Če uporabljate posrednike, testirajte CL/TE skladnost (desync) na stagingu.

Nginx

V strežniškem bloku za HTTPS dodajte http2 (in uporabite veljaven certifikat):

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /path/fullchain.pem;
    ssl_certificate_key /path/privkey.pem;

    # ...
}

To omogoči HTTP/2 na robu. Poskrbite za TLS in redno posodabljajte Nginx na izdaje, ki naslovijo h2 DoS (Rapid Reset).

Opomba: nekateri reversni proxyji/CDN-ji lahko še vedno govorijo HTTP/1.1 proti originu. Kjer je to mogoče, izberite pot, ki ne uvaja skrite pretvorbe ali zagotovite identična pravila razčlenjevanja ter testirajte desync scenarije (PortSwigger priporočila)

Povzetek

  • Ključ do varnosti je doslednost na vseh sklopih (edge ↔ origin), izklop h2c, redne posodobitve in preizkusi desync na stagingu.
  • HTTP/1.1 je nagnjen k desyncu zaradi zgodovinskih dvoumnosti.
  • HTTP/2 prinaša varnejše ograje (in boljšo zmogljivost), a zahteva pravilno ALPN/TLS nastavitev in popravke (npr. Rapid Reset).

Reference:

  • https://portswigger.net/research/http1-must-die
  • https://www.youtube.com/watch?v=n3Bw8CASnHE

More posts