HTTP Request Smugling angreb, hvordan man undgår det og farer

Når brugere surfer på internettet og udfører forskellige opgaver, er vi udsat for at modtage angreb. Cyberkriminelle leder efter sårbarheder og mangler i vores operativsystemer for at opnå deres fordele. At have et opdateret styresystem og et godt antivirus er derfor altid et godt udgangspunkt at basere vores forsvar på. Internetbrugere er dog ikke det eneste mål for cyberkriminelle. De udfører også angreb på en webserver, en firewall, en proxyserver og mere. I dag skal vi tale om en type angreb, der påvirker sidstnævnte. I denne tutorial skal vi tale om hvad HTTP-anmodningssmugling er og vi vil også forklare, hvorfor det er så farligt.

HTTP-anmodningssmuglingangreb

Hvad gør dette angreb og farer

We kan definere et HTTP Request Smugling-angreb som en, der udnytter uoverensstemmelserne i analysen, når en eller flere HTTP-enheder/enheder er i datastrømmen mellem brugeren og webserveren. Vi støder på en teknik, der forstyrrer den måde, en hjemmeside behandler streams af HTTP-anmodninger, der modtages fra en eller flere brugere.

Disse sårbarheder er ofte af kritisk karakter, hvilket gør det muligt for cyberkriminelle at omgå sikkerhedskontrol, få uautoriseret adgang til private data og endda direkte kompromittere andre brugere af applikationen. Denne ulovlige trafik af HTTP-anmodninger vil tillade forskellige angreb, såsom cacheforgiftning, sessionskapring, og muligheden for at omgå firewallbeskyttelsen af ​​webapplikationer kan opnås.

Dette HTTP Request Smugling-angreb kan påvirke forskellige computere og tjenester:

  • Webserver.
  • Firewall.
  • Proxyserver.

Hvad angår oprindelsen, går det tilbage til 2005, hvor dette angreb blev demonstreret af en gruppe Watchfire-forskere, herunder Klein, Ronen Heled, Chaim Linhart og Steve Orrin. Der er dog foretaget en række forbedringer i de senere år, som udvider angrebsoverfladen og giver maksimal privilegeret adgang til interne API'er og cacheforgiftning.

Hvordan dette angreb opstår

Webapplikationer i dag anvender ofte HTTP-serverstrenge mellem brugere og ultimativ applikationslogik. På denne måde sender brugere anmodninger til en front-end-server, og derefter sender front-end-serveren anmodningerne til en eller flere back-end-servere. Det skal bemærkes, at denne arkitektur bliver hyppigere og i nogle tilfælde uundgåelig, såsom cloud-baserede applikationer.

Når en front-end-server videresender HTTP-anmodninger til en back-end-server, sender den typisk flere anmodninger over den samme back-end-netværksforbindelse. Dette gøres, fordi det er mere effektivt og giver højere ydeevne. Måden at handle på er enkel, først sendes HTTP-anmodningerne den ene efter den anden. Den modtagende server analyserer derefter headerne på hver HTTP-anmodning for at bestemme, hvor en anmodning slutter, og hvornår den næste begynder.

Et meget vigtigt aspekt er, at front-end og back-end systemer skal blive enige om grænserne for anmodningerne . Dette er relevant, fordi en cyberkriminel ellers kunne sende en tvetydig anmodning til front-end- og back-end-systemerne, og de kunne forstå det anderledes.

Her forårsager angriberen, at en del af sin front-end-anmodning bliver fortolket af back-end-serveren som starten på den næste anmodning. Det, der så sker, er, at det går forud for den næste anmodning, hvilket forårsager forstyrrelser i den måde, applikationen behandler anmodningen på. Vi vil støde på et HTTP-anmodningssmuglingsangreb, og det kan have katastrofale resultater for ejeren af ​​den server.

Hvorfor disse angreb opstår

En stor del af HTTP Request Smugling-sårbarhederne opstår, fordi HTTP-specifikationen giver to forskellige måder at angive, hvor en anmodning slutter. En header er enkel, den angiver længden af ​​meddelelsesteksten i bytes. Dette kan bruges til at angive, at meddelelsens brødtekst bruger chunk-kodning. Det betyder, at meddelelsens brødtekst indeholder en eller flere stykker data. Nogle sikkerhedsadministratorer er ikke klar over, at chunked kryptering kan bruges i HTTP-anmodninger, og dette er et problem.

Hvis du ikke ved det, giver HTTP to forskellige metoder til at bestemme længden af ​​HTTP-meddelelser. Det skal også bemærkes, at det er muligt for en enkelt besked at bruge begge metoder på samme tid, i hvilket tilfælde de ville være i konflikt med hinanden. HTTP-protokollen forsøger at løse dette problem ved at angive, at hvis både Content-Length- og Transfer-Encoding-headerne er til stede, så bør Content-Length-headeren ikke bruges. Denne formel kan være tilstrækkelig til at undgå tvetydighed, når vi kun har én aktiv server, men ikke når vi har to eller flere servere kædet sammen.

Derfor, hvis front-end- og back-end-servere opfører sig forskelligt i forhold til en overførsels-encoding-type header, der muligvis er sløret, kan de være uenige om grænserne mellem successive anmodninger. Dette kan føre til sårbarheder og et HTTP Request Smugling-angreb.

Hvordan man forhindrer dette farlige angreb

HTTP Request Smugling-angreb involverer at placere både Content-Length-headeren og Transfer-Encoding-headeren i den samme HTTP-anmodning og derefter manipulere dem, så front-end- og back-end-serverne behandler anmodningen forskelligt.

Klein, som vi nævnte tidligere, opfordrer til normalisering af udgående HTTP-anmodninger fra proxyservere og fremhæver behovet for en robust og open source webapplikations firewall-løsning, der er i stand til at håndtere disse typer angreb. For at løse dette problem har Klein udgivet et C++-baseret projekt, der vil sikre, at alle indkommende HTTP-anmodninger er fuldt ud gyldige, kompatible og utvetydige. Dette arbejde er udgivet på GitHub, og du kan tjekke det ud her .

På den anden side ville nogle andre ting, vi kunne gøre for at undgå et HTTP-angrebssmugling, være disse:

  • Deaktiver genbrug af back-end-forbindelser, så hver back-end-anmodning sendes gennem en separat netværksforbindelse.
  • Brug HTTP / 2 til back-end-forbindelser, da denne protokol undgår tvetydighed i grænserne mellem anmodninger.
  • Den nøjagtig samme og identiske webserversoftware skal bruges til front-end- og back-end-serverne. Dette sikrer, at de er enige om grænserne mellem anmodninger.

Som du har set, er HTTP Request Smugling-angrebet meget vigtigt på grund af dets alvor, det er ret farligt, men vi har forskellige måder at forhindre dette angreb på og afbøde det korrekt.