Hvad er HTTP-parameterkontaminering, og hvorfor er det en reel risiko?

Når vi taler om webapplikationssikkerhed, tænker mange mennesker kun på SQL-injektion, XSS eller godkendelsesfejlI årevis har der dog eksisteret en temmelig tavs teknik, der fortsat går ubemærket hen i mange revisioner: HTTP-parameterkontaminering eller forurening, kendt som HTTP-parameterforurening (HPP) o HTTP-parameterkontaminering.

Denne type sårbarhed udnytter, hvordan forskellige serverteknologier og frameworks administrerer duplikerede parametre i den samme HTTP-anmodningHvis applikationen ikke er forberedt på det, kan en angriber ændre den interne logik, omgå valideringer, bedrage webapplikationsfirewalls (WAF'er) og endda tage kontrol over kritiske funktioner såsom godkendelse eller tilladelsesadministration.

Konceptet med HTTP-parametre og præcedens

På stort set alle moderne websteder sender brugerne data via HTTP-parametre i URL'en eller i anmodningstekstenDisse parametre giver browseren mulighed for at sende oplysninger til applikationen: søgninger, formulardata, valgmuligheder i undersøgelser, kommentarer, loginoplysninger osv.

I en typisk GET-anmodning bevæger disse data sig i forespørgselsstreng (alt, der kommer efter ?-tegnet i URL'en)Nøgle-/værdipar er adskilt af et &-tegnet. I en POST-anmodning kan de være i brødteksten, men applikationslogikken på serveren behandler dem normalt meget ens: nøgler med en eller flere tilknyttede værdier.

Mange programmeringssprog og frameworks tilbyder metoder til at opnå begge dele en enkelt værdi af en parameter såsom den komplette liste over værdier, hvis den pågældende parameter vises gentagne gange. Dette er almindeligt, for eksempel med afkrydsningsfelter, der tillader flere valg, hvor det samme parameternavn forekommer flere gange.

Problemet opstår, når udvikleren antager, at Der vil kun være én værdi pr. parameter. og bruger funktioner, der returnerer en enkelt værdi, mens browseren (eller angriberen) sender flere værdier med samme navn. På dette tidspunkt kommer et nøglebegreb i spil: værdiernes forrang.

Afhængigt af sprog, framework og webserver kan flere forekomster af den samme parameter resultere i flere forskellige adfærdsmønstre: at første modtagne værdiat han tager sidste værdi eller som genereres en kombination af alle (for eksempel sammenkædet med kommaer)Der findes ingen enkelt standard, så hver teknologistak kan opføre sig forskelligt, hvilket åbner døren for meget farlige situationer.

At en funktion kun returnerer én værdi er ikke en sårbarhed i sig selv, men når der er Duplikerede parametre, og udvikleren er ikke klar over det Afhængigt af hvordan denne præcedens fungerer, kan applikationen opnå en uventet værdi. Denne unormale adfærd er præcis, hvad teknikker udnytter. HTTP-parameterforurening.

Hvad er HTTP-parameterforurening (HPP)?

HTTP-parameterforurening er en teknik, der består af indsæt yderligere parametre eller forespørgselsstrengafgrænsere (kodet) inden for andre eksisterende parametre. Når den indsprøjtede parameter afkodes og genbruges til at generere en ny URL eller til at konstruere en anden anmodning, vil applikationen Det ender med at inkorporere ekstra parametre, som udvikleren ikke havde forventet..

Med andre ord udnytter HPP den måde, hvorpå applikationen Den rekonstruerer URL'er, behandler formularer og håndterer gentagne parametre.Hvis inputtet ikke valideres korrekt, kan en angriber tvinge applikationen til at fortolke andre værdier end de forventede eller til at inkludere yderligere parametre i links, formularer og omdirigeringer.

HPP-teknikker blev offentligt introduceret af Stefano Di Paola og Luca Carettoni på OWASP AppSec 2009-konferencen. Siden da er de blevet dokumenteret mange angrebsscenarierMen selv i dag har de ikke den samme synlighed som andre, bedre kendte sårbarheder, og de er heller ikke fuldt dækket af alle automatiserede værktøjer.

Virkningen af ​​et HTTP Parameter Pollution-angreb afhænger i høj grad af den særlige logik i applikationenaf frameworket og webserveren. I nogle tilfælde er konsekvenserne mindre (præsentationsfejl, fejl i etikettudskrivning osv.), men i andre kan det betyde godkendelsesomgåelse, ændring af tilladelser eller manipulation af kritiske operationer.

For at HPP-sårbarheden reelt kan udnyttes, skal server- eller framework-parameterlæsningsmekanismen være returnere en anden værdi end den forventede når den støder på duplikerede parametre. Derfra kan angriberen manipulere denne præcedens for at styre applikationsflowet i deres favør.

Sådan håndterer servere dublerede parametre

Det centrale tekniske element, der gør HPP mulig, ligger i den ulige adfærd hos de forskellige webservere og backend-sprog når de behandler gentagne parametre. Ikke alle gør det samme, og det er netop den variation, der gør det muligt for angribere at finde sårbarheder.

I nogle miljøer, hvis vi sender en URL af typen variabel1=værdi1 og variabel1=værdi2serveren vil kun gemme første værdi (val1). I andre tilfælde vil det tage sidst modtagne værdi (val2). Og i visse tilfælde, som det sker med visse konfigurationer af IIS, de to værdier er sammenkædning internt til en liste, for eksempel adskilt af kommaer, som applikationen derefter skal fortolke.

Et almindeligt citeret eksempel er, at Apache I standardfunktion beholder den normalt den første værdi af en parameter og kasserer de følgende, mens andre teknologier genererer en CSV-liste (kommaseparerede værdier) med alle værdier for den forurenede parameter. Hvis backend-applikationen kun er tilpasset til ét af disse tilfælde, kan ukontrollerede scenarier forårsage uventede effekter.

Denne håndtering af duplikerede parametre påvirker ikke kun den logik, der er synlig for brugeren, men også interne sikkerhedskontroller, inputvalidatorer, godkendelses- og autorisationsrutinerDen samme parameter kan kontrolleres på ét tidspunkt i applikationen ved hjælp af én værdi og bruges på et andet tidspunkt med en anden værdi, alt sammen inden for den samme anmodning.

Derudover kan HPP'er bruges til at drage fordel af interne karaktertransformationer hvilket serveren selv gør. Det er for eksempel blevet dokumenteret, hvordan nogle servere ændrer bestemte tegn (f.eks. at tegnet "]" erstattes af "_") under behandlingen, hvilket kan bruges til at omgåelse af filtreringsregler eller WAF-firmware baseret på regulære udtryk.

Konsekvenser og udnyttelsesscenarier for HPP

HTTP Parameter Pollution-teknikker muliggør generering af en ret bred vifte af risikosituationer, både på server- og klientsiden. Deres alvorlighed afhænger af funktion af den berørte parameter og punktet i applikationsflowet hvori den er ændret.

Blandt de mest bemærkelsesværdige konsekvenser, der observeres i sårbare applikationer, er overskrivning af beskyttede parametreEn angriber kan tilføje mere end én værdi for en kritisk parameter og tvinge applikationen til at bruge præcis den skadelige værdi takket være, hvordan præcedens fungerer i det specifikke miljø.

Det er også almindeligt, at HPP tillader ændring af applikationens forventede opførselFor eksempel ved at ændre filtre i interne søgemaskiner, ændre ressource-id'er, manipulere afstemningsoperationer eller variere parametre, der styrer forretningslogik (såsom administratorflag, fejlretningstilstande eller transaktionstilstande).

En anden vigtig konsekvens er omgåelse af inputvalideringerHvis sikkerhedsvalideringskoden undersøger den første forekomst af en parameter, men den faktiske handling udføres med en senere forekomst, kan en angriber omgå tilsyneladende velimplementerede sikkerhedskontroller. Dette er set i tilfælde af godkendelse og omgåelse af adgangskontrol.

I mere komplekse sammenhænge kan HPP udløse interne applikationsfejl, eksponering af følsomme oplysninger, adgang til variabler uden for det tilsigtede omfang og endda brugen af ​​sammenkædede parametre, der, når de er samlet igen, danner nyttelast, som en WAF ikke detekterede, når den analyserede hver parameter separat.

Med hensyn til virkning er der observeret angreb fra begge sider. server side (omgåelse af WAF, ændring af URL-omskrivning, gennemtvingning af forskellige interne ruter) fra og med klientsiden (indsprøjtning af parametre i links og formularer for at narre ofre via specielt manipulerede URL'er).

Klassisk eksempel på HPP i en afstemningsapplikation

For bedre at forstå, hvordan et HTTP Parameter Pollution-angreb fungerer, kan eksemplet på et webapplikation til afstemning skrevet i JSPhvor brugerne har mulighed for at stemme på deres foretrukne kandidat ved forskellige valg.

Applikationen modtager via en parameter kaldet valg-id Identifikatoren for det aktuelle valg. Med denne værdi genererer serveren en side, der viser de tilgængelige kandidater, hver med et link til at afgive en stemme. Metoden Request.getParameter("par") I JSP returneres altid , når der er flere værdier til stede for den samme parameter. første værdi.

Lad os forestille os en URL som denne: http://servidor/eleccion.jsp?eleccion_id=4568Den resulterende side viser et link til at stemme på hver kandidat, for eksempel:

1-linkJeg stemmer på hr. White
2-linkJeg stemmer på fru Green

Lad os antage, at en ondsindet bruger, der støtter en bestemt kandidat, indser, at applikationen ikke gør det. validerer parameteren choice_id med succesVed at udnytte en HPP-sårbarhed beslutter den at injicere parameteren Candidato inden for det pågældende choice_id, der koder forespørgselsstrengens afgrænsere.

Den URL, den opbygger, kunne være noget i retning af: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenBemærk, at angriberen har kodet &-tegnet som %26 og =-tegnet som %3D, så de efter afkodning bliver en ny kandidatparameter indlejret i election_id-værdien.

Når offeret klikker på den manipulerede URL, tilsyneladende får de adgang til den korrekte election. Men fordi applikationen bruger election_id-værdien til at konstruere afstemningslinkene, afkoder den indsprøjtede værdi... Det ender med at inkludere en ekstra kandidat i den resulterende forespørgselsstreng.

Resultatet er, at internt genererede links bliver nogenlunde sådan her:

1-linkJeg stemmer på hr. White
2-linkJeg stemmer på fru Green

Det er ligegyldigt hvilket af de to links offeret klikker på: scriptet voting.jsp modtager altid to forekomster af kandidatparameterenhvor den første værdi er grøn. Da udvikleren bruger standard Java-funktionalitet til at opnå en enkelt værdi, får de kun den første værdi af kandidatparameteren og kasserer den anden, hvilket ville registrere brugerens faktiske stemme.

Takket være denne adfærd giver HPP-sårbarheden angriberen mulighed for tving alle stemmer afgivet på den side til at gå til deres kandidatuanset offerets valg i brugerfladen. Dette er et meget tydeligt eksempel på, hvordan en angiveligt "simpel" parameterstyring kan have en direkte indflydelse på dataintegritet og forretningslogik.

Godkendelsesomgåelse: Blogger-sagen

Et af de mest berygtede eksempler på udnyttelse af HTTP-parameterforurening fandt sted i blogsystemet BloggerEn sårbarhed i parameterhåndteringen gjorde det muligt for angribere at få adgang til blive administratorer af andre folks blogsblot ved at manipulere parametrene i en POST-anmodning.

Den problematiske anmodning var nogenlunde sådan her (forenkling af 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 autentificerings- og sikkerhedsverifikationsmekanisme Jeg kiggede bare på første parameter blogID der ankom i anmodningen, der bekræftede, at brugeren havde tilladelser til den blog. Den faktiske handling, som gæsteforfatteren tilføjede, blev dog udført ved hjælp af anden forekomst af blogID, som svarede til offerets blog.

Takket være denne interne modsigelse, den måde serveren håndterede duplikerede parametreAngriberen formåede at bestå sikkerhedskontrollerne for sin egen blog, men udførte handlingen på den anden blog. Resultatet var en fuldstændig omgåelse af godkendelse med en enkelt velformuleret anmodning.

Denne case viser meget godt, hvordan HPP ikke blot er en "teknisk kuriositet", men en teknik med reelle konsekvenser for store udbyderes systemerDesuden fremhæver det vigtigheden af ​​sikkerhedstjek og udførelse af operationer ved hjælp af nøjagtig de samme parameterværdier, uden at være afhængig af ukontrolleret præcedens.

HPP og webapplikationsfirewall (WAF)

Mange organisationer bruger en WAF som et ekstra lag til at beskytte deres webapplikationer mod kendte angreb. Disse firewalls er typisk baseret på regler og signaturer (regulære udtryk) som anvendes på parametrene, headerne og endda selve HTTP-anmodningerne.

Problemet er, at en angriber kan, hvis der er duplikerede parametre, fragmentér en ondsindet nyttelast i flere værdier af den samme parameterSelvom WAF analyserer hver parameter separat, er det muligt, at ingen af ​​de isolerede værdier matcher angrebssignaturerne, så anmodningen passerer filtrene uden at blive blokeret.

Når anmodningen når webserveren, applikationsmotoren eller selve serveren samler værdierne igen i henhold til dens interne logik (for eksempel ved at sammenkæde dem med kommaer eller tage det sidste), hvilket resulterer i en streng, der som helhed udgør angrebet. På denne måde tillader den samme parameterforureningsteknik omgå WAF'er, der ikke er udstyret til at analysere det sammenkædede sæt af værdier.

Derudover fungerer nogle WAF'er ikke som omvendt proxy Og dem, der ikke har et komplet overblik over flowet mellem klient og server, men snarere fungerer mere som punktfiltre, kan være særligt sårbare over for disse HPP-omgåelser. Dem, der er baseret på teknologier som f.eks. Apache med en parameterscoring- og statistisk analysemotor De har en tendens til at opføre sig bedre, når de bliver brugt den slags teknikker.

Kort sagt demonstrerer HPP, at selv med en korrekt konfigureret WAF, Sikkerhed er ikke garanteret Hvis selve applikations- og serverlogikken håndterer dubletter af parametre forkert, skal beskyttelsen være omfattende og tage højde for, hvordan anmodninger behandles på alle niveauer.

Virkelige tilfælde, værktøjer og udbredelse af HPP

Akademisk forskning og sikkerhedseksperters arbejde har vist, at HTTP-parameterforurening langt fra er sjælden. Projekter som f.eks. PAPAS (PArameter-forureningsanalysesystem), drevet af forskere som Carmen Torrano, blev designet netop til at automatisk registrering af HPP-sårbarheder i store webapplikationer.

I forsøg udført på mere end 5000 meget populære hjemmesider (ifølge ranglister som Alexa) blev det observeret, at næsten 30% af de analyserede steder De indeholdt mindst én side, der var sårbar over for HPP. Det vil sige, at det var muligt at indsætte en kodet parameter i en anden eksisterende og verificere, at den så ud til at være dekodet i en resulterende URL eller form.

Endnu mere slående er det, at der er tæt på 47% af de fundne sårbarheder (hvilket svarer til omkring 14% af det samlede antal steder) var virkelig udnytteligtillod angreb, der gik ud over simple præsentationsfejl. Blandt de berørte websteder var Store navne som Microsoft eller GoogleDette gør det klart, at selv ikke tech-giganter er fritaget for disse problemer.

Værktøjer som PAPAS De har bidraget til at analysere og kvantificere problemet, men de har også fremhævet vanskeligheden ved detekter HPP automatiskMange traditionelle websårbarhedsscannere overvejer ikke scenarier med duplikerede parametre grundigt, eller de genererer et meget højt antal falske positiver.

Udover specifikke løsninger som KARTOFLER, er der udvidelser som HPP-finder til Google ChromeDisse værktøjer er designet til at detektere potentielle HPP-angrebsvektorer i URL'er og HTML-formularer. Selvom de kan hjælpe med at identificere mistænkelige punkter (f.eks. formularer, der genbruger parametre uden korrekt validering), udgør de ikke en ikke en komplet løsning eller en erstatning for en dybdegående sikkerhedsrevision.

Et andet værktøj, der er meget udbredt i økosystemet for sikkerhedstestning, er OWASP ZAPsom inkluderer udvidelser og scripts til test af forskellige vektorer, herunder dem, der er relateret til parametre i forespørgselsstrengen. I det specifikke tilfælde af HPP er det dog stadig nødvendigt at kombinere automatiserede værktøjer med manuel analyse og forståelse af applikationsflowet.

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

HPP'er er ikke kun blevet observeret i blogstyringssystemer eller administrationspaneler, de optræder også i tilsyneladende uskadelige funktioner såsom tag-søgemaskiner i onlinefora og -fællesskaber. Et slående eksempel blev fundet i Apple-fora, hvor håndteringen af ​​forurenede etiketter og parametre viste besynderlig adfærd.

I disse fora blev der tilføjet en parameter ved at vælge et tag i brugerfladen tags Forespørgselsstrengen i URL'en fik overført værdien af ​​det valgte tag. Backend-applikationen hentede denne værdi, søgte efter emner med det pågældende tag og viste resultaterne for brugeren. Hvis flere tags blev valgt, blev de alle tilføjet. i den samme tags-parameter, adskilt af additionsoperatoren (+)så backend'en var klar til at behandle den liste.

Da tags-parameteren var forurenet med flere duplikerede værdier, blev det observeret, at backend-teknologien genererede en kommasepareret liste (CSV) med alle de forurenede parameterværdier. Applikationen var i stand til delvist at behandle denne liste (opdage de forskellige tags), men Den udskrev ikke alle etiketterne korrekt. i søgemaskinens tekstfelt.

I denne specifikke kontekst syntes der ikke at være en sikkerhedsfejl, der kunne udnyttes, men det var tydeligt, at Der var scenarier, som udviklerne ikke havde taget højde forI andre, mindre uskyldige applikationer kan lignende adfærd føre til uoverensstemmelser mellem hvad der er valideret, hvad der bruges, og hvad der vises til brugeren, med mere alvorlige konsekvenser.

Analysen af ​​de underliggende teknologier i fora som Apples (for eksempel Apache med J2EE i backend) viser, at mange moderne stakke opfører sig på samme måde som servere som IIS eller kombinationer som Apache med Python, når de håndterer forurenede parametre, genererer kommaseparerede lister og delegerer den endelige behandling af disse værdier til applikationslogikken.

Denne type eksempler tjener som en påmindelse om, at Det er ikke nok, at det "ser ud til at virke" i normale tilfælde.Du skal systematisk teste, hvordan applikationen reagerer, når den får tilsendt duplikerede parametre, mærkeligt kodede værdier, usædvanlige kombinationer osv., for det er her, HPP finder sin niche.

Detektion og afhjælpning af HTTP-parameterforurening

Detektion og afbødning af HPP kræver en hybrid tilgang, der kombinerer gode sikre udviklingspraksisser, korrekt serverkonfiguration og brug af specifikke værktøjerDet er ikke nok at stole på, at WAF løser alt, for som vi har set, er det mange gange netop det lag, der kan bedrages.

Fra et udviklingsperspektiv er det vigtigt, at programmører Vær opmærksom på, at en parameter kan have flere værdier og de skal eksplicit beslutte, hvordan de skal håndtere den sag. De bør ikke stole på standardsprog eller rammeadfærd uden en grundig forståelse af, hvordan værdiprioritet fungerer.

Det anbefales også, at man på kritiske punkter, som f.eks. godkendelse, autorisation, følsomme handlinger eller vigtige tilstandsændringerDet er strengt valideret, at parametre kun vises én gang, hvilket afviser anmodninger med dubletter af parametre eller i det mindste logger dem til analyse.

Med hensyn til infrastruktur er det tilrådeligt at gennemgå webserver- og frameworkkonfigurationer For at forstå præcis, hvad der sker, når en gentaget parameter modtages: om den første, den sidste eller alle sammenkædede bevares. Derfra kan applikationslogikken justeres for at undgå uoverensstemmelser mellem validering og den faktiske brug af værdien.

Med hensyn til værktøjer er det, udover de sædvanlige sårbarhedsscannere, nyttigt at inkorporere målrettede løsninger som f.eks. PAPAS eller udvidelsestype HPP-finder i testflowet. Hvis OWASP ZAP eller andre pentestværktøjer anvendes, er det værd at designe specifikke scripts, der genererer anmodninger med duplikerede parametre og værdier kodet på forskellige måder at observere applikationens reaktion.

Endelig er det vigtigt at erkende, at HPP er et problem meget mere udbredt end man almindeligvis trorDette gælder især i store applikationer med mange års udvikling. Kombination af træning, kodegennemgang, automatiseret testning og veldesignet manuel testning er den bedste måde at holde disse fejl under kontrol.

HTTP-parameterkontaminering har med rette fortjent sin plads blandt de webangrebsteknikker, som ethvert udviklings- og sikkerhedsteam bør have på radaren: Det er diskret, svært at se med et simpelt blik på træstammerne, og kan have meget alvorlige konsekvenser. hvis det påvirker nøgleparametre i forretningslogikken eller sikkerhedskontrollerne. At forstå, hvordan duplikerede parametre håndteres i din stak, og aktivt teste disse scenarier, er en af ​​de opgaver, der måske virker lidt kedelig i starten, men det gør hele forskellen mellem en blot funktionel applikation og en, der er virkelig robust over for avancerede angreb.