Wat is HTTP-parameterverontreiniging en waarom vormt het een reëel risico?

Als we het over webapplicatiebeveiliging hebben, denken veel mensen alleen aan... SQL-injectie, XSS of authenticatiefoutenEr bestaat echter al jaren een tamelijk stille techniek die bij veel audits onopgemerkt blijft: HTTP-parameterverontreiniging, ook wel bekend als HTTP-parametervervuiling (HPP) o Verontreiniging van HTTP-parameters.

Dit type kwetsbaarheid maakt misbruik van de manier waarop verschillende servertechnologieën en frameworks te werk gaan. dubbele parameters in hetzelfde HTTP-verzoekAls de applicatie er niet op is voorbereid, kan een aanvaller de interne logica wijzigen, validaties omzeilen, webapplicatiefirewalls (WAF's) misleiden en zelfs de controle over cruciale functionaliteiten zoals authenticatie of toegangsbeheer overnemen.

Het concept van HTTP-parameters en hun prioriteit.

Op vrijwel elke moderne website versturen gebruikers gegevens via HTTP-parameters in de URL of in de request bodyDeze parameters stellen de browser in staat om informatie door te geven aan de applicatie: zoekopdrachten, formuliergegevens, enquêteantwoorden, opmerkingen, inloggegevens, enzovoort.

Bij een typische GET-aanvraag worden die gegevens verzonden in de query string (alles wat na het ?-teken in de URL komt)Sleutel/waarde-paren worden gescheiden door het ampersand-symbool (&). In een POST-verzoek kunnen ze in de body staan, maar de applicatielogica op de server behandelt ze meestal op een vergelijkbare manier: sleutels met een of meer bijbehorende waarden.

Veel programmeertalen en frameworks bieden methoden om beide te verkrijgen. een enkele waarde van een parameter zoals de volledige lijst met waarden als die parameter herhaaldelijk voorkomt. Dit is bijvoorbeeld gebruikelijk bij selectievakjes waarmee meerdere selecties mogelijk zijn, waarbij dezelfde parameternaam meerdere keren voorkomt.

Het probleem ontstaat wanneer de ontwikkelaar ervan uitgaat dat Er is slechts één waarde per parameter. en maakt gebruik van functies die één enkele waarde retourneren, terwijl de browser (of de aanvaller) meerdere waarden met dezelfde naam verzendt. Op dit punt komt een belangrijk concept in beeld: voorrang van waarden.

Afhankelijk van de taal, het framework en de webserver kan het meerdere keren voorkomen van dezelfde parameter tot verschillende gedragingen leiden: dat de eerste waarde ontvangendat hij de laatste waarde of dat wordt gegenereerd een combinatie van alles (bijvoorbeeld samengevoegd met komma's)Er bestaat geen eenduidige standaard, waardoor elke technologiestack zich anders kan gedragen, wat de deur opent naar zeer gevaarlijke situaties.

Dat een functie slechts één waarde retourneert, is op zich geen kwetsbaarheid, maar wanneer er sprake is van... Dubbele parameters en de ontwikkelaar is zich daar niet van bewust. Afhankelijk van hoe die prioriteit werkt, kan de applicatie een onverwachte waarde verkrijgen. Dit afwijkende gedrag is precies wat technieken uitbuiten. HTTP-parametervervuiling.

Wat is HTTP-parametervervuiling (HPP)?

HTTP-parametervervuiling is een techniek die bestaat uit extra parameters of query string-scheidingstekens invoegen (gecodeerd) binnen andere bestaande parameters. Wanneer die ingevoegde parameter wordt gedecodeerd en hergebruikt om een ​​nieuwe URL te genereren of een nieuw verzoek samen te stellen, doet de applicatie dat. Het resultaat is dat er extra parameters worden toegevoegd die de ontwikkelaar niet had verwacht..

Met andere woorden, HPP maakt gebruik van de manier waarop de applicatie Het herbouwt URL's, verwerkt formulieren en behandelt herhaalde parameters.Als de invoer niet correct wordt gevalideerd, kan een aanvaller de applicatie dwingen om andere waarden te interpreteren dan verwacht, of om extra parameters op te nemen in links, formulieren en omleidingen.

HPP-technieken werden publiekelijk geïntroduceerd door Stefano Di Paola en Luca Carettoni op de OWASP AppSec 2009-conferentie. Sindsdien zijn ze gedocumenteerd. veel aanvalsscenario'sMaar zelfs nu nog hebben ze niet dezelfde zichtbaarheid als andere, beter bekende kwetsbaarheden, en worden ze ook niet volledig door alle geautomatiseerde tools opgespoord.

De impact van een HTTP-parametervervuilingsaanval hangt grotendeels af van de specifieke logica van de toepassingvan het framework en de webserver. In sommige gevallen zijn de gevolgen gering (weergavefouten, problemen met het afdrukken van labels, enz.), maar in andere gevallen kan het betekenen dat... authenticatie-omzeiling, wijziging van machtigingen of manipulatie van kritieke processen.

Om de HPP-kwetsbaarheid daadwerkelijk te kunnen exploiteren, moet het mechanisme voor het uitlezen van server- of frameworkparameters... retourneert een andere waarde dan de verwachte waarde. wanneer het dubbele parameters tegenkomt. Van daaruit kan de aanvaller die prioriteit manipuleren om de applicatiestroom in zijn of haar voordeel te sturen.

Hoe servers omgaan met dubbele parameters

Het belangrijkste technische element dat HPP mogelijk maakt, ligt in het ongelijke gedrag van de verschillende webservers en backend-talen Bij het verwerken van herhaalde parameters. Niet iedereen doet hetzelfde, en juist die variatie stelt aanvallers in staat om kwetsbaarheden te vinden.

In sommige omgevingen, als we een URL van het type verzenden variabele1=waarde1&variabele1=waarde2de server bewaart alleen de eerste waarde (val1). In andere gevallen zal het de laatst ontvangen waarde (val2). En in bepaalde gevallen, zoals gebeurt bij bepaalde configuraties van IIS, de twee waarden zijn intern samenvoegen tot een lijst, bijvoorbeeld gescheiden door komma's, die de applicatie vervolgens moet interpreteren.

Een veel aangehaald voorbeeld is dat apache In de standaardinstelling behoudt het meestal de eerste waarde van een parameter en negeert de volgende waarden, terwijl andere technologieën een waarde genereren. CSV-lijst (Comma Separated Values) met alle waarden van die vervuilde parameter. Als de backend-applicatie slechts is aangepast aan één van die gevallen, kunnen ongecontroleerde scenario's onverwachte gevolgen hebben.

Deze manier van omgaan met dubbele parameters heeft niet alleen gevolgen voor de logica die de gebruiker ziet, maar ook voor... interne beveiligingscontroles, invoervalidatoren, authenticatie- en autorisatieproceduresDezelfde parameter kan op een bepaald punt in de applicatie met een bepaalde waarde worden gecontroleerd en op een ander punt met een andere waarde worden gebruikt, allemaal binnen hetzelfde verzoek.

Bovendien kunnen HPP's worden gebruikt om te profiteren van interne karaktertransformaties wat de server zelf doet. Het is bijvoorbeeld gedocumenteerd hoe sommige servers bepaalde specifieke tekens wijzigen (zoals het teken "]" dat wordt vervangen door "_") tijdens de verwerking, wat gebruikt kan worden om Het omzeilen van filterregels of WAF-firmware op basis van reguliere expressies..

Gevolgen en exploitatiescenario's van HPP

Technieken voor HTTP-parametervervuiling maken het mogelijk om een ​​vrij breed scala aan risicosituaties te creëren, zowel aan de server- als aan de clientzijde. De ernst hiervan hangt af van de functie van de betreffende parameter en het punt in de applicatiestroom waarin het wordt gewijzigd.

Een van de meest opvallende gevolgen die worden waargenomen bij kwetsbare applicaties is de beveiligde parameters overschrijvenEen aanvaller kan meerdere waarden voor een kritieke parameter invoeren en de applicatie dwingen om precies de kwaadwillige waarde te gebruiken, dankzij de manier waarop prioriteit in die specifieke omgeving werkt.

Het is ook gebruikelijk dat HPP het volgende toestaat: wijziging van het verwachte gedrag van de applicatieBijvoorbeeld door filters in interne zoekmachines te wijzigen, resource-identificaties aan te passen, stemprocessen te manipuleren of parameters te variëren die de bedrijfslogica bepalen (zoals beheerdersvlaggen, debugmodi of transactiestatussen).

Een ander belangrijk gevolg is dat ontwijking van invoervalidatiesAls de beveiligingsvalidatiecode de eerste keer dat een parameter voorkomt controleert, maar de daadwerkelijke bewerking wordt uitgevoerd met een latere keer dat deze voorkomt, kan een aanvaller ogenschijnlijk goed geïmplementeerde beveiligingsmaatregelen omzeilen. Dit is bijvoorbeeld voorgekomen in de volgende gevallen: authenticatie en toegangscontrole omzeilen.

In complexere contexten kan HPP triggeren Interne applicatiefouten, blootstelling van gevoelige informatie, toegang tot variabelen buiten het beoogde bereik en zelfs het gebruik van samengevoegde parameters die, eenmaal opnieuw samengesteld, payloads vormen die een WAF niet detecteerde bij het analyseren van elke parameter afzonderlijk.

Wat de impact betreft, zijn er aanvallen van beide kanten waargenomen. serverzijde (WAF omzeilen, URL-herschrijving wijzigen, andere interne routes afdwingen) vanaf de clientzijde (Het injecteren van parameters in links en formulieren om slachtoffers te misleiden via speciaal gemanipuleerde URL's).

Klassiek voorbeeld van HPP in een stemapplicatie

Om beter te begrijpen hoe een HTTP-parametervervuilingsaanval werkt, volgt hier het voorbeeld van een Stemapplicatie geschreven in JSPwaarbij gebruikers in verschillende verkiezingen op hun favoriete kandidaat kunnen stemmen.

De applicatie ontvangt via een parameter genaamd verkiezing_id De identificatiecode van de huidige verkiezing. Met deze waarde genereert de server een pagina met een lijst van de beschikbare kandidaten, elk met een link om te stemmen. De methode Request.getParameter("pair") In JSP wordt, wanneer er meerdere waarden voor dezelfde parameter aanwezig zijn, altijd de ene waarde geretourneerd. eerste waarde.

Stel je een URL voor zoals deze: http://servidor/eleccion.jsp?eleccion_id=4568De resulterende pagina toont een link om op elke kandidaat te stemmen, bijvoorbeeld:

Verbinding 1Ik stem voor meneer White.
Verbinding 2Ik stem voor mevrouw Green.

Stel dat een kwaadwillende gebruiker, die een bepaalde kandidaat steunt, ontdekt dat de applicatie niet werkt. De parameter choice_id is succesvol gevalideerd.Door gebruik te maken van een HPP-kwetsbaarheid besluit het de parameter te injecteren. kandidaat Binnen die choice_id worden de scheidingstekens van de queryreeks gecodeerd.

De URL die het genereert zou er bijvoorbeeld zo uit kunnen zien: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenMerk op dat de aanvaller het &-symbool heeft gecodeerd als %26 en het =-teken als %3D, zodat ze na decodering een nieuwe kandidaatparameter vormen die is ingebed in de waarde van election_id.

Wanneer het slachtoffer op die gemanipuleerde URL klikt, lijkt hij of zij toegang te krijgen tot de juiste verkiezing. Omdat de applicatie echter de waarde van election_id gebruikt om de stemlinks samen te stellen, is het decoderen van de geïnjecteerde waarde lastig... Het resultaat is dat er een extra kandidaat in de resulterende queryreeks wordt opgenomen..

Het resultaat is dat intern gegenereerde links er ongeveer zo uitzien:

Verbinding 1Ik stem voor meneer White.
Verbinding 2Ik stem voor mevrouw Green.

Het maakt niet uit op welke van de twee links het slachtoffer klikt: het script voting.jsp ontvangt altijd twee instanties van de parameter 'candidate'.waarbij de eerste waarde groen is. Omdat de ontwikkelaar standaard Java-functionaliteit gebruikt om één enkele waarde te verkrijgen, halen ze alleen de eerste waarde uit de parameter 'candidate' en negeren ze de tweede, die de daadwerkelijke stem van de gebruiker zou vertegenwoordigen.

Dankzij dit gedrag stelt de HPP-kwetsbaarheid de aanvaller in staat om alle stemmen die op die pagina worden uitgebracht, dwingen naar hun kandidaat te gaan.ongeacht de keuzes van het slachtoffer in de interface. Dit is een zeer duidelijk voorbeeld van hoe een ogenschijnlijk "eenvoudig" parameterbeheer een directe impact kan hebben op de situatie. gegevensintegriteit en bedrijfslogica.

Authenticatie omzeilen: het geval van Blogger

Een van de meest beruchte voorbeelden van misbruik van HTTP-parametervervuiling deed zich voor in het bloggingsysteem van BloggerEen kwetsbaarheid in de parameterverwerking stelde aanvallers in staat toegang te krijgen tot beheerder worden van de blogs van anderensimpelweg door de parameters van een POST-verzoek te manipuleren.

Het problematische verzoek zag er ongeveer zo uit (de syntaxis is vereenvoudigd):

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

Het probleem lag in het feit dat de authenticatie- en beveiligingsverificatiemechanisme Ik was net aan het kijken naar de eerste parameter blogID dat in het verzoek werd ontvangen, waarmee werd geverifieerd dat de gebruiker toestemming had voor die blog. De daadwerkelijke bewerking die de gastschrijver toevoegde, werd echter uitgevoerd met behulp van de tweede vermelding van blogID, wat overeenkwam met de blog van het slachtoffer.

Dankzij deze interne tegenstrijdigheid verwerkte de server de situatie op een andere manier. dubbele parametersDe aanvaller slaagde erin de beveiligingscontroles voor zijn eigen blog te omzeilen, maar voerde de actie vervolgens uit op de andere blog. Het resultaat was een volledige authenticatie-omzeiling met één goed geformuleerd verzoek.

Deze casus laat heel goed zien dat HPP niet zomaar een "technische curiositeit" is, maar een techniek met concrete gevolgen voor de systemen van grote aanbiedersBovendien benadrukt het het belang van veiligheidscontroles en het uitvoeren van bewerkingen met exact dezelfde parameterwaarden, zonder afhankelijk te zijn van ongecontroleerde voorrangsregels.

HPP en webapplicatie-firewall (WAF)

Veel organisaties vertrouwen op een WAF als extra beveiligingslaag om hun webapplicaties te beschermen tegen bekende aanvallen. Deze firewalls zijn doorgaans gebaseerd op regels en signaturen (reguliere expressies) die worden toegepast op de parameters, headers en zelfs de body van HTTP-verzoeken.

Het probleem is dat een aanvaller, in aanwezigheid van dubbele parameters, Een kwaadaardige payload opsplitsen in meerdere waarden van dezelfde parameter.Hoewel de WAF elke parameter afzonderlijk analyseert, is het mogelijk dat geen van de geïsoleerde waarden overeenkomt met de aanvalspatronen, waardoor het verzoek de filters passeert zonder te worden geblokkeerd.

Zodra dat verzoek de webserver, de applicatie-engine of de server zelf bereikt, herschikt de waarden volgens zijn interne logica. (bijvoorbeeld door ze met komma's samen te voegen of de laatste te nemen), wat resulteert in een tekenreeks die als geheel de aanval vormt. Op deze manier maakt dezelfde parametervervuilingstechniek het mogelijk Omzeil WAF's die niet zijn uitgerust om de samengevoegde reeks waarden te analyseren..

Daarnaast zijn er enkele WAF's die niet functioneren als reverse proxy En systemen die geen volledig overzicht hebben van de communicatie tussen client en server, maar eerder fungeren als puntfilters, kunnen bijzonder kwetsbaar zijn voor deze HPP-omzeilingen. Systemen die gebaseerd zijn op technologieën zoals... Apache met een engine voor parameterbeoordeling en statistische analyse. Ze gedragen zich doorgaans beter in het licht van dit soort technieken.

Kortom, HPP laat zien dat zelfs met een correct geconfigureerde WAF, Veiligheid is niet gegarandeerd. Als de applicatie- en serverlogica zelf onjuist omgaat met dubbele parameters, moet de beveiliging alomvattend zijn en rekening houden met de manier waarop verzoeken op alle niveaus worden verwerkt.

Echte gevallen, instrumenten en prevalentie van HPP

Academisch onderzoek en het werk van beveiligingsexperts hebben aangetoond dat HTTP-parametervervuiling allesbehalve zeldzaam is. Projecten zoals PAPAS (PArameter Pollution Analysis System), gedreven door onderzoekers zoals Carmen Torrano, waren precies ontworpen om HPP-kwetsbaarheden automatisch detecteren in grootschalige webapplicaties.

In experimenten uitgevoerd op meer dan 5000 zeer populaire websites (Volgens ranglijsten zoals die van Alexa) werd geconstateerd dat bijna 30% van de geanalyseerde locaties Ze bevatten minstens één pagina die kwetsbaar was voor HPP. Dat wil zeggen, het was mogelijk om een ​​gecodeerde parameter in een andere bestaande parameter te injecteren en te controleren of deze gedecodeerd in een resulterende URL of formulier verscheen.

Nog opvallender is dat vlakbij de 47% van de gevonden kwetsbaarheden (wat overeenkomt met ongeveer 14% van het totale aantal locaties) waren eigenlijk exploiteerbaarwaardoor aanvallen mogelijk werden die verder gingen dan simpele presentatiefouten. Onder de getroffen sites bevonden zich Grote namen zoals Microsoft of GoogleDit maakt duidelijk dat zelfs techreuzen niet aan deze problemen ontkomen.

Tools zoals PAPA'S Ze hebben bijgedragen aan de analyse en kwantificering van het probleem, maar ze hebben ook de moeilijkheid ervan benadrukt. HPP automatisch detecterenVeel traditionele webkwetsbaarheidsscanners houden onvoldoende rekening met scenario's met dubbele parameters, of ze genereren een zeer groot aantal valse positieven.

Naast specifieke oplossingen zoals POTATOES zijn er ook uitbreidingen zoals HPP Finder voor Google ChromeDeze tools zijn ontworpen om potentiële HPP-aanvalsvectoren in URL's en HTML-formulieren te detecteren. Hoewel ze kunnen helpen bij het identificeren van verdachte punten (bijvoorbeeld formulieren die parameters hergebruiken zonder de juiste validatie), vormen ze geen volledig beschermingsmechanisme. Dit is geen complete oplossing en geen vervanging voor een grondige beveiligingsaudit..

Een ander hulpmiddel dat veelvuldig wordt gebruikt in het ecosysteem voor beveiligingstesten is OWASP ZAPDit omvat extensies en scripts voor het testen van verschillende vectoren, waaronder die gerelateerd aan parameters in de queryreeks. In het specifieke geval van HPP is het echter nog steeds nodig om geautomatiseerde tools te combineren met Handmatige analyse en begrip van de applicatiestroom.

HPP in interne zoekmachines en voorbeelden zoals Apple.com

HPP's zijn niet alleen waargenomen in blogbeheersystemen of beheerderspanelen, ze verschijnen ook in ogenschijnlijk onschuldige functies zoals zoekmachines voor tags in online forums en online communities. Een treffend voorbeeld werd gevonden in de Apple-forums, waar het beheer van vervuilde labels en parameters merkwaardig gedrag vertoonde.

In deze forums werd er een parameter toegevoegd aan het selecteren van een tag in de interface. labels De queryreeks in de URL bevatte de waarde van de gekozen tag. De backend-applicatie haalde deze waarde op, zocht naar onderwerpen met die tag en toonde de resultaten aan de gebruiker. Als er meerdere tags waren geselecteerd, werden deze allemaal toegevoegd. in dezelfde tags-parameter, gescheiden door de plusoperator (+)De backend was dus klaar om die lijst te verwerken.

Toen de parameter 'tags' meerdere dubbele waarden bevatte, bleek dat de backend-technologie een foutmelding genereerde. door komma's gescheiden lijst (CSV) met alle vervuilde parameterwaarden. De applicatie kon die lijst gedeeltelijk verwerken (de verschillende tags ontdekken), maar Niet alle etiketten werden correct afgedrukt. in het tekstveld van de zoekmachine.

In deze specifieke context leek er geen sprake te zijn van een exploiteerbaar beveiligingslek, maar het was duidelijk dat Er waren scenario's waar de ontwikkelaars geen rekening mee hadden gehouden.In andere, minder onschuldige toepassingen zou soortgelijk gedrag kunnen leiden tot discrepanties tussen wat gevalideerd wordt, wat gebruikt wordt en wat aan de gebruiker getoond wordtmet ernstiger gevolgen.

De analyse van de onderliggende technologieën in forums zoals die van Apple (bijvoorbeeld, Apache met J2EE als backend.(Dit laat zien dat veel moderne stacks zich bij het verwerken van vervuilde parameters, waarbij ze door komma's gescheiden lijsten genereren en de uiteindelijke verwerking van die waarden delegeren aan de applicatielogica, vergelijkbaar gedragen als servers zoals IIS of combinaties zoals Apache met Python.)

Dit soort voorbeelden dienen als een herinnering dat Het is niet voldoende dat het in normale gevallen "lijkt te werken".Je moet systematisch testen hoe de applicatie reageert wanneer er dubbele parameters, vreemd gecodeerde waarden, ongebruikelijke combinaties, enzovoort, naartoe worden gestuurd, want dat is waar HPP zijn niche vindt.

Detectie en beperking van HTTP-parametervervuiling

Het opsporen en beperken van HPP vereist een hybride aanpak die verschillende factoren combineert. goede en veilige ontwikkelpraktijken, correcte serverconfiguratie en het gebruik van specifieke tools.Het is niet voldoende om volledig op de WAF te vertrouwen, want zoals we hebben gezien, is het juist die laag die vaak misleid kan worden.

Vanuit een ontwikkelingsperspectief is het essentieel dat programmeurs Houd er rekening mee dat een parameter meerdere waarden kan hebben. En ze moeten expliciet beslissen hoe ze met dat geval omgaan. Ze mogen niet vertrouwen op standaardtaal of frameworkgedrag zonder een grondig begrip van hoe waardeprioriteit werkt.

Het is ook aan te raden om op cruciale momenten zoals authenticatie, autorisatie, gevoelige bewerkingen of belangrijke statuswijzigingenEr wordt strikt gecontroleerd of parameters slechts één keer voorkomen; verzoeken met dubbele parameters worden afgewezen of, op zijn minst, geregistreerd voor analyse.

Wat de infrastructuur betreft, is het raadzaam om de volgende zaken te herzien: webserver- en frameworkconfiguraties Om precies te begrijpen wat er gebeurt wanneer een herhaalde parameter wordt ontvangen: of de eerste, de laatste of alle parameters samen worden behouden. Van daaruit kan de applicatielogica worden aangepast om discrepanties tussen validatie en het daadwerkelijke gebruik van de waarde te voorkomen.

Wat betreft tools is het, naast de gebruikelijke kwetsbaarheidsscanners, nuttig om gerichte oplossingen zoals PAPA'S of extensies type HPP-zoeker in de testflow. Als OWASP ZAP of andere pentestingtools worden gebruikt, is het de moeite waard om specifieke scripts te ontwerpen die genereren verzoeken met dubbele parameters en waarden die op verschillende manieren zijn gecodeerd om de reactie van de applicatie te observeren.

Tot slot is het belangrijk te erkennen dat HPP een probleem is. veel wijdverspreider dan algemeen wordt aangenomen.Dit geldt met name voor grote applicaties die al vele jaren in ontwikkeling zijn. Een combinatie van training, codebeoordeling, geautomatiseerd testen en goed ontworpen handmatige tests is de beste manier om deze fouten onder controle te houden.

HTTP-parameterverontreiniging heeft terecht een plekje verdiend tussen de webaanvaltechnieken die elk ontwikkelings- en beveiligingsteam in de gaten moet houden: Het is discreet, moeilijk te zien met een simpele blik op de logboeken, en kan zeer ernstige gevolgen hebben. als het van invloed is op belangrijke parameters van de bedrijfslogica of beveiligingsmaatregelen. Inzicht in hoe dubbele parameters in uw stack worden verwerkt en het actief testen van deze scenario's is een taak die in eerste instantie misschien wat omslachtig lijkt, maar het maakt een wereld van verschil tussen een louter functionele applicatie en een applicatie die echt bestand is tegen geavanceerde aanvallen.