Hva er HTTP-parameterkontaminering, og hvorfor er det en reell risiko?

Når vi snakker om sikkerhet for webapplikasjoner, tenker mange bare på SQL-injeksjon, XSS eller autentiseringsfeilI årevis har det imidlertid eksistert en ganske stille teknikk som fortsatt går ubemerket hen i mange revisjoner: HTTP-parameterkontaminering eller forurensning, kjent som HTTP-parameterforurensning (HPP) o HTTP-parameterkontaminering.

Denne typen sårbarhet utnytter hvordan ulike serverteknologier og rammeverk administrerer dupliserte parametere i samme HTTP-forespørselHvis applikasjonen ikke er forberedt på det, kan en angriper endre den interne logikken, omgå valideringer, lure brannmurer for webapplikasjoner (WAF-er) og til og med ta kontroll over kritiske funksjoner som autentisering eller tillatelsesadministrasjon.

Konseptet med HTTP-parametere og prioritet

På så godt som alle moderne nettsteder sender brukere data via HTTP-parametere i URL-en eller i forespørselstekstenDisse parameterne lar nettleseren sende informasjon til applikasjonen: søk, skjemadata, valg i undersøkelser, kommentarer, påloggingsinformasjon osv.

I en typisk GET-forespørsel beveger disse dataene seg i spørrestreng (alt som kommer etter ?-tegnet i URL-en)Nøkkel-/verdipar er atskilt med &-tegnet. I en POST-forespørsel kan de være i brødteksten, men applikasjonslogikken på serveren behandler dem vanligvis veldig likt: nøkler med én eller flere tilknyttede verdier.

Mange programmeringsspråk og rammeverk tilbyr metoder for å oppnå begge deler en enkelt verdi av en parameter som for eksempel den komplette listen over verdier hvis parameteren vises gjentatte ganger. Dette er vanlig, for eksempel med avmerkingsbokser som tillater flere valg, der det samme parameternavnet vises flere ganger.

Problemet oppstår når utvikleren antar at Det vil bare være én verdi per parameter. og bruker funksjoner som returnerer én enkelt verdi, mens nettleseren (eller angriperen) sender flere verdier med samme navn. På dette tidspunktet kommer et nøkkelkonsept inn i bildet: prioritet av verdier.

Avhengig av språk, rammeverk og webserver kan flere forekomster av samme parameter føre til flere virkemåter: at første verdi mottattat han tar siste verdi eller som genereres en kombinasjon av alle (for eksempel sammenkoblet med komma)Det finnes ingen enkelt standard, så hver teknologistabel kan oppføre seg forskjellig, noe som åpner døren for svært farlige situasjoner.

At en funksjon bare returnerer én verdi er ikke en sårbarhet i seg selv, men når det finnes Dupliserte parametere, og utvikleren er ikke klar over det Avhengig av hvordan denne prioriteten fungerer, kan applikasjonen få en uventet verdi. Denne unormale oppførselen er nettopp det teknikker utnytter. HTTP-parameterforurensning.

Hva er HTTP-parameterforurensning (HPP)?

HTTP-parameterforurensning er en teknikk som består av injisere tilleggsparametere eller skilletegn for spørrestrenger (kodet) innenfor andre eksisterende parametere. Når den injiserte parameteren dekodes og brukes på nytt for å generere en ny URL eller for å konstruere en annen forespørsel, vil applikasjonen Det ender opp med å inkludere ekstra parametere som utvikleren ikke forventet..

Med andre ord utnytter HPP måten applikasjonen Den rekonstruerer URL-er, behandler skjemaer og håndterer gjentatte parametere.Hvis inndataene ikke valideres riktig, kan en angriper tvinge applikasjonen til å tolke andre verdier enn de forventede, eller til å inkludere tilleggsparametere i lenker, skjemaer og omdirigeringer.

HPP-teknikker ble offentlig introdusert av Stefano Di Paola og Luca Carettoni på OWASP AppSec 2009-konferansen. Siden den gang har de blitt dokumentert mange angrepsscenarierMen selv i dag har de ikke samme synlighet som andre, bedre kjente sårbarheter, og de er heller ikke fullt ut dekket av alle automatiserte verktøy.

Virkningen av et HTTP Parameter Pollution-angrep avhenger i stor grad av den spesielle logikken i applikasjonenav rammeverket og webserveren. I noen tilfeller er konsekvensene små (presentasjonsfeil, etikettutskriftsfeil osv.), men i andre kan det bety autentiseringsomgåelse, endring av tillatelser eller manipulering av kritiske operasjoner.

For at HPP-sårbarheten virkelig skal kunne utnyttes, må server- eller rammeverksparameterlesingsmekanismen være returnere en annen verdi enn den forventede når den støter på dupliserte parametere. Derfra kan angriperen manipulere denne prioriteten for å styre applikasjonsflyten i sin favør.

Hvordan servere håndterer dupliserte parametere

Det viktigste tekniske elementet som gjør HPP mulig ligger i den ulik oppførselen til de forskjellige webservere og backend-språk når man behandler gjentatte parametere. Ikke alle gjør det samme, og det er nettopp denne variasjonen som gjør at angripere kan finne sårbarheter.

I noen miljøer, hvis vi sender en URL av typen variabel1=verdi1 og variabel1=verdi2serveren vil bare beholde første verdi (val1). I andre tilfeller vil det ta siste verdi mottatt (val2). Og i visse tilfeller, slik det skjer med visse konfigurasjoner av IIS, de to verdiene er sammenkoble internt til en liste, for eksempel atskilt med komma, som applikasjonen deretter må tolke.

Et ofte sitert eksempel er at Apache I standardoppførselen beholder den vanligvis den første verdien av en parameter og forkaster de følgende, mens andre teknologier genererer en CSV-liste (kommaseparerte verdier) med alle verdiene til den forurensede parameteren. Hvis backend-applikasjonen bare er tilpasset ett av disse tilfellene, kan ukontrollerte scenarier forårsake uventede effekter.

Denne håndteringen av dupliserte parametere påvirker ikke bare logikken som er synlig for brukeren, men også interne sikkerhetskontroller, inndatavalidatorer, autentiserings- og autorisasjonsrutinerDen samme parameteren kan kontrolleres på ett punkt i applikasjonen med én verdi, og brukes på et annet punkt med en annen verdi, alt innenfor samme forespørsel.

Videre kan HPP-er brukes til å dra nytte av interne karaktertransformasjoner noe serveren selv gjør. Det er for eksempel dokumentert hvordan noen servere endrer visse spesifikke tegn (som at tegnet "]" erstattes av "_") under behandling, noe som kan brukes til å omgå filtreringsregler eller WAF-firmware basert på regulære uttrykk.

Konsekvenser og utnyttelsesscenarier for HPP

HTTP-parameterforurensningsteknikker tillater generering av et ganske bredt spekter av risikosituasjoner, både på server- og klientsiden. Alvorlighetsgraden avhenger av funksjonen til den berørte parameteren og punktet i applikasjonsflyten der den er endret.

Blant de mest bemerkelsesverdige konsekvensene som er observert i sårbare applikasjoner er overskriving av beskyttede parametereEn angriper kan legge til mer enn én verdi for en kritisk parameter og tvinge applikasjonen til å bruke nøyaktig den skadelige verdien, avhengig av hvordan prioritet fungerer i det spesifikke miljøet.

Det er også vanlig at HPP tillater endring av applikasjonens forventede oppførselFor eksempel ved å endre filtre i interne søkemotorer, endre ressursidentifikatorer, manipulere avstemningsoperasjoner eller variere parametere som kontrollerer forretningslogikk (som administratorflagg, feilsøkingsmoduser eller transaksjonstilstander).

En annen viktig konsekvens er unnvikelse av inputvalideringerHvis sikkerhetsvalideringskoden undersøker den første forekomsten av en parameter, men den faktiske operasjonen utføres med en senere forekomst, kan en angriper omgå tilsynelatende godt implementerte sikkerhetskontroller. Dette har blitt sett i tilfeller av autentisering og omgåelse av tilgangskontroll.

I mer komplekse sammenhenger kan HPP utløse interne applikasjonsfeil, eksponering av sensitiv informasjon, tilgang til variabler utenfor det tiltenkte omfanget og til og med bruken av sammenkoblede parametere som, når de er satt sammen igjen, danner nyttelaster som en WAF ikke oppdaget ved analyse av hver parameter separat.

Når det gjelder virkning, har det blitt observert angrep fra begge sider. server side (omgå WAF, endre URL-omskriving, tvinge frem forskjellige interne ruter) fra og med klientsiden (injeksjon av parametere i lenker og skjemaer for å lure ofre gjennom spesialmanipulerte URL-er).

Klassisk eksempel på HPP i en stemmesøknad

For å bedre forstå hvordan et HTTP Parameter Pollution-angrep fungerer, kan vi se eksemplet på et nettapplikasjon for stemmegivning skrevet i JSPder brukere får stemme på sin favorittkandidat i forskjellige valg.

Applikasjonen mottar gjennom en parameter kalt valg-ID Identifikatoren for det gjeldende valget. Med denne verdien genererer serveren en side som viser de tilgjengelige kandidatene, hver med en lenke for å avgi en stemme. Metoden Request.getParameter("par") I JSP, når flere verdier er tilstede for samme parameter, returneres alltid første verdi.

La oss forestille oss en URL som denne: http://servidor/eleccion.jsp?eleccion_id=4568Den resulterende siden viser en lenke for å stemme på hver kandidat, for eksempel:

1-lenkeJeg stemmer på Mr. White
2-lenkeJeg stemmer på fru Green

La oss anta at en ondsinnet bruker, som støtter en bestemt kandidat, innser at applikasjonen ikke gjør det. validerer choice_id-parameterenVed å utnytte en HPP-sårbarhet bestemmer den seg for å injisere parameteren candi innenfor den choice_id-en, som koder skilletegnene for spørrestrengen.

URL-en den bygger kan være noe sånt som: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenMerk at angriperen har kodet &-tegnet som %26 og =-tegnet som %3D, slik at de etter dekoding blir en ny kandidatparameter innebygd i election_id-verdien.

Når offeret klikker på den manipulerte URL-en, ser det ut til at de får tilgang til riktig valg. Men fordi applikasjonen bruker election_id-verdien til å konstruere stemmelenkene, dekoder den injiserte verdien... Det ender opp med å inkludere en ekstra kandidat i den resulterende spørrestrengen.

Resultatet er at internt genererte lenker blir omtrent slik:

1-lenkeJeg stemmer på Mr. White
2-lenkeJeg stemmer på fru Green

Det spiller ingen rolle hvilken av de to lenkene offeret klikker på: skriptet voting.jsp mottar alltid to forekomster av kandidatparameterender den første verdien er grønn. Siden utvikleren bruker standard Java-funksjonalitet for å hente én enkelt verdi, henter de bare den første verdien fra kandidatparameteren og forkaster den andre, som ville representere brukerens faktiske stemme.

Takket være denne oppførselen lar HPP-sårbarheten angriperen tvinge alle stemmer avgitt på den siden til å gå til kandidaten deresuavhengig av offerets valg i grensesnittet. Dette er et veldig tydelig eksempel på hvordan en angivelig «enkel» parameterhåndtering kan ha en direkte innvirkning på dataintegritet og forretningslogikk.

Autentiseringsomgåelse: Blogger-saken

Et av de mest beryktede eksemplene på utnyttelse av HTTP-parameterforurensning skjedde i bloggsystemet til BloggerEn sårbarhet i parameterhåndteringen tillot angripere tilgang til bli administratorer av andres bloggerganske enkelt ved å manipulere parameterne til en POST-forespørsel.

Den problematiske forespørselen var noe slikt (forenkling av syntaksen):

POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Inviter

Problemet lå i det faktum at autentiserings- og sikkerhetsverifiseringsmekanisme Jeg bare så på første parameter bloggID som kom inn i forespørselen, og bekreftet at brukeren hadde tillatelser over den bloggen. Den faktiske operasjonen som gjesteforfatteren la til, ble imidlertid utført ved hjelp av andre forekomst av bloggID, som tilsvarte offerets blogg.

Takket være denne interne motsetningen, måten serveren håndterte dupliserte parametereAngriperen klarte å bestå sikkerhetskontrollene for sin egen blogg, men utførte handlingen på den andre bloggen. Resultatet var en fullstendig autentiseringsomgåelse med én enkelt velformulert forespørsel.

Denne saken viser veldig godt hvordan HPP ikke bare er en «teknisk kuriositet», men en teknikk med reelle konsekvenser for systemene til store leverandørerVidere fremhever det viktigheten av sikkerhetskontroller og utførelse av operasjoner med nøyaktig de samme parameterverdiene, uten å være avhengig av ukontrollert prioritet.

HPP og webapplikasjonsbrannmur (WAF)

Mange organisasjoner er avhengige av en WAF som et ekstra lag for å beskytte webapplikasjonene sine mot kjente angrep. Disse brannmurene er vanligvis basert på regler og signaturer (regulære uttrykk) som brukes på parameterne, overskriftene og til og med brødteksten i HTTP-forespørsler.

Problemet er at en angriper kan, hvis det finnes dupliserte parametere, fragmenter en ondsinnet nyttelast i flere verdier av samme parameterSelv om WAF analyserer hver parameter separat, er det mulig at ingen av de isolerte verdiene samsvarer med angrepssignaturene, slik at forespørselen passerer filtrene uten å bli blokkert.

Når forespørselen når webserveren, applikasjonsmotoren eller selve serveren setter verdiene sammen på nytt i henhold til sin interne logikk (for eksempel ved å sette dem sammen med komma eller ta den siste), noe som resulterer i en streng som som helhet utgjør angrepet. På denne måten tillater den samme parameterforurensningsteknikken omgå WAF-er som ikke er utstyrt til å analysere det sammenkoblede settet med verdier.

I tillegg fungerer noen WAF-er ikke som omvendt proxy Og de som ikke har fullstendig oversikt over flyten mellom klient og server, men heller fungerer mer som punktfiltre, kan være spesielt sårbare for disse HPP-omgangene. De som er basert på teknologier som Apache med en parametervurderings- og statistisk analysemotor De har en tendens til å oppføre seg bedre i møte med denne typen teknikker.

Kort sagt, HPP viser at selv med en riktig konfigurert WAF, Sikkerhet er ikke garantert Hvis applikasjons- og serverlogikken i seg selv håndterer dupliserte parametere feil, må beskyttelsen være omfattende og ta hensyn til hvordan forespørsler behandles på alle nivåer.

Ekte tilfeller, verktøy og utbredelse av HPP

Akademisk forskning og arbeidet til sikkerhetseksperter har vist at HTTP-parameterforurensning langt fra er sjelden. Prosjekter som PAPAS (PArameter forurensningsanalysesystem), drevet av forskere som Carmen Torrano, ble designet nettopp for å automatisk oppdage HPP-sårbarheter i storskala webapplikasjoner.

I eksperimenter utført på mer enn 5000 svært populære nettsteder (ifølge rangeringer som Alexa), ble det observert at nesten 30 % av nettstedene som ble analysert De inneholdt minst én side som var sårbar for HPP. Det vil si at det var mulig å injisere en kodet parameter i en annen eksisterende og bekrefte at den så ut til å være dekodet i en resulterende URL eller form.

Enda mer oppsiktsvekkende er det at i nærheten av 47 % av sårbarhetene som ble funnet (som tilsvarer omtrent 14 % av det totale antallet nettsteder) var virkelig utnyttbartillot angrep som gikk utover enkle presentasjonsfeil. Blant de berørte nettstedene var Store navn som Microsoft eller GoogleDette gjør det klart at selv ikke teknologigiganter er unntatt fra disse problemene.

Verktøy som PAPAS De har bidratt til å analysere og kvantifisere problemet, men de har også fremhevet vanskeligheten med oppdage HPP automatiskMange tradisjonelle sårbarhetsskannere for nett vurderer ikke scenarier med dupliserte parametere grundig, eller de genererer et veldig høyt volum av falske positiver.

I tillegg til spesifikke løsninger som POTETER, finnes det utvidelser som HPP-søker for Google ChromeDisse verktøyene er utviklet for å oppdage potensielle HPP-angrepsvektorer i URL-er og HTML-skjemaer. Selv om de kan bidra til å identifisere mistenkelige punkter (for eksempel skjemaer som gjenbruker parametere uten skikkelig validering), utgjør de ikke en ikke en komplett løsning eller en erstatning for en grundig sikkerhetsrevisjon.

Et annet verktøy som er mye brukt i økosystemet for sikkerhetstesting er OWASP ZAPsom inkluderer utvidelser og skript for testing av forskjellige vektorer, inkludert de som er relatert til parametere i spørrestrengen. Imidlertid, i det spesifikke tilfellet med HPP, er det fortsatt nødvendig å kombinere automatiserte verktøy med manuell analyse og forståelse av applikasjonsflyten.

HPP i interne søkemotorer og eksempler som Apple.com

HPP-er har ikke bare blitt observert i bloggadministrasjonssystemer eller administrasjonspaneler, de vises også i tilsynelatende uskyldige funksjoner som søkemotorer for tagger i nettfora og -fellesskap. Et slående eksempel ble funnet i Apple-fora, hvor håndteringen av forurensede etiketter og parametere viste merkelig atferd.

I disse forumene ble det lagt til en parameter når man valgte en tag i grensesnittet tags Spørrestrengen i URL-adressen fikk verdien til den valgte taggen. Backend-applikasjonen hentet denne verdien, søkte etter emner med den taggen og viste resultatene til brukeren. Hvis flere tagger ble valgt, ble alle lagt til. i samme tags-parameter, atskilt med addisjonsoperatoren (+)så backend-systemet var klart til å behandle den listen.

Da tags-parameteren var forurenset med flere dupliserte verdier, ble det observert at backend-teknologien genererte en kommaseparert liste (CSV) med alle de forurensede parameterverdiene. Applikasjonen var i stand til å delvis behandle den listen (oppdage de forskjellige taggene), men Den skrev ikke ut alle etikettene riktig. i tekstfeltet i søkemotoren.

I denne spesifikke konteksten så det ikke ut til å være en utnyttbar sikkerhetsfeil, men det var tydelig at Det var scenarier som ikke ble vurdert av utviklerneI andre, mindre uskyldige applikasjoner kan lignende oppførsel føre til avvik mellom hva som er validert, hva som brukes og hva som vises til brukeren, med mer alvorlige konsekvenser.

Analysen av de underliggende teknologiene i fora som Apples (for eksempel Apache med J2EE i backend) viser at mange moderne stakker oppfører seg på samme måte som servere som IIS eller kombinasjoner som Apache med Python når de håndterer forurensede parametere, genererer kommaseparerte lister og delegerer den endelige behandlingen av disse verdiene til applikasjonslogikken.

Denne typen eksempler tjener som en påminnelse om at Det er ikke nok at det «ser ut til å fungere» i normale tilfeller.Du må systematisk teste hvordan applikasjonen reagerer når den får tilsendt dupliserte parametere, merkelig kodede verdier, uvanlige kombinasjoner osv., for det er der HPP finner sin nisje.

Deteksjon og begrensning av HTTP-parameterforurensning

Å oppdage og redusere HPP krever en hybrid tilnærming som kombinerer gode sikre utviklingspraksiser, riktig serverkonfigurasjon og bruk av spesifikke verktøyDet er ikke nok å stole på at WAF fikser alt, for som vi har sett, er det mange ganger nettopp det laget som kan bli lurt.

Fra et utviklingsperspektiv er det viktig at programmerere Vær oppmerksom på at en parameter kan ha flere verdier og de må eksplisitt bestemme hvordan de skal håndtere den saken. De bør ikke stole på standardspråk eller rammeverk uten en grundig forståelse av hvordan verdiprioritet fungerer.

Det anbefales også at man på kritiske punkter, som f.eks. autentisering, autorisasjon, sensitive operasjoner eller viktige tilstandsendringerDet er strengt validert at parametere bare vises én gang, og forespørsler med dupliserte parametere avvises, eller i det minste logges de for analyse.

Når det gjelder infrastruktur, er det lurt å se gjennom webserver- og rammeverkskonfigurasjoner For å forstå nøyaktig hva som skjer når en gjentatt parameter mottas: om den første, den siste eller alle sammenkoblede parametere beholdes. Derfra kan applikasjonslogikken justeres for å unngå avvik mellom validering og den faktiske bruken av verdien.

Når det gjelder verktøy, i tillegg til de vanlige sårbarhetsskannerne, er det nyttig å innlemme målrettede løsninger som f.eks. PAPAS eller utvidelsestype HPP-søker i testflyten. Hvis OWASP ZAP eller andre penetrasjonstestverktøy brukes, er det verdt å designe spesifikke skript som genererer forespørsler med dupliserte parametere og verdier kodet på forskjellige måter for å observere applikasjonens reaksjon.

Til slutt er det viktig å erkjenne at HPP er et problem. mye mer utbredt enn man vanligvis trorDette gjelder spesielt i store applikasjoner med mange års utvikling. Å kombinere opplæring, kodegjennomgang, automatisert testing og godt utformet manuell testing er den beste måten å holde disse feilene under kontroll.

HTTP-parameterkontaminering har med rette fortjent sin plass blant nettangrepsteknikkene som ethvert utviklings- og sikkerhetsteam bør ha på radaren sin: Det er diskret, vanskelig å se med et enkelt blikk på stokkene, og kan ha svært alvorlige konsekvenser. hvis det påvirker viktige parametere i forretningslogikken eller sikkerhetskontrollene. Å forstå hvordan dupliserte parametere håndteres i stakken din, og aktivt teste disse scenariene, er en av de oppgavene som kan virke litt kjedelig i starten, men det utgjør hele forskjellen mellom en rent funksjonell applikasjon og en som er virkelig robust mot avanserte angrep.