Vad är HTTP-parameterkontaminering och varför är det en verklig risk?

När vi pratar om webbapplikationssäkerhet tänker många bara på SQL-injektion, XSS eller autentiseringsfelI åratal har det dock funnits en ganska tyst teknik som fortsätter att gå obemärkt förbi i många revisioner: HTTP-parameterkontaminering eller förorening, så kallad HTTP-parameterförorening (HPP) o HTTP-parameterkontaminering.

Den här typen av sårbarhet utnyttjar hur olika servertekniker och ramverk hanterar duplicerade parametrar i samma HTTP-förfråganOm applikationen inte är förberedd för det kan en angripare ändra den interna logiken, kringgå valideringar, lura webbapplikationsbrandväggar (WAF) och till och med ta kontroll över kritiska funktioner som autentisering eller behörighetshantering.

Begreppet HTTP-parametrar och prioritet

På praktiskt taget alla moderna webbplatser skickar användare data via HTTP-parametrar i URL:en eller i begäranDessa parametrar gör det möjligt för webbläsaren att skicka information till programmet: sökningar, formulärdata, val i enkäter, kommentarer, inloggningsuppgifter etc.

I en typisk GET-förfrågan färdas den datan i frågesträng (allt som kommer efter ?-tecknet i URL:en)Nyckel-/värdepar separeras med et-tecknet (&). I en POST-begäran kan de finnas i brödtexten, men applikationslogiken på servern behandlar dem vanligtvis på ett mycket liknande sätt: nycklar med ett eller flera associerade värden.

Många programmeringsspråk och ramverk erbjuder metoder för att erhålla båda ett enda värde av en parameter såsom den kompletta listan med värden om parametern förekommer upprepade gånger. Detta är vanligt, till exempel med kryssrutor som tillåter flera val, där samma parameternamn förekommer flera gånger.

Problemet uppstår när utvecklaren antar att Det kommer bara att finnas ett värde per parameter. och använder funktioner som returnerar ett enda värde, medan webbläsaren (eller angriparen) skickar flera värden med samma namn. Vid denna tidpunkt kommer ett nyckelbegrepp in i bilden: prioritet av värden.

Beroende på språk, ramverk och webbserver kan flera förekomster av samma parameter resultera i flera beteenden: att första mottagna värdetatt han tar sista värdet eller som genereras en kombination av alla (till exempel sammanfogad med kommatecken)Det finns ingen enskild standard, så varje teknikstack kan bete sig olika, vilket öppnar dörren för mycket farliga situationer.

Att en funktion bara returnerar ett värde är inte en sårbarhet i sig, men när det finns Duplicerade parametrar och utvecklaren är inte medveten om det Beroende på hur den prioriteten fungerar kan applikationen få ett oväntat värde. Det är just detta avvikande beteende som tekniker utnyttjar. HTTP-parameterförorening.

Vad är HTTP-parameterförorening (HPP)?

HTTP-parameterförorening är en teknik som består av injicera ytterligare parametrar eller avgränsare för frågesträngar (kodad) inom andra befintliga parametrar. När den injicerade parametern avkodas och återanvänds för att generera en ny URL eller för att konstruera en annan begäran, applikationen Det slutar med att det innehåller extra parametrar som utvecklaren inte förväntade sig..

Med andra ord utnyttjar HPP hur applikationen Den rekonstruerar URL:er, bearbetar formulär och hanterar upprepade parametrar.Om inmatningen inte valideras korrekt kan en angripare tvinga applikationen att tolka andra värden än de förväntade eller att inkludera ytterligare parametrar i länkar, formulär och omdirigeringar.

HPP-tekniker introducerades offentligt av Stefano Di Paola och Luca Carettoni på OWASP AppSec-konferensen 2009. Sedan dess har de dokumenterats många attackscenarierMen även idag har de inte samma synlighet som andra, mer kända sårbarheter, och de täcks inte heller helt av alla automatiserade verktyg.

Effekten av en HTTP Parameter Pollution-attack beror till stor del på den specifika logiken i applikationenav ramverket och webbservern. I vissa fall är konsekvenserna små (presentationsfel, etikettutskriftsfel etc.), men i andra kan det innebära autentiseringskring, ändring av behörigheter eller manipulation av kritiska operationer.

För att HPP-sårbarheten verkligen ska kunna utnyttjas måste serverns eller ramverkets parameterläsningsmekanism vara returnera ett annat värde än det förväntade när den stöter på dubbletter av parametrar. Därifrån kan angriparen manipulera den prioriteten för att styra applikationsflödet till sin fördel.

Hur servrar hanterar dubbletter av parametrar

Det viktigaste tekniska elementet som gör HPP möjligt ligger i det ojämlika beteendet hos de olika webbservrar och backend-språk vid bearbetning av upprepade parametrar. Alla gör inte samma sak, och det är just den variationen som gör det möjligt för angripare att hitta sårbarheter.

I vissa miljöer, om vi skickar en URL av typen variabel1=värde1 och variabel1=värde2servern kommer bara att behålla första värdet (val1). I andra fall tar det senast mottagna värde (val2). Och i vissa fall, vilket händer med vissa konfigurationer av IIS, de två värdena är sammanfoga internt till en lista, till exempel separerade med kommatecken, som applikationen sedan måste tolka.

Ett vanligt förekommande exempel är att Apache I standardbeteendet behåller den vanligtvis det första värdet på en parameter och ignorerar de följande, medan andra tekniker genererar en CSV-lista (kommaseparerade värden) med alla värden för den förorenade parametern. Om backend-applikationen bara är anpassad till ett av dessa fall kan okontrollerade scenarier orsaka oväntade effekter.

Denna hantering av duplicerade parametrar påverkar inte bara logiken som är synlig för användaren, utan också interna säkerhetskontroller, inmatningsvaliderare, autentiserings- och auktoriseringsrutinerSamma parameter kan kontrolleras vid en punkt i applikationen med ett värde och användas vid en annan punkt med ett annat värde, allt inom samma begäran.

Dessutom kan HPP:er användas för att dra nytta av interna karaktärstransformationer vilket servern själv gör. Det har till exempel dokumenterats hur vissa servrar ändrar vissa specifika tecken (som att tecknet "]" ersätts av "_") under bearbetning, vilket kan användas för att kringgå filtreringsregler eller WAF-firmware baserade på reguljära uttryck.

Konsekvenser och utnyttjandescenarier för HPP

HTTP-parameterföroreningstekniker möjliggör generering av ett ganska brett spektrum av risksituationer, både på server- och klientsidan. Deras allvarlighetsgrad beror på funktion av den berörda parametern och punkten i applikationsflödet i vilket den är ändrad.

Bland de mest anmärkningsvärda konsekvenserna som observerats i sårbara applikationer är överskrivning av skyddade parametrarEn angripare kan lägga till mer än ett värde för en kritisk parameter och tvinga programmet att använda exakt det skadliga värdet tack vare hur prioritet fungerar i den specifika miljön.

Det är också vanligt att HPP tillåter modifiering av applikationens förväntade beteendeTill exempel genom att ändra filter i interna sökmotorer, ändra resursidentifierare, manipulera röstningsoperationer eller variera parametrar som styr affärslogik (t.ex. administratörsflaggor, felsökningslägen eller transaktionstillstånd).

En annan viktig konsekvens är undvikande av inmatningsvalideringarOm säkerhetsvalideringskoden undersöker den första förekomsten av en parameter, men den faktiska operationen utförs med en senare förekomst, kan en angripare kringgå till synes väl implementerade säkerhetskontroller. Detta har observerats i fall av autentisering och kringgå åtkomstkontroll.

I mer komplexa sammanhang kan HPP utlösa interna applikationsfel, exponering av känslig information, åtkomst till variabler utanför det avsedda omfånget och till och med användningen av sammanfogade parametrar som, när de väl är återsatta, bildar nyttolaster som en WAF inte upptäckte när varje parameter analyserades separat.

När det gäller påverkan har attacker observerats från båda sidor. serversidan (kringgå WAF, ändra URL-omskrivning, tvinga fram olika interna rutter) från och med klientsidan (injicering av parametrar i länkar och formulär för att lura offer genom särskilt manipulerade webbadresser).

Klassiskt exempel på HPP i en röstningsapplikation

För att bättre förstå hur en HTTP Parameter Pollution-attack fungerar, exemplet på en röstningswebbapplikation skriven i JSPdär användare får rösta på sin favoritkandidat i olika val.

Applikationen tar emot via en parameter som heter val-id Identifieraren för det aktuella valet. Med detta värde genererar servern en sida som listar tillgängliga kandidater, var och en med en länk för att rösta. Request.getParameter("par") I JSP, när flera värden finns för samma parameter, returneras alltid första värdet.

Låt oss föreställa oss en URL som denna: http://servidor/eleccion.jsp?eleccion_id=4568Den resulterande sidan visar en länk för att rösta på varje kandidat, till exempel:

1-länkJag röstar på Mr. White
2-länkJag röstar på fru Green

Låt oss anta att en illvillig användare, som stöder en viss kandidat, inser att applikationen inte validerar parametern choice_id framgångsriktGenom att utnyttja en HPP-sårbarhet beslutar den att injicera parametern kandidat inom det choice_id, som kodar frågesträngens avgränsare.

URL:en som den skapar kan vara något i stil med: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenObservera att angriparen har kodat &-tecknet som %26 och =-tecknet som %3D, så att de efter avkodning blir en ny kandidatparameter inbäddad i värdet election_id.

När offret klickar på den manipulerade URL:en verkar de få åtkomst till rätt election. Men eftersom applikationen använder election_id-värdet för att konstruera röstningslänkarna, avkodar det injicerade värdet... Det slutar med att det inkluderar en extra kandidat i den resulterande frågesträngen.

Resultatet blir att internt genererade länkar blir ungefär så här:

1-länkJag röstar på Mr. White
2-länkJag röstar på fru Green

Det spelar ingen roll vilken av de två länkarna offret klickar på: skriptet voting.jsp tar alltid emot två instanser av kandidatparameterndär det första värdet är grönt. Eftersom utvecklaren använder standard Java-funktionalitet för att hämta ett enda värde, hämtar de bara det första värdet av kandidatparametern och ignorerar det andra, vilket skulle fånga användarens faktiska röst.

Tack vare detta beteende tillåter HPP-sårbarheten angriparen tvinga alla röster som avges på den sidan att gå till deras kandidatoavsett offrets val i gränssnittet. Detta är ett mycket tydligt exempel på hur en till synes "enkel" parameterhantering kan ha en direkt inverkan på dataintegritet och affärslogik.

Autentiseringskring: Blogger-fallet

Ett av de mest ökända exemplen på utnyttjande av HTTP-parameterföroreningar inträffade i bloggsystemet bloggerEn sårbarhet i parameterhanteringen gjorde det möjligt för angripare att få åtkomst till bli administratörer för andra människors bloggarhelt enkelt genom att manipulera parametrarna för en POST-begäran.

Den problematiska begäran var ungefär så här (förenklad syntax):

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

Problemet låg i det faktum att autentiserings- och säkerhetsverifieringsmekanism Jag tittade bara på första parametern blogg-ID som anlände i begäran, vilket verifierade att användaren hade behörighet över den bloggen. Den faktiska åtgärden som gästförfattaren lade till utfördes dock med hjälp av andra förekomsten av bloggID, vilket motsvarade offrets blogg.

Tack vare denna interna motsägelse, hur servern hanterade duplicerade parametrarAngriparen lyckades klara säkerhetskontrollerna för sin egen blogg men utföra åtgärden på den andra bloggen. Resultatet blev en fullständig kringgåelse av autentisering med en enda välformulerad förfrågan.

Detta fall visar mycket väl hur HPP inte bara är en "teknisk kuriositet", utan en teknik med verkliga effekter på stora leverantörers systemDessutom belyser det vikten av säkerhetskontroller och utförandet av operationer med exakt samma parametervärden, utan att vara beroende av okontrollerad prioritet.

HPP och webbapplikationsbrandvägg (WAF)

Många organisationer förlitar sig på en WAF som ett extra lager för att skydda sina webbapplikationer från kända attacker. Dessa brandväggar är vanligtvis baserade på regler och signaturer (reguljära uttryck) som tillämpas på parametrar, rubriker och till och med brödtexten i HTTP-förfrågningar.

Problemet är att en angripare kan, om det finns dubbletter av parametrar, fragmentera en skadlig nyttolast i flera värden av samma parameterMedan WAF analyserar varje parameter separat är det möjligt att inget av de isolerade värdena matchar attacksignaturerna, så begäran passerar filtren utan att blockeras.

När den begäran når webbservern, applikationsmotorn eller själva servern återställer värdena enligt dess interna logik (till exempel genom att sammanfoga dem med kommatecken eller ta det sista), vilket resulterar i en sträng som, som helhet, utgör attacken. På så sätt tillåter samma parameterföroreningsteknik kringgå WAF:er som inte är utrustade för att analysera den sammanfogade uppsättningen värden.

Dessutom fungerar vissa WAF:er inte som omvänd proxy Och de som inte har en fullständig bild av flödet mellan klient och server, utan snarare fungerar mer som punktfilter, kan vara särskilt sårbara för dessa HPP-förbikopplingar. De som är baserade på tekniker som Apache med en parameterpoängsättnings- och statistisk analysmotor De tenderar att bete sig bättre inför den här typen av tekniker.

Kort sagt visar HPP att även med en korrekt konfigurerad WAF, Säkerheten är inte garanterad Om själva applikations- och serverlogiken hanterar dubbletter av parametrar felaktigt måste skyddet vara omfattande och ta hänsyn till hur förfrågningar behandlas på alla nivåer.

Verkliga fall, verktyg och förekomst av HPP

Akademisk forskning och arbete utfört av säkerhetsexperter har visat att HTTP-parameterföroreningar är långt ifrån ovanliga. Projekt som PAPAS (PArameterföroreningsanalyssystem), drivna av forskare som Carmen Torrano, utformades just för att automatiskt upptäcka HPP-sårbarheter i storskaliga webbapplikationer.

I experiment utförda på mer än 5000 mycket populära webbplatser (enligt rankningar som Alexa) observerades det att nästan 30 % av de analyserade platserna De innehöll minst en sida som var sårbar för HPP. Det vill säga, det var möjligt att injicera en kodad parameter i en annan befintlig och verifiera att den verkade avkodad i någon resulterande URL eller form.

Ännu mer slående är att nära 47 % av de funna sårbarheterna (vilket motsvarar cirka 14 % av det totala antalet platser) var verkligen exploaterbarmöjliggjorde attacker som gick utöver enkla presentationsfel. Bland de drabbade webbplatserna fanns Stora namn som Microsoft eller GoogleDetta gör det tydligt att inte ens teknikjättar är undantagna från dessa problem.

Verktyg som PAPAS De har bidragit till att analysera och kvantifiera problemet, men de har också belyst svårigheten med upptäcka HPP automatisktMånga traditionella webbsårbarhetsskannrar tar inte noggrant hänsyn till scenarier med dubbletter av parametrar, eller så genererar de en mycket hög volym falska positiva resultat.

Förutom specifika lösningar som POTATIS finns det tillägg som HPP-sökare för Google ChromeDessa verktyg är utformade för att upptäcka potentiella HPP-attackvektorer i URL:er och HTML-formulär. Även om de kan hjälpa till att identifiera misstänkta punkter (till exempel formulär som återanvänder parametrar utan korrekt validering), utgör de inte en inte en komplett lösning eller en ersättning för en djupgående säkerhetsrevision.

Ett annat verktyg som används flitigt i ekosystemet för säkerhetstestning är OWASP ZAPvilket inkluderar tillägg och skript för att testa olika vektorer, inklusive de som är relaterade till parametrar i frågesträngen. Men i det specifika fallet med HPP är det fortfarande nödvändigt att kombinera automatiserade verktyg med manuell analys och förståelse av applikationsflödet.

HPP i interna sökmotorer och exempel som Apple.com

HPP:er har inte bara observerats i blogghanteringssystem eller administrationspaneler, de förekommer även i till synes oskyldiga funktioner som taggsökmotorer i onlineforum och -grupper. Ett slående exempel hittades i Apple-forum, där hanteringen av förorenade etiketter och parametrar uppvisade märkliga beteenden.

I dessa forum lades en parameter till när man väljer en tagg i gränssnittet taggar Frågesträngen i URL:en fick värdet för den valda taggen. Backend-applikationen hämtade detta värde, sökte efter ämnen med den taggen och visade resultaten för användaren. Om flera taggar valdes lades alla till. i samma taggarparameter, separerade med additionsoperatorn (+)så backend-systemet var redo att bearbeta den listan.

När taggar-parametern var förorenad med flera duplicerade värden observerades det att backend-tekniken genererade en kommaseparerad lista (CSV) med alla förorenade parametervärden. Applikationen kunde delvis bearbeta den listan (upptäcka de olika taggarna) men Den skrev inte ut alla etiketter korrekt. i sökmotorns textfält.

I detta specifika sammanhang verkade det inte finnas någon säkerhetsbugg som kunde utnyttjas, men det var tydligt att Det fanns scenarier som utvecklarna inte beaktadeI andra, mindre oskyldiga applikationer kan liknande beteende leda till skillnader mellan vad som valideras, vad som används och vad som visas för användaren, med allvarligare konsekvenser.

Analysen av de underliggande teknologierna i forum som Apples (till exempel Apache med J2EE i backend) visar att många moderna stackar beter sig på liknande sätt som servrar som IIS eller kombinationer som Apache med Python när de hanterar förorenade parametrar, genererar kommaseparerade listor och delegerar den slutliga behandlingen av dessa värden till applikationslogiken.

Den här typen av exempel tjänar som en påminnelse om att Det räcker inte att det "verkar fungera" i vanliga fall.Du måste systematiskt testa hur applikationen reagerar när den får dubbletter av parametrar, konstigt kodade värden, ovanliga kombinationer etc., för det är där HPP hittar sin nisch.

Detektion och begränsning av HTTP-parameterföroreningar

Att upptäcka och mildra HPP kräver en hybridmetod som kombinerar goda säkra utvecklingspraxis, korrekt serverkonfiguration och användning av specifika verktygDet räcker inte att förlita sig på att WAF fixar allt, för som vi har sett är det många gånger just det lagret som kan luras.

Ur ett utvecklingsperspektiv är det viktigt att programmerare Var medveten om att en parameter kan ha flera värden och de måste uttryckligen bestämma hur de ska hantera det fallet. De bör inte förlita sig på standardspråk eller ramverksbeteenden utan en grundlig förståelse för hur värdeprioritet fungerar.

Det rekommenderas också att man vid kritiska punkter, som t.ex. autentisering, auktorisering, känsliga åtgärder eller viktiga tillståndsändringarDet är strikt validerat att parametrar bara visas en gång, vilket avvisar förfrågningar med dubbletter av parametrar eller åtminstone loggar dem för analys.

När det gäller infrastruktur är det lämpligt att se över webbserver- och ramverkskonfigurationer För att förstå exakt vad som händer när en upprepad parameter tas emot: om den första, den sista eller alla sammanfogade parametern behålls. Därifrån kan applikationslogiken justeras för att undvika avvikelser mellan validering och den faktiska användningen av värdet.

När det gäller verktyg är det, utöver de vanliga sårbarhetsskannrarna, användbart att införliva riktade lösningar som t.ex. PAPAS eller tilläggstyp HPP-sökare i testflödet. Om OWASP ZAP eller andra penetrationstestverktyg används är det värt att utforma specifika skript som genererar förfrågningar med dubbla parametrar och värden kodade på olika sätt för att observera applikationens reaktion.

Slutligen är det viktigt att erkänna att HPP är ett problem mycket mer utbredd än man allmänt trorDetta gäller särskilt i stora applikationer med många års utveckling. Att kombinera utbildning, kodgranskning, automatiserad testning och väl utformad manuell testning är det bästa sättet att hålla dessa fel under kontroll.

HTTP-parameterkontaminering har med rätta förtjänat sin plats bland de webbattacktekniker som alla utvecklings- och säkerhetsteam bör ha på sin radar: Det är diskret, svårt att se med en enkel blick på stockarna och kan få mycket allvarliga konsekvenser. om det påverkar viktiga parametrar i affärslogiken eller säkerhetskontrollerna. Att förstå hur duplicerade parametrar hanteras i din stack, och att aktivt testa dessa scenarier, är en av de uppgifter som kan verka lite tråkiga till en början, men det gör hela skillnaden mellan en bara funktionell applikation och en som är verkligt robust mot avancerade attacker.