Mis on HTTP parameetrite saastumine ja miks see on reaalne oht?

Veebirakenduste turvalisusest rääkides mõtlevad paljud inimesed ainult sellele, SQL-i süstimise, XSS-i või autentimise tõrkedSiiski on aastaid olnud üsna vaikne tehnika, mis jääb paljudes auditites märkamatuks: HTTP-parameetrite saastumine ehk reostus, mida tuntakse kui HTTP parameetrite reostus (HPP) o HTTP parameetrite saastumine.

Seda tüüpi haavatavus kasutab ära seda, kuidas erinevad serveritehnoloogiad ja raamistikud haldavad dubleeritud parameetrid samas HTTP-päringusKui rakendus pole selleks valmis, saab ründaja muuta sisemist loogikat, mööda hiilida valideerimistest, petta veebirakenduste tulemüüre (WAF) ja isegi võtta kontrolli kriitiliste funktsioonide, näiteks autentimise või lubade haldamise üle.

HTTP-parameetrite ja eelistuse mõiste

Peaaegu igal tänapäevasel veebisaidil saadavad kasutajad andmeid läbi HTTP-parameetrid URL-is või päringu sisusNeed parameetrid võimaldavad brauseril edastada rakendusele teavet: otsingud, vormiandmed, küsitluse valikud, kommentaarid, sisselogimisandmed jne.

Tüüpilises GET-päringus liiguvad need andmed päringustring (kõik, mis URL-is pärast ?-märki tuleb)Võtme/väärtuse paarid eraldatakse ampersandi (&) sümboliga. POST-päringus võivad need olla küll päringu sisus, kuid serveri rakendusloogika käsitleb neid tavaliselt väga sarnaselt: ühe või mitme seotud väärtusega võtmed.

Paljud programmeerimiskeeled ja raamistikud pakuvad meetodeid mõlema saamiseks parameetri üksik väärtus näiteks täielik väärtuste loend, kui see parameeter esineb korduvalt. See on tavaline näiteks märkeruudud, mis võimaldavad mitut valikut, kus sama parameetri nimi esineb mitu korda.

Probleem tekib siis, kui arendaja eeldab, et Parameetri kohta on ainult üks väärtus. ja kasutab funktsioone, mis tagastavad ühe väärtuse, samal ajal kui brauser (või ründaja) saadab mitu sama nimega väärtust. Siinkohal tuleb mängu üks võtmekontseptsioon: väärtuste eelistus.

Sõltuvalt keelest, raamistikust ja veebiserverist võib sama parameetri mitmekordne esinemine põhjustada mitmeid käitumishäireid: esimene saadud väärtuset ta võtab viimane väärtus või mis on genereeritud kõigi kombinatsioon (näiteks komadega liidetud)Ühtset standardit pole, seega võib iga tehnoloogiapakk käituda erinevalt, mis avab ukse väga ohtlikele olukordadele.

See, et funktsioon tagastab ainult ühe väärtuse, ei ole iseenesest haavatavus, aga kui see on olemas Duplikaatparameetrid ja arendaja pole sellest teadlik Sõltuvalt sellest, kuidas see eelistus toimib, võib rakendus saada ootamatu väärtuse. Just seda anomaalset käitumist need tehnikad ära kasutavadki. HTTP parameetrite reostus.

Mis on HTTP parameetrite reostus (HPP)?

HTTP parameetrite reostus on tehnika, mis koosneb järgmisest: sisestage täiendavaid parameetreid või päringustringi eraldajaid (kodeeritud) teiste olemasolevate parameetrite sees. Kui see sisestatud parameeter dekodeeritakse ja taaskasutatakse uue URL-i genereerimiseks või uue päringu koostamiseks, siis rakendus See lisab lõpuks lisaparameetreid, mida arendaja ei oodanud..

Teisisõnu, HPP kasutab ära viisi, kuidas rakendus See rekonstrueerib URL-id, töötleb vorme ja käsitleb korduvaid parameetreid.Kui sisendit ei ole korralikult valideeritud, saab ründaja sundida rakendust tõlgendama oodatust erinevaid väärtusi või lisama linkidesse, vormidesse ja ümbersuunamistesse täiendavaid parameetreid.

HPP-tehnikaid tutvustas avalikult Stefano Di Paola ja Luca Carettoni OWASP AppSec 2009 konverentsil. Sellest ajast alates on neid dokumenteeritud palju rünnakustsenaariumeKuid isegi tänapäeval pole neil sama nähtavust kui teistel, tuntumatel haavatavustel ega ole need täielikult kaetud kõigi automatiseeritud tööriistadega.

HTTP parameetrite reostuse rünnaku mõju sõltub suuresti rakenduse konkreetne loogikaraamistiku ja veebiserveri. Mõnel juhul on tagajärjed väikesed (esitlusvead, siltide printimise tõrked jne), kuid teistel juhtudel võib see tähendada autentimise möödahiilimine, õiguste muutmine või kriitiliste toimingute manipuleerimine.

Selleks, et HPP haavatavust saaks tõeliselt ära kasutada, peab serveri või raamistiku parameetrite lugemise mehhanism olema tagastab oodatust erineva väärtuse kui see kohtab duplikaatparameetreid. Sealt edasi saab ründaja seda eelistust manipuleerida, et rakenduse voogu enda kasuks suunata.

Kuidas serverid duplikaatparameetreid käsitlevad

Peamine tehniline element, mis HPP-d võimalikuks teeb, peitub erinevate ebavõrdses käitumises. veebiserverid ja taustkeeled korduvate parameetrite töötlemisel. Kõik ei tee sama asja ja just see mitmekesisus võimaldab ründajatel haavatavusi leida.

Mõnes keskkonnas, kui saadame URL-i tüübi järgi muutuja1=väärtus1&muutuja1=väärtus2server hoiab alles ainult esimene väärtus (väärtus1). Teistes riikides võtab see viimane saadud väärtus (val2). Ja teatud juhtudel, nagu juhtub teatud konfiguratsioonidega IIS, on need kaks väärtust sisemiselt loendiks liitma, näiteks komadega eraldatuna, mida rakendus peab seejärel tõlgendama.

Sageli viidatud näide on see, et Apache Vaikimisi hoiab see tavaliselt parameetri esimest väärtust ja loobub järgmistest, samas kui teised tehnoloogiad genereerivad CSV (komaga eraldatud väärtused) loend kõigi selle saastunud parameetri väärtustega. Kui taustrakendust kohandatakse ainult ühele neist juhtudest, võivad kontrollimatud stsenaariumid põhjustada ootamatuid tagajärgi.

Duplikaatparameetrite käsitlemine mõjutab mitte ainult kasutajale nähtavat loogikat, vaid ka sisemised turvakontrollid, sisendvalideerijad, autentimis- ja autoriseerimisrutiinidSama parameetrit saab rakenduses ühes punktis kontrollida ühe väärtusega ja teises punktis kasutada erineva väärtusega, kõik sama päringu piires.

Lisaks saab HPP-sid kasutada selleks, et ära kasutada sisemised iseloomu muutused mida server ise teeb. Näiteks on dokumenteeritud, kuidas mõned serverid töötlemise ajal teatud märke (näiteks märgi "]" asendamine märgiga "_") muudavad, mida saab kasutada selleks, et regulaaravaldistel põhinevate filtreerimisreeglite või WAF-püsivarade vältimine.

HPP tagajärjed ja ekspluateerimise stsenaariumid

HTTP parameetrite reostuse tehnikad võimaldavad genereerida üsna laia valikut riskisituatsioone nii serveri kui ka kliendi poolel. Nende raskusaste sõltub mõjutatud parameetri funktsioon ja punkt rakendusvoos milles seda muudetakse.

Haavatavate rakenduste puhul on kõige märkimisväärsemate tagajärgede hulgas kaitstud parameetrite ülekirjutamineRündaja saab kriitilisele parameetrile lisada mitu väärtust ja sundida rakendust kasutama täpselt pahatahtlikku väärtust tänu sellele, kuidas eelistus selles konkreetses keskkonnas töötab.

Samuti on tavaline, et HPP lubab rakenduse oodatava käitumise muutmineNäiteks sisemiste otsingumootorite filtrite muutmise, ressursiidentifikaatorite muutmise, hääletustoimingute manipuleerimise või äriloogikat juhtivate parameetrite (nt administraatori lipud, silumisrežiimid või tehingute olekud) varieerimise teel.

Teine oluline tagajärg on sisendvalideerimise vältimineKui turvalisuse valideerimise kood uurib parameetri esimest esinemist, kuid tegelik toiming tehakse hilisema esinemisega, saab ründaja mööda hiilida näiliselt hästi rakendatud turvakontrollidest. Seda on nähtud juhtudel, kus autentimine ja juurdepääsukontrolli möödaviik.

Keerukamates olukordades võib HPP käivitada sisemised rakendusvead, tundliku teabe avalikustamine, juurdepääs muutujatele väljaspool kavandatud ulatust ja isegi liidetud parameetrite kasutamine, mis pärast uuesti kokkupanekut moodustavad kasulikke koormusi, mida WAF iga parameetri eraldi analüüsimisel ei tuvastanud.

Mõju osas on rünnakuid täheldatud mõlemalt poolt. serveri poolel (WAF-ist mööda minek, URL-i ümberkirjutamise muutmine, erinevate sisemiste marsruutide sundimine) alates kliendi pool (parameetrite süstimine linkidesse ja vormidesse ohvrite petmiseks spetsiaalselt manipuleeritud URL-ide abil).

Klassikaline näide HPP-st hääletusrakenduses

HTTP parameetrite reostuse rünnaku toimimise paremaks mõistmiseks toome näite a JSP-s kirjutatud hääletusveebirakenduskus kasutajad saavad erinevatel valimistel hääletada oma lemmikkandidaadi poolt.

Rakendus saab parameetri nimega kaudu valimise_id Praeguse valimise identifikaator. Selle väärtusega genereerib server lehe, kus on loetletud saadaolevad kandidaadid, igaühel neist on link hääletamiseks. Meetod Request.getParameter("paar") JSP-s tagastatakse alati sama parameetri mitme väärtuse korral esimene väärtus.

Kujutame ette sellist URL-i: http://servidor/eleccion.jsp?eleccion_id=4568Tulemuseks olev leht kuvab lingi iga kandidaadi poolt hääletamiseks, näiteks:

1 linkMa hääletan hr White'i poolt
2 linkMa hääletan proua Greeni poolt

Oletame, et pahatahtlik kasutaja, kes toetab konkreetset kandidaati, saab aru, et rakendus seda ei tee. valideerib edukalt parameetri choice_idHPP haavatavust ära kasutades otsustab see parameetri süstida kandidaat selle choice_id sees, kodeerides päringustringi eraldajaid.

Selle loodud URL võiks olla midagi sellist: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenPane tähele, et ründaja on kodeerinud sümboli & kui %26 ja märgi = kui %3D, nii et pärast dekodeerimist muutuvad need uueks kandidaatparameetriks, mis on manustatud election_id väärtuse sisse.

Kui ohver klõpsab sellel manipuleeritud URL-il, pääseb ta näiliselt ligi õigele valikule. Kuna rakendus aga kasutab hääletuslinkide loomiseks election_id väärtust, dekodeerib sisestatud väärtuse... Lõpuks lisatakse saadud päringustringi täiendav kandidaat.

Tulemuseks on, et sisemiselt genereeritud lingid muutuvad millekski selliseks:

1 linkMa hääletan hr White'i poolt
2 linkMa hääletan proua Greeni poolt

Pole vahet, kummal kahest lingist ohver klõpsab: skriptil voting.jsp saab alati kaks kandidaadi parameetri eksemplarikus esimene väärtus on roheline. Kuna arendaja kasutab ühe väärtuse saamiseks Java standardfunktsionaalsust, saavad nad kandidaadiparameetrist ainult esimese väärtuse ja hülgavad teise, mis jäädvustaks kasutaja tegeliku hääle.

Tänu sellele käitumisele võimaldab HPP haavatavus ründajal sunnib kõik sellel lehel antud hääled minema tema kandidaadileolenemata ohvri valikutest liideses. See on väga selge näide sellest, kuidas väidetavalt "lihtne" parameetrite haldamine võib otseselt mõjutada andmete terviklikkus ja äriloogika.

Autentimise möödaviik: Bloggeri juhtum

Üks kurikuulsamaid HTTP parameetrite reostuse ärakasutamise näiteid leidis aset blogimissüsteemis BloggerParameetrite käsitlemise haavatavus võimaldas ründajatel pääseda ligi saada teiste inimeste blogide administraatoritekslihtsalt POST-päringu parameetreid muutes.

Probleemne päring oli midagi sellist (süntaksi lihtsustamine):

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

Probleem seisnes selles, et autentimise ja turvalisuse kontrollimise mehhanism Ma lihtsalt vaatasin seda esimene parameeter blogi ID mis saabus päringuga, kinnitades, et kasutajal on selle ajaveebi üle õigused. Külalisautori lisatud toiming tehti aga tegeliku toimingu abil blogiID teine ​​esinemine, mis vastas ohvri blogile.

Tänu sellele sisemisele vastuolule serveri käitus erinevalt. duplikaatparameetridRündajal õnnestus läbida oma blogi turvakontroll, kuid ta sooritas toimingu teisel blogil. Tulemuseks oli täielik autentimise möödaviik üheainsa hästi sõnastatud palvega.

See juhtum näitab väga hästi, kuidas HPP ei ole lihtsalt „tehniline kurioosum“, vaid tehnika, millel on reaalne mõju suurte teenusepakkujate süsteemideleLisaks rõhutab see turvakontrollide ja toimingute teostamise olulisust täpselt samade parameetriväärtuste abil, ilma et see sõltuks kontrollimatust eelistusest.

HPP ja veebirakenduste tulemüür (WAF)

Paljud organisatsioonid toetuvad WAF-ile täiendava kihina oma veebirakenduste kaitsmiseks teadaolevate rünnakute eest. Need tulemüürid põhinevad tavaliselt järgmisel: reeglid ja signatuurid (regulaaravaldised) mida rakendatakse HTTP-päringute parameetritele, päistele ja isegi sisule.

Probleem on selles, et dubleeritud parameetrite olemasolul saab ründaja fragmenteeri pahatahtlik koormus sama parameetri mitmeks väärtuseksKuigi WAF analüüsib iga parameetrit eraldi, on võimalik, et ükski isoleeritud väärtustest ei vasta rünnaku signatuuridele, seega läbib päring filtrid blokeerimata.

Kui see päring jõuab veebiserverisse, rakendusmootorisse või serverisse endasse paneb väärtused uuesti kokku vastavalt oma sisemisele loogikale (näiteks komadega liites või viimast võttes), mille tulemuseks on string, mis tervikuna moodustab rünnaku. Sel viisil võimaldab sama parameetrite reostuse tehnika mööda hiilida WAF-idest, mis ei ole varustatud liidetud väärtuste komplekti analüüsimiseks.

Lisaks mõned WAF-id, mis ei toimi nii pöördproksi Ja need, kellel puudub täielik ülevaade kliendi ja serveri vahelisest andmevoost, vaid kes toimivad pigem punktfiltritena, võivad olla nende HPP möödaviikude suhtes eriti haavatavad. Need, mis põhinevad sellistel tehnoloogiatel nagu Apache parameetrite hindamise ja statistilise analüüsi mootoriga Nad kipuvad seda tüüpi tehnikate ees paremini käituma.

Lühidalt, HPP näitab, et isegi õigesti konfigureeritud WAF-i korral Ohutus pole garanteeritud Kui rakenduse ja serveri loogika ise käsitleb duplikaatparameetreid valesti, peab kaitse olema põhjalik ja arvestama sellega, kuidas päringuid kõigil tasanditel töödeldakse.

HPP tegelikud juhtumid, tööriistad ja levimus

Akadeemilised uuringud ja turvaekspertide töö on näidanud, et HTTP parameetrite reostus pole kaugeltki haruldane. Sellised projektid nagu PAPAS (parameetrite saaste analüüsi süsteem), mida juhtisid teadlased nagu Carmen Torrano, olid loodud just selleks, et tuvastab HPP haavatavused automaatselt suuremahulistes veebirakendustes.

Katsetes, mis viidi läbi enam kui 5000 väga populaarset veebisaiti (vastavalt edetabelitele nagu Alexa) täheldati, et peaaegu 30% analüüsitud saitidest Need sisaldasid vähemalt ühte HPP suhtes haavatavat lehte. See tähendab, et kodeeritud parameetri oli võimalik sisestada teise olemasolevasse lehte ja kontrollida, kas see ilmus dekodeerituna mõnes saadud URL-is või vormis.

Veelgi silmatorkavam on see, et lähedal 47% leitud haavatavustest (mis moodustab umbes 14% saitide koguarvust) olid tõesti ärakasutatavvõimaldades rünnakuid, mis ületasid lihtsaid esitlusvigu. Mõjutatud saitide hulgas olid Suured nimed nagu Microsoft või GoogleSee teeb selgeks, et isegi tehnoloogiahiiglased pole nendest probleemidest vabastatud.

Tööriistad nagu PAPAS Need on aidanud probleemi analüüsida ja kvantifitseerida, aga on ka toonud esile raskuse tuvastab HPP automaatseltPaljud traditsioonilised veebihaavatavuse skannerid ei arvesta duplikaatparameetrite stsenaariumidega põhjalikult või genereerivad väga suure hulga valepositiivseid tulemusi.

Lisaks spetsiifilistele lahendustele nagu KARTULID on olemas ka laiendusi nagu HPP Finder Google Chrome'i jaoksNeed tööriistad on loodud URL-ides ja HTML-vormides võimalike HPP-rünnakute tuvastamiseks. Kuigi need aitavad tuvastada kahtlaseid punkte (näiteks vorme, mis taaskasutavad parameetreid ilma korraliku valideerimiseta), ei kujuta need endast... mitte täielik lahendus ega asenda põhjalikku turvaauditit.

Teine turvatestimise ökosüsteemis laialdaselt kasutatav tööriist on OWASP ZAPmis hõlmab laiendusi ja skripte erinevate vektorite testimiseks, sealhulgas päringustringi parameetritega seotud vektorite testimiseks. HPP konkreetsel juhul on siiski vaja kombineerida automatiseeritud tööriistu rakendusvoo käsitsi analüüs ja mõistmine.

HPP sisemistes otsingumootorites ja näidetes nagu Apple.com

HPP-sid pole täheldatud mitte ainult ajaveebide haldussüsteemides või administreerimispaneelides, vaid need ilmuvad ka pealtnäha süütud funktsioonid, näiteks siltide otsingumootorid veebifoorumites ja kogukondades. Silmatorkav näide leiti ... Apple'i foorumid, kus saastunud siltide ja parameetrite haldamine näitas uudishimulikku käitumist.

Nendes foorumites lisas liideses sildi valimine parameetri silte URL-i päringustringile edastati valitud sildi väärtus. Tagarakendus hankis selle väärtuse, otsis selle sildiga teemasid ja kuvas tulemused kasutajale. Kui valitud oli mitu silti, lisati need kõik. samas sildi parameetris, eraldatuna liitmisoperaatoriga (+)seega oli taustprogramm selle nimekirja töötlemiseks valmis.

Kui siltide parameeter oli saastunud mitme duplikaatväärtusega, täheldati, et tausttehnoloogia genereeris komaga eraldatud loend (CSV) kõigi saastunud parameetrite väärtustega. Rakendus suutis seda loendit osaliselt töödelda (tuvastada erinevaid silte), aga See ei prindinud kõiki silte õigesti. otsingumootori tekstiväljal.

Selles konkreetses kontekstis ei paistnud olevat ärakasutatavat turvaviga, kuid oli selge, et Arendajad ei arvestanud stsenaariumidegaTeistes, vähem süütutes rakendustes võib sarnane käitumine viia lahknevused valideeritu, kasutatava ja kasutajale kuvatava vahel, tõsisemate tagajärgedega.

Alustehnoloogiate analüüs sellistes foorumites nagu Apple'i oma (näiteks Apache koos J2EE-ga taustal) näitab, et paljud tänapäevased pinud käituvad saastunud parameetrite käsitlemisel, komadega eraldatud loendite genereerimisel ja nende väärtuste lõpliku töötlemise rakendusloogikale delegeerimisel sarnaselt serveritele nagu IIS või sellistele kombinatsioonidele nagu Apache ja Python.

Sellised näited tuletavad meelde, et Tavalistel juhtudel ei piisa sellest, et see "näib toimivat".Rakenduse reageeringut dubleerivate parameetrite, kummaliselt kodeeritud väärtuste, ebatavaliste kombinatsioonide jms saatmisele tuleb süstemaatiliselt testida, sest just seal leiab HPP oma niši.

HTTP parameetrite reostuse tuvastamine ja leevendamine

HPP tuvastamine ja leevendamine nõuab hübriidlähenemist, mis ühendab endas head turvalised arendustavad, serveri õige konfigureerimine ja spetsiaalsete tööriistade kasutamineWAF-ile lootmisest kõige parandamisel ei piisa, sest nagu me oleme näinud, on see sageli just see kiht, keda saab petta.

Arenduse seisukohast on oluline, et programmeerijad Pea meeles, et parameetril võib olla mitu väärtust ja nad peavad selgesõnaliselt otsustama, kuidas sellisel juhul toimida. Nad ei tohiks tugineda vaikekeelele või raamistiku käitumismallidele ilma põhjaliku arusaamata sellest, kuidas väärtuste eelistus toimib.

Samuti on soovitatav kriitilistes punktides, näiteks autentimine, autoriseerimine, tundlikud toimingud või olulised oleku muutusedRangelt valideeritakse, et parameetrid ilmuvad ainult üks kord, lükates tagasi topeltparameetritega päringud või vähemalt logides need analüüsiks.

Taristu osas on soovitatav üle vaadata veebiserveri ja raamistiku konfiguratsioonid Et täpselt aru saada, mis juhtub korduva parameetri vastuvõtmisel: kas säilitatakse esimene, viimane või kõik liidetud parameeter. Sealt edasi saab rakenduse loogikat kohandada, et vältida lahknevusi valideerimise ja väärtuse tegeliku kasutamise vahel.

Tööriistade osas on lisaks tavapärastele haavatavuste skanneritele kasulik kaasata ka sihipäraseid lahendusi, näiteks PAPAS või laienduste tüüp HPP leidja testimisvoos. Kui kasutatakse OWASP ZAP-i või muid penetratsioonitestimise tööriistu, on mõttekas kujundada spetsiaalsed skriptid, mis genereerivad päringud, mille parameetrid ja väärtused on erinevalt kodeeritud rakenduse reaktsiooni jälgimiseks.

Lõpuks on oluline tunnistada, et HPP on probleem palju levinum, kui üldiselt arvatakseSee kehtib eriti suurte ja paljude aastate pikkuse arenguga rakenduste kohta. Koolituse, koodi ülevaatuse, automatiseeritud testimise ja hästi kavandatud käsitsi testimise kombineerimine on parim viis nende vigade kontrolli all hoidmiseks.

HTTP-parameetrite saastumine on õigustatult teeninud oma koha veebirünnakutehnikate hulgas, mida iga arendus- ja turvameeskond peaks oma radaril hoidma: See on diskreetne, seda on logidele lihtsa pilguga raske märgata ja sellel võivad olla väga tõsised tagajärjed. kui see mõjutab äriloogika või turvakontrollide võtmeparameetreid. Selle mõistmine, kuidas teie pinus duplikaatparameetreid käsitletakse, ja nende stsenaariumide aktiivne testimine on üks neist ülesannetest, mis võib alguses tunduda veidi tüütu, kuid see teebki suure vahe pelgalt funktsionaalse rakenduse ja tõeliselt keerukate rünnakute suhtes vastupidava rakenduse vahel.