Kaj je kontaminacija parametrov HTTP in zakaj predstavlja resnično tveganje?

Ko govorimo o varnosti spletnih aplikacij, mnogi ljudje pomislijo le na Napake pri vbrizgavanju SQL-a, XSS-ju ali preverjanju pristnostiVendar pa že leta obstaja precej tiha tehnika, ki v mnogih revizijah ostaja neopažena: kontaminacija ali onesnaževanje parametrov HTTP, znano kot Onesnaževanje parametrov HTTP (HPP) o Kontaminacija parametrov HTTP.

Ta vrsta ranljivosti izkorišča, kako različne strežniške tehnologije in ogrodja upravljajo podvojeni parametri v isti zahtevi HTTPČe aplikacija na to ni pripravljena, lahko napadalec spremeni notranjo logiko, zaobide preverjanja veljavnosti, prevara požarne zidove spletnih aplikacij (WAF) in celo prevzame nadzor nad kritičnimi funkcijami, kot sta preverjanje pristnosti ali upravljanje dovoljenj.

Koncept parametrov HTTP in prednostnih nalog

Na praktično vsaki sodobni spletni strani uporabniki pošiljajo podatke prek Parametri HTTP v URL-ju ali v telesu zahteveTi parametri omogočajo brskalniku, da aplikaciji posreduje informacije: iskanja, podatke obrazcev, izbire anket, komentarje, prijavne podatke itd.

V tipični zahtevi GET ti podatki potujejo v niz poizvedbe (vse, kar sledi znaku ? v URL-ju)Pari ključ/vrednost so ločeni s simbolom & (&). V zahtevi POST so lahko v telesu, vendar jih logika aplikacije na strežniku običajno obravnava zelo podobno: ključi z eno ali več povezanimi vrednostmi.

Številni programski jeziki in ogrodja ponujajo metode za pridobitev obeh ena sama vrednost parametra na primer celoten seznam vrednosti, če se ta parameter pojavlja večkrat. To je običajno na primer pri potrditvena polja, ki omogočajo več izbir, kjer se isto ime parametra pojavi večkrat.

Težava nastane, ko razvijalec predpostavlja, da Vsak parameter bo imel samo eno vrednost. in uporablja funkcije, ki vrnejo eno samo vrednost, medtem ko brskalnik (ali napadalec) pošlje več vrednosti z istim imenom. Na tej točki pride v poštev ključni koncept: prednost vrednot.

Glede na jezik, ogrodje in spletni strežnik lahko večkratna pojavitev istega parametra povzroči več vedenj: da prva prejeta vrednostda on vzame zadnja vrednost ali ki je ustvarjen kombinacija vseh (na primer združenih z vejicami)Ni enotnega standarda, zato se lahko vsak tehnološki sklad obnaša drugače, kar odpira vrata zelo nevarnim situacijam.

To, da funkcija vrne samo eno vrednost, samo po sebi ni ranljivost, ampak kadar obstaja Podvojeni parametri in razvijalec se tega ne zaveda Glede na to, kako deluje ta prednost, lahko aplikacija pridobi nepričakovano vrednost. Prav to nenavadno vedenje tehnike izkoriščajo. Onesnaženje parametrov HTTP.

Kaj je onesnaževanje parametrov HTTP (HPP)?

Polemika parametrov HTTP je tehnika, ki je sestavljena iz vstavite dodatne parametre ali ločila nizov poizvedb (kodirano) znotraj drugih obstoječih parametrov. Ko je ta vbrizgani parameter dekodiran in ponovno uporabljen za generiranje novega URL-ja ali za izdelavo druge zahteve, aplikacija Na koncu vključi dodatne parametre, ki jih razvijalec ni pričakoval..

Z drugimi besedami, HPP izkorišča način, kako aplikacija Rekonstruira URL-je, obdeluje obrazce in obravnava ponavljajoče se parametre.Če vnos ni pravilno potrjen, lahko napadalec prisili aplikacijo, da interpretira vrednosti, ki niso pričakovane, ali da v povezave, obrazce in preusmeritve vključi dodatne parametre.

Tehnike hidroelektrarn so bile javno predstavljene s strani Stefano Di Paola in Luca Carettoni na konferenci OWASP AppSec 2009. Od takrat so bili dokumentirani veliko scenarijev napadovA tudi danes nimajo enake prepoznavnosti kot druge, bolj znane ranljivosti, niti jih vsa avtomatizirana orodja v celoti ne pokrivajo.

Vpliv napada HTTP Parameter Pollution je v veliki meri odvisen od posebna logika aplikacijeogrodja in spletnega strežnika. V nekaterih primerih so posledice manjše (napake pri predstavitvi, napake pri tiskanju etiket itd.), v drugih pa lahko pomenijo obhod overjanja, spreminjanje dovoljenj ali manipulacija kritičnih operacij.

Da bi bila ranljivost HPP resnično izkoriščena, mora biti mehanizem za branje parametrov strežnika ali ogrodja vrniti vrednost, ki ni pričakovana ko naleti na podvojene parametre. Od tam lahko napadalec manipulira s to prednostjo, da usmeri potek aplikacije v svojo korist.

Kako strežniki obravnavajo podvojene parametre

Ključni tehnični element, ki omogoča HPP, leži v neenakem vedenju različnih spletni strežniki in jeziki za zaledne programe pri obdelavi ponavljajočih se parametrov. Vsi ne počnejo iste stvari in prav ta raznolikost napadalcem omogoča, da najdejo ranljivosti.

V nekaterih okoljih, če pošljemo URL vrste spremenljivka1=vrednost1&spremenljivka1=vrednost2strežnik bo obdržal samo prva vrednost (val1). V drugih primerih bo trajalo zadnja prejeta vrednost (val2). In v nekaterih primerih, kot se zgodi pri določenih konfiguracijah IIS, obe vrednosti sta združiti interno v seznam, na primer ločene z vejicami, ki jih bo morala aplikacija nato interpretirati.

Pogosto naveden primer je, da Apache V privzetem načinu delovanja običajno ohrani prvo vrednost parametra in zavrže naslednje, medtem ko druge tehnologije ustvarijo Seznam CSV (vrednosti, ločene z vejicami) z vsemi vrednostmi tega onesnaženega parametra. Če je zaledna aplikacija prilagojena le enemu od teh primerov, lahko nenadzorovani scenariji povzročijo nepričakovane učinke.

To ravnanje s podvojenimi parametri ne vpliva le na logiko, ki jo vidi uporabnik, ampak tudi notranji varnostni mehanizmi, validatorji vnosa, rutine za preverjanje pristnosti in avtorizacijoIsti parameter je mogoče v aplikaciji na eni točki preveriti z eno vrednostjo, na drugi pa z drugo vrednostjo, vse znotraj iste zahteve.

Poleg tega se lahko hidroelektrarne uporabljajo za izkoriščanje notranje preobrazbe značaja kar stori sam strežnik. Dokumentirano je bilo na primer, kako nekateri strežniki med obdelavo spremenijo določene specifične znake (na primer znak "]" zamenjajo z "_"), kar se lahko uporabi za izogibanje pravilom filtriranja ali vdelanim programom WAF na podlagi regularnih izrazov.

Posledice in scenariji izkoriščanja HE

Tehnike onesnaževanja parametrov HTTP omogočajo ustvarjanje precej širokega nabora tveganih situacij, tako na strani strežnika kot odjemalca. Njihova resnost je odvisna od funkcija prizadetega parametra in točka v poteku aplikacije v katerem je spremenjen.

Med najbolj opaznimi posledicami, opaženimi pri ranljivih aplikacijah, so prepisovanje zaščitenih parametrovNapadalec lahko kritičnemu parametru doda več kot eno vrednost in aplikacijo prisili, da uporabi natančno zlonamerno vrednost, zaradi načina delovanja prednostnih nalog v tem specifičnem okolju.

Prav tako je običajno, da HE omogočajo sprememba pričakovanega vedenja aplikacijeNa primer s spreminjanjem filtrov v internih iskalnikih, spreminjanjem identifikatorjev virov, manipuliranjem glasovalnih operacij ali spreminjanjem parametrov, ki nadzorujejo poslovno logiko (kot so skrbniške zastavice, načini odpravljanja napak ali stanja transakcij).

Druga pomembna posledica je izogibanje validacijam vnosovČe koda za varnostno preverjanje preveri prvo pojavitev parametra, dejanska operacija pa se izvede s poznejšo pojavitvijo, lahko napadalec zaobide na videz dobro implementirane varnostne kontrole. To se je pokazalo v primerih obhod avtentikacije in nadzora dostopa.

V bolj zapletenih kontekstih lahko HPP sproži notranje napake aplikacije, izpostavljenost občutljivih informacij, dostop do spremenljivk zunaj predvidenega obsega in celo uporaba združenih parametrov, ki po ponovni sestavi tvorijo koristne tovore, ki jih WAF ni zaznal pri analizi vsakega parametra posebej.

Kar zadeva vpliv, so bili napadi opaženi z obeh strani. strani strežnika (obilazak WAF-a, spreminjanje prepisovanja URL-jev, vsiljevanje različnih notranjih poti) od stran odjemalca (vbrizgavanje parametrov v povezave in obrazce za zavajanje žrtev prek posebej prirejenih URL-jev).

Klasičen primer HPP v volilni aplikaciji

Za boljše razumevanje delovanja napada HTTP Parameter Pollution si oglejmo primer spletna aplikacija za glasovanje, napisana v JSP-jukjer lahko uporabniki glasujejo za svojega najljubšega kandidata na različnih volitvah.

Aplikacija prejme prek parametra, imenovanega volilna_id Identifikator trenutnih volitev. S to vrednostjo strežnik ustvari stran s seznamom razpoložljivih kandidatov, vsak s povezavo za oddajo glasovanja. Metoda Zahteva.getParameter("par") V JSP-ju, ko je za isti parameter prisotnih več vrednosti, vedno vrne prva vrednost.

Predstavljajmo si URL, kot je ta: http://servidor/eleccion.jsp?eleccion_id=4568Na strani, ki se prikaže, se prikaže povezava za glasovanje za vsakega kandidata, na primer:

Povezava 1Glasujem za gospoda Whitea
Povezava 2Glasujem za gospo Green.

Recimo, da zlonamerni uporabnik, ki podpira določenega kandidata, ugotovi, da aplikacija tega ne uspešno potrdi parameter choice_idIzkoristi ranljivost HPP in se odloči vbrizgati parameter Kandidat znotraj tega choice_id, ki kodira ločila poizvedbenega niza.

URL, ki ga ustvari, bi lahko bil nekaj takega: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenUpoštevajte, da je napadalec simbol & kodiral kot %26 in znak = kot %3D, tako da po dekodiranju postaneta nov parameter kandidata, vdelan v vrednost election_id.

Ko žrtev klikne na ta spremenjeni URL, se zdi, da dostopa do pravilnih volitev. Ker pa aplikacija uporablja vrednost election_id za izdelavo povezav za glasovanje in dekodira vbrizgano vrednost ... Na koncu v nastali niz poizvedbe vključi dodatnega kandidata..

Rezultat je, da interno ustvarjene povezave postanejo nekaj takega:

Povezava 1Glasujem za gospoda Whitea
Povezava 2Glasujem za gospo Green.

Ni pomembno, na katero od obeh povezav žrtev klikne: skript voting.js vedno prejme dva primerka parametra candidatekjer je prva vrednost zelena. Ker razvijalec uporablja standardno funkcionalnost Jave za pridobitev ene same vrednosti, iz parametra kandidata dobi le prvo vrednost in zavrže drugo, ki bi predstavljala dejanski glas uporabnika.

Zaradi tega vedenja ranljivost HPP napadalcu omogoča prisiliti vse glasove, oddane na tej strani, da gredo njihovemu kandidatune glede na izbire žrtve v vmesniku. To je zelo jasen primer, kako lahko domnevno "preprosto" upravljanje parametrov neposredno vpliva na integriteta podatkov in poslovna logika.

Obhod avtentikacije: primer Bloggerja

Eden najbolj razvpitih primerov izkoriščanja onesnaževanja parametrov HTTP se je zgodil v blogerskem sistemu BloggerRanljivost pri obdelavi parametrov je napadalcem omogočila dostop do postati skrbniki blogov drugih ljudipreprosto z manipulacijo parametrov zahteve POST.

Problematična zahteva je bila nekako takšna (poenostavljena sintaksa):

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

Težava je bila v dejstvu, da je mehanizem za preverjanje pristnosti in varnost Ravno sem gledal/a prvi parameter blogID ki je prispela v zahtevi in ​​potrdila, da ima uporabnik dovoljenja za ta blog. Vendar pa je bila dejanska operacija, ki jo je dodal gostujoči avtor, izvedena z uporabo druga pojavitev blogID-ja, kar je ustrezalo blogu žrtve.

Zaradi tega notranjega protislovja je način, kako je strežnik obravnaval podvojeni parametriNapadalcu je uspelo prestati varnostna preverjanja za svoj blog, vendar je dejanje izvedel na drugem blogu. Rezultat je bil popoln obhod overjanja z eno samo dobro sestavljeno zahtevo.

Ta primer zelo dobro prikazuje, kako HPP ni le »tehnična zanimivost«, temveč tehnika z resnični vplivi na sisteme velikih ponudnikovPoleg tega poudarja pomen varnostnih pregledov in izvajanja operacij z uporabo popolnoma enakih vrednosti parametrov, brez odvisnosti od nenadzorovane prednosti.

HPP in požarni zid spletnih aplikacij (WAF)

Številne organizacije se zanašajo na WAF kot dodatno plast za zaščito svojih spletnih aplikacij pred znanimi napadi. ​​Ti požarni zidovi običajno temeljijo na pravila in podpisi (regularni izrazi) ki se uporabljajo za parametre, glave in celo telo zahtev HTTP.

Težava je v tem, da lahko napadalec ob prisotnosti podvojenih parametrov razdrobiti zlonamerno koristno vsebino na več vrednosti istega parametraČeprav WAF analizira vsak parameter posebej, je možno, da se nobena od izoliranih vrednosti ne ujema z napadalnimi podpisi, zato zahteva preide skozi filtre, ne da bi bila blokirana.

Ko ta zahteva doseže spletni strežnik, aplikacijski mehanizem ali sam strežnik ponovno sestavi vrednosti v skladu s svojo notranjo logiko (na primer tako, da jih združimo z vejicami ali vzamemo zadnjega), kar ima za posledico niz, ki kot celota predstavlja napad. Na ta način ista tehnika onesnaževanja parametrov omogoča obiti WAF-e, ki niso opremljeni za analizo združenega nabora vrednosti.

Poleg tega nekateri WAF-ji, ki ne delujejo kot obratni proxy In tisti, ki nimajo popolnega pregleda nad tokom med odjemalcem in strežnikom, temveč delujejo bolj kot točkovni filtri, so lahko še posebej ranljivi za te obvoze HPP. Tisti, ki temeljijo na tehnologijah, kot so Apache z mehanizmom za točkovanje parametrov in statistično analizo Ponavadi se bolje obnašajo ob soočanju s tovrstnimi tehnikami.

Skratka, HPP dokazuje, da tudi s pravilno konfiguriranim WAF-om, Varnost ni zagotovljena Če sama logika aplikacije in strežnika napačno obravnava podvojene parametre, mora biti zaščita celovita in upoštevati, kako se zahteve obdelujejo na vseh ravneh.

Resnični primeri, orodja in razširjenost HPP

Akademske raziskave in delo varnostnih strokovnjakov so pokazali, da onesnaževanje parametrov HTTP še zdaleč ni redko. Projekti, kot so PAPAS (sistem za analizo onesnaženosti s parametri), ki so jih vodili raziskovalci, kot je Carmen Torrano, so bili zasnovani prav zato, da samodejno zaznavanje ranljivosti HPP v obsežnih spletnih aplikacijah.

V poskusih, izvedenih na več kot 5000 zelo priljubljenih spletnih mest (glede na lestvice, kot je Alexa), je bilo ugotovljeno, da skoraj 30 % analiziranih spletnih mest Vsebovali so vsaj eno stran, ranljivo za HPP. To pomeni, da je bilo mogoče vstaviti kodiran parameter v drug obstoječi parameter in preveriti, ali se je dekodiran pojavil v nekem nastalem URL-ju ali obliki.

Še bolj presenetljivo je, da je blizu 47 % najdenih ranljivosti (kar ustreza približno 14 % vseh lokacij) so bile resnično izkoriščenkar je omogočilo napade, ki so presegli preproste pomanjkljivosti v predstavitvi. Med prizadetimi spletnimi mesti so bila Velika imena, kot sta Microsoft ali GoogleTo jasno kaže, da niti tehnološki velikani niso izvzeti iz teh težav.

Orodja kot PAPAS Služili so za analizo in kvantifikacijo problema, hkrati pa so poudarili tudi težavnost samodejno zazna HPPMnogi tradicionalni spletni skenerji ranljivosti ne upoštevajo temeljito scenarijev s podvojenimi parametri ali pa ustvarijo zelo veliko število lažno pozitivnih rezultatov.

Poleg specifičnih rešitev, kot je KROMPIR, obstajajo tudi razširitve, kot so Iskalnik HPP za Google ChromeTa orodja so zasnovana za odkrivanje potencialnih vektorjev napadov HPP v URL-jih in obrazcih HTML. Čeprav lahko pomagajo prepoznati sumljive točke (na primer obrazce, ki ponovno uporabljajo parametre brez ustrezne validacije), ne predstavljajo ni celovita rešitev niti nadomestilo za poglobljen varnostni pregled.

Drugo orodje, ki se pogosto uporablja v ekosistemu varnostnega testiranja, je OWASP ZAPki vključuje razširitve in skripte za testiranje različnih vektorjev, vključno s tistimi, ki so povezani s parametri v poizvedbenem nizu. Vendar pa je v specifičnem primeru HPP še vedno treba kombinirati avtomatizirana orodja z ročna analiza in razumevanje poteka aplikacije.

HPP v internih iskalnikih in primerih, kot je Apple.com

HPP-ji niso bili opaženi le v sistemih za upravljanje blogov ali administratorskih ploščah, temveč se pojavljajo tudi v na videz neškodljive funkcije, kot so iskalniki oznak na spletnih forumih in skupnostih. Presenetljiv primer je bil najden v Apple forumi, kjer je upravljanje onesnaženih oznak in parametrov pokazalo nenavadno vedenje.

Na teh forumih je izbira oznake v vmesniku dodala parameter oznake Nizu poizvedbe v URL-ju je bila posredovana vrednost izbrane oznake. Aplikacija v ozadju je pridobila to vrednost, poiskala teme s to oznako in uporabniku prikazala rezultate. Če je bilo izbranih več oznak, so bile dodane vse. v istem parametru oznak, ločenih z operatorjem seštevanja (+)tako je bil zaledni sistem pripravljen za obdelavo tega seznama.

Ko je bil parameter tags onesnažen z več podvojenimi vrednostmi, je bilo ugotovljeno, da je tehnologija zaledja ustvarila seznam, ločen z vejicami (CSV) z vsemi onesnaženimi vrednostmi parametrov. Aplikacija je ta seznam lahko delno obdelala (odkrila različne oznake), vendar Vse nalepke niso bile pravilno natisnjene. v besedilnem polju iskalnika.

V tem specifičnem kontekstu se ni zdelo, da bi obstajala izkoriščevalna varnostna napaka, vendar je bilo jasno, da Obstajali so scenariji, ki jih razvijalci niso upoštevaliV drugih, manj nedolžnih aplikacijah lahko podobno vedenje privede do neskladja med tem, kaj je potrjeno, kaj se uporablja in kaj je prikazano uporabniku, z resnejšimi posledicami.

Analiza osnovnih tehnologij na forumih, kot je Applov (na primer Apache z J2EE v ozadju) kaže, da se številni sodobni skladi obnašajo podobno kot strežniki, kot je IIS, ali kombinacije, kot je Apache s Pythonom, pri obravnavanju onesnaženih parametrov, ustvarjanju seznamov, ločenih z vejicami, in prenosu končne obdelave teh vrednosti na logiko aplikacije.

Takšni primeri služijo kot opomnik, da V normalnih primerih ni dovolj, da "navidezno deluje".Sistematično morate preizkusiti, kako se aplikacija odzove, ko ji pošljete podvojene parametre, čudno kodirane vrednosti, nenavadne kombinacije itd., saj prav tam HPP najde svojo nišo.

Zaznavanje in ublažitev onesnaženja parametrov HTTP

Odkrivanje in blaženje HPP zahteva hibridni pristop, ki združuje dobre prakse varnega razvoja, pravilna konfiguracija strežnika in uporaba specifičnih orodijNi dovolj, da se zanašamo na to, da bo WAF popravil vse, saj, kot smo videli, je velikokrat mogoče prevarati prav to plast.

Z razvojnega vidika je bistveno, da programerji Upoštevajte, da ima lahko parameter več vrednosti in se morajo izrecno odločiti, kako bodo ta primer obravnavali. Ne smejo se zanašati na privzeti jezik ali vedenje ogrodja brez temeljitega razumevanja delovanja prednostnih vrednosti.

Priporočljivo je tudi, da se na kritičnih točkah, kot so preverjanje pristnosti, avtorizacija, občutljive operacije ali pomembne spremembe stanjaStrogo je potrjeno, da se parametri pojavijo samo enkrat, zahteve s podvojenimi parametri pa se zavrnejo ali vsaj shranijo za analizo.

Kar zadeva infrastrukturo, je priporočljivo pregledati konfiguracije spletnega strežnika in ogrodja Da bi natančno razumeli, kaj se zgodi, ko je prejet ponovljen parameter: ali se ohrani prvi, zadnji ali vsi združeni. Na podlagi tega je mogoče prilagoditi logiko aplikacije, da se izognemo neskladjem med validacijo in dejansko uporabo vrednosti.

Kar zadeva orodja, je poleg običajnih skenerjev ranljivosti koristno vključiti tudi ciljno usmerjene rešitve, kot so PAPAS ali vrsto razširitev Iskalnik HE v testnem toku. Če se uporablja OWASP ZAP ali druga orodja za testiranje vdorov, je smiselno oblikovati posebne skripte, ki generirajo zahteve s podvojenimi parametri in vrednostmi, kodiranimi na različne načine opazovati reakcijo aplikacije.

Nenazadnje je pomembno priznati, da je hidroelektrarna problem veliko bolj razširjena, kot se običajno misliTo še posebej velja za velike aplikacije z dolgoletnimi izkušnjami na področju razvoja. Kombinacija učenja, pregleda kode, avtomatiziranega testiranja in dobro zasnovanega ročnega testiranja je najboljši način za nadzor nad temi napakami.

Kontaminacija parametrov HTTP si je upravičeno prislužila mesto med tehnikami spletnih napadov, ki bi jih morala imeti na radarju vsaka razvojna in varnostna ekipa: Je diskreten, težko ga je videti s preprostim pogledom na hlode in ima lahko zelo resne posledice. če vpliva na ključne parametre poslovne logike ali varnostnih kontrol. Razumevanje, kako se v vašem skladu obravnavajo podvojeni parametri, in aktivno testiranje teh scenarijev je ena tistih nalog, ki se na začetku morda zdi nekoliko dolgočasna, vendar naredi vso razliko med zgolj funkcionalno aplikacijo in aplikacijo, ki je resnično robustna proti naprednim napadom.