Når brukere surfer på Internett og utfører ulike oppgaver, er vi utsatt for å motta angrep. Nettkriminelle ser etter sårbarheter og feil i operativsystemene våre for å få fordelene deres. Derfor er det å ha et oppdatert operativsystem og et godt antivirus alltid et godt utgangspunkt å basere forsvaret vårt på. Internett-brukere er imidlertid ikke det eneste målet for nettkriminelle. De utfører også angrep på en webserver, en brannmur, en proxy-server og mer. I dag skal vi snakke om en type angrep som påvirker sistnevnte. I denne opplæringen skal vi snakke om hva HTTP-forespørselssmugling er og vi vil også forklare hvorfor det er så farlig.
Hva gjør dette angrepet og farene
We kan definere et HTTP Request Smugling-angrep som en som utnytter avvikene i analysen når en eller flere HTTP-enheter/enheter er i dataflyten mellom brukeren og webserveren. Vi kommer over en teknikk som forstyrrer måten et nettsted behandler strømmene av HTTP-forespørsler som mottas fra en eller flere brukere.
Disse sårbarhetene er ofte kritiske, og lar nettkriminelle omgå sikkerhetskontroller, få uautorisert tilgang til private data og til og med direkte kompromittere andre brukere av applikasjonen. Denne ulovlige trafikken av HTTP-forespørsler vil tillate ulike angrep som cache-forgiftning, øktkapring og muligheten til å omgå brannmurbeskyttelsen til nettapplikasjoner kan oppnås.
Dette HTTP-forespørselssmuglingsangrepet kan påvirke forskjellige datamaskiner og tjenester:
- Internett server.
- Brannmur.
- Proxy-server.
Når det gjelder opprinnelsen, går det tilbake til 2005 da dette angrepet ble demonstrert av en gruppe Watchfire-forskere, inkludert Klein, Ronen Heled, Chaim Linhart og Steve Orrin. Imidlertid har en rekke forbedringer blitt gjort de siste årene som utvider angrepsoverflaten og gir maksimal rettighetstilgang til interne APIer og cacheforgiftning.
Hvordan dette angrepet skjer
Nettapplikasjoner i dag bruker ofte HTTP-serverstrenger mellom brukere og ultimate applikasjonslogikk. På denne måten sender brukere forespørsler til en front-end-server, og deretter sender front-end-serveren forespørslene til en eller flere back-end-servere. Det bør bemerkes at denne arkitekturen blir hyppigere og i noen tilfeller uunngåelig, for eksempel skybaserte applikasjoner.
Når en front-end-server videresender HTTP-forespørsler til en back-end-server, sender den vanligvis flere forespørsler over samme back-end-nettverkstilkobling. Dette gjøres fordi det er mer effektivt og gir høyere ytelse. Måten å handle på er enkel, først sendes HTTP-forespørslene etter hverandre. Den mottakende serveren analyserer deretter overskriftene til hver HTTP-forespørsel for å bestemme hvor en forespørsel slutter og når den neste begynner.
Et veldig viktig aspekt er at front-end og back-end systemer må bli enige om grensene for forespørslene . Dette er relevant fordi ellers kan en nettkriminell sende en tvetydig forespørsel til front-end- og back-end-systemene, og de kan forstå det annerledes.
Her fører angriperen til at en del av front-end-forespørselen hans tolkes av back-end-serveren som starten på neste forespørsel. Det som skjer da er at det går foran neste forespørsel, noe som forårsaker forstyrrelser i måten søknaden behandler forespørselen på. Vi vil støte på et HTTP-forespørselssmuglingsangrep, og det kan ha katastrofale resultater for eieren av den serveren.
Hvorfor disse angrepene skjer
En stor del av sårbarhetene i HTTP-forespørselssmugling oppstår fordi HTTP-spesifikasjonen gir to forskjellige måter å spesifisere hvor en forespørsel slutter. En header er enkel, den spesifiserer lengden på meldingsteksten i byte. Dette kan brukes til å indikere at brødteksten i meldingen bruker chunk-koding. Dette betyr at brødteksten i meldingen inneholder én eller flere data. Noen sikkerhetsadministratorer er ikke klar over at chunkkryptering kan brukes i HTTP-forespørsler, og dette er et problem.
I tilfelle du ikke vet, tilbyr HTTP to forskjellige metoder for å bestemme lengden på HTTP-meldinger. Det skal også bemerkes at det er mulig for en enkelt melding å bruke begge metodene samtidig, i så fall vil de komme i konflikt med hverandre. HTTP-protokollen prøver å løse dette problemet ved å si at hvis både Content-Length- og Transfer-Encoding-hodene er til stede, bør ikke Content-Length-overskriften brukes. Denne formelen kan være tilstrekkelig for å unngå tvetydighet når vi bare har én aktiv server, men ikke når vi har to eller flere servere lenket.
Derfor, hvis front-end- og back-end-servere oppfører seg annerledes i forhold til en overføringskodingstype-header som muligens er tilslørt, kan de være uenige om grensene mellom påfølgende forespørsler. Dette kan føre til sårbarheter og et HTTP Request Smugling-angrep.
Hvordan forhindre dette farlige angrepet
HTTP Request Smugling-angrep involverer å plassere både Content-Length-headeren og Transfer-Encoding-headeren i samme HTTP-forespørsel, og deretter manipulere dem slik at front-end- og back-end-servere behandler forespørselen annerledes.
Klein, som vi nevnte tidligere, krever normalisering av utgående HTTP-forespørsler fra proxy-servere og fremhever behovet for en robust og åpen kildekode nettapplikasjonsbrannmurløsning som er i stand til å håndtere denne typen angrep. For å løse dette problemet har Klein publisert et C++-basert prosjekt som vil sikre at alle innkommende HTTP-forespørsler er fullt gyldige, kompatible og entydige. Dette verket er publisert på GitHub, og du kan sjekke det ut her. .
På den annen side vil noen andre ting vi kan gjøre for å unngå et HTTP-forespørselssmuglingsangrep være disse:
- Deaktiver gjenbruk av back-end-tilkoblinger, slik at hver back-end-forespørsel sendes gjennom en separat nettverkstilkobling.
- Bruk HTTP / 2 for back-end-tilkoblinger, da denne protokollen unngår tvetydighet i grensene mellom forespørsler.
- Nøyaktig samme og identiske webserverprogramvare må brukes for front-end og back-end servere. Dette sikrer at de blir enige om grensene mellom forespørslene.
Som du har sett, er HTTP Request Smugling-angrepet veldig viktig på grunn av dets alvorlighetsgrad, det er ganske farlig, men vi har forskjellige måter å forhindre dette angrepet på og dempe det på riktig måte.
