9 priljubljenih vrst napadov vbrizgavanja spletnih aplikacij

Težava spletnih aplikacij je, da so odprto izpostavljene milijonom uporabnikov interneta, med katerimi bodo mnogi želeli prekršiti svoje varnostne ukrepe – ne glede na razloge.


V zgodnjih dneh interneta je bila ena najpogostejših napadalnih metod osnovna, preprosta brutalna sila. Boti so ponavadi izvajali te napade – ali osebe z veliko prostega časa -, ki so preizkušale zilione kombinacij uporabniških imen in gesel, dokler niso našle tistega, ki bi omogočil dostop do ciljne aplikacije.

Brutalni napadi niso več grožnja zaradi pravilnikov o geslu, omejenih poskusov prijave in captchas. Toda kibernetski kriminalci radi odkrivajo nove podvige in jih uporabljajo za izvajanje novih vrst napadov. Dolgo nazaj so odkrili, da lahko besedilna polja na aplikacijah ali spletnih straneh izkoristijo tako, da vanj vnesejo – ali vbrizgajo – nepričakovano besedilo, ki bi prisililo aplikacijo, da naredi nekaj, česar ne bi smel storiti. Tako so na sceno stopili tako imenovani napadi injekcij.

Injekcijski napadi se lahko uporabljajo ne le za prijavo v aplikacijo brez poznavanja uporabniškega imena in gesla, ampak tudi za izpostavitev zasebnih, zaupnih ali občutljivih informacij ali celo za ugrabitev celotnega strežnika. Zato ti napadi ne grozijo samo spletnim aplikacijam, temveč tudi uporabnikom, katerih podatki so na teh aplikacijah, v najslabših primerih pa tudi drugim povezanim aplikacijam in storitvam.

Vbrizgavanje kode

Vbrizgavanje kode je ena najpogostejših vrst napadov injekcije. Če napadalci poznajo programski jezik, okvir, bazo podatkov ali operacijski sistem, ki ga uporablja spletna aplikacija, lahko vbrizgajo kodo preko polj za vnos besedila in s tem prisilijo spletni strežnik, da dela, kar hoče.

Te vrste napadov injekcije so možne v aplikacijah, ki nimajo preverjanja vhodnih podatkov. Če polje za vnos besedila uporabnikom omogoča, da vnesejo, karkoli želijo, je aplikacija potencialno izkoriščena. Za preprečitev teh napadov je treba aplikacijo omejiti toliko, kolikor lahko vnese uporabnikom vnosa.

Na primer, treba omejiti količino pričakovanih podatkov, preveriti obliko podatkov, preden jo sprejmejo, in omejiti nabor dovoljenih znakov.

Ranljivosti vbrizgavanja kode je enostavno najti, če preizkusite vnos besedila v spletni aplikaciji z različnimi vrstami vsebine. Ko jih najdemo, je ranljivosti zmerno težko izkoristiti. Ko pa napadalec uspe izkoristiti eno od teh ranljivosti, lahko vpliv vključuje izgubo zaupnosti, celovitosti, razpoložljivosti ali funkcionalnosti aplikacij.

Injekcija SQL

Podobno kot vbrizgavanje kode, ta napad v polje za vnos besedila vstavi skript SQL – jezik, ki ga uporablja večina baz podatkov za izvajanje poizvedbenih operacij. Skript se pošlje aplikaciji, ki ga izvrši neposredno v svoji bazi podatkov. Kot rezultat tega lahko napadalec preide prijavni zaslon ali stori bolj nevarne stvari, kot je branje občutljivih podatkov neposredno iz baze podatkov, spreminjanje ali uničenje podatkov baze podatkov ali izvajanje skrbniških operacij v bazi.

Aplikacije PHP in ASP sta nagnjeni k napadom vbrizgavanja SQL zaradi starejših funkcionalnih vmesnikov. Programi J2EE in ASP.Net so običajno bolj zaščiteni pred temi napadi. Ko najdemo ranljivost za vbrizgavanje SQL – in jih je mogoče zlahka najti -, bo obseg potencialnih napadov omejen le z veščino in domišljijo napadalca. Tako je vpliv napada injekcije SQL nedvomno velik.

Injiciranje ukazov

Možni so tudi ti napadi, predvsem zaradi nezadostne potrditve vnosa. Od napadov vbrizgavanja kode se razlikujejo po tem, da napadalec vstavi sistemske ukaze namesto kosov programske kode ali skriptov. Zato hekerju ni treba poznati programskega jezika, v katerem temelji aplikacija ali jezika, ki ga uporablja baza podatkov. Vendar morajo poznati operacijski sistem, ki ga uporablja strežnik gostovanja.

Vstavljene sistemske ukaze izvaja gostiteljski operacijski sistem s privilegiji aplikacije, ki bi lahko omogočili razkrivanje vsebine poljubnih datotek, ki so na strežniku, prikazovanje strukture imenika strežnika, med drugim spreminjanje uporabniških gesel..

Te napade lahko prepreči sysadmin, tako da omeji raven dostopa do sistema za spletne aplikacije, ki delujejo na strežniku.

Skriptnost na drugem mestu

Kadar koli aplikacija vnese podatke uporabnika v izhod, ki ga ustvari, ne da bi ga potrdila ali kodirala, daje napadalcu možnost, da zlonamerno kodo pošlje drugemu končnemu uporabniku. Napadi med skrivnimi skriptami (XSS) izkoristijo te priložnosti, da zlonamerne skripte vbrizgajo na zaupanja vredna spletna mesta, ki se na koncu pošljejo drugim uporabnikom aplikacije, ki postanejo napadalčeve žrtve.

Brskalnik žrtev bo zlonamerno skript izvedel, ne da bi vedel, da mu ne bi smeli zaupati. Zato bo brskalnik omogočil dostop do žetonov, piškotkov ali občutljivih informacij, ki jih shrani v brskalnik. Če so pravilno programirani, bi lahko skripti celo napisali vsebino datoteke HTML.

Napadi XSS lahko na splošno razdelimo v dve različni kategoriji: shranjeni in odsevani.

V shranjeno Napadi XSS, zlonamerni skript trajno prebiva na ciljnem strežniku, forumu za sporočila, zbirki podatkov, dnevniku obiskovalcev itd. Žrtev ga dobi, ko brskalnik zahteva shranjene podatke. V odsevalo V napadih XSS se zlonamerni skript kaže v odzivu, ki vključuje vhod, poslan v strežnik. To je lahko na primer sporočilo o napaki ali rezultat iskanja.

XPath injekcija

Ta vrsta napada je možna, kadar spletna aplikacija uporablja podatke, ki jih zagotovi uporabnik za izdelavo poizvedbe XPath za podatke XML. Način delovanja te napada je podoben vbrizganju SQL: napadalci pošljejo v program napačno oblikovane podatke, da ugotovijo, kako so strukturirani podatki XML, nato pa spet napadejo, da dostopajo do teh podatkov.

XPath je standardni jezik, s katerim lahko, tako kot SQL, določite atribute, ki jih želite najti. Če želite opraviti poizvedbo po podatkih XML, spletne aplikacije s pomočjo uporabniškega vnosa določijo vzorec, s katerim naj se podatki ujemajo. S pošiljanjem napačnega vnosa se lahko vzorec spremeni v operacijo, ki jo napadalec želi uporabiti za podatke.

Za razliko od tega, kar se zgodi s SQL, v XPathu ni različnih različic. To pomeni, da je mogoče injekcijo XPath opraviti v kateri koli spletni aplikaciji, ki uporablja podatke XML, ne glede na izvedbo. To pomeni tudi, da je napad mogoče avtomatizirati; zato lahko, za razliko od vbrizgavanja SQL, izstreli poljubno število ciljev.

Injiciranje poštnega ukaza

Ta metoda napada se lahko uporablja za izkoriščanje e-poštnih strežnikov in aplikacij, ki gradijo stavke IMAP ali SMTP z nepravilno potrjenim uporabniškim vnosom. Občasno strežniki IMAP in SMTP nimajo močne zaščite pred napadi, kot bi bilo to pri večini spletnih strežnikov, zato bi lahko bili bolj izkoriščeni. Napadniki prek e-poštnega strežnika bi se lahko izognili omejitvam, kot so captchas, omejeno število zahtev itd.

Za izkoriščanje strežnika SMTP napadalci potrebujejo veljaven e-poštni račun za pošiljanje sporočil z vbrizganimi ukazi. Če je strežnik ranljiv, se bo odzval na zahteve napadalcev in jim omogočil, da na primer preglasijo omejitve strežnika in uporabijo svoje storitve za pošiljanje neželene pošte.

Injekcijo IMAP je mogoče izvajati predvsem v spletnih programih, pri čemer se izkorišča funkcionalnost branja sporočil. V teh primerih lahko napad izvedete tako, da v naslovno vrstico spletnega brskalnika preprosto vnesete URL z vbrizganimi ukazi.

Injekcija CRLF

Vstavljanje znakov za vrnitev nosilca in podajanje vrstic – kombinacija, znana kot CRLF–, v vnosna polja spletnega obrazca predstavlja napadno metodo, imenovano CRLF injekcija. Ti nevidni znaki označujejo konec vrstice ali konec ukaza v mnogih tradicionalnih internetnih protokolih, kot so HTTP, MIME ali NNTP.

Na primer, vstavitev CRLF v zahtevo HTTP, ki ji sledi nekaj določene kode HTML, lahko obiskovalcem spletnega mesta pošlje spletne strani po meri..

Ta napad se lahko izvede na ranljivih spletnih aplikacijah, ki ne uporabljajo ustreznega filtriranja na uporabnikov vnos. Ta ranljivost odpira vrata za druge vrste napadov z injekcijami, kot sta XSS in vbrizgavanje kode, in lahko prihaja tudi do ugrabitve spletnega mesta.

Injekcija glavnega strežnika

V strežnikih, ki gostijo številna spletna mesta ali spletne aplikacije, postane glava gostitelja potrebna za določitev, katera od stalnih spletnih mest ali spletnih aplikacij – vsaka od njih znana kot virtualni gostitelj – naj obdeluje dohodno zahtevo. Vrednost glave sporoči strežniku, kateremu virtualnemu gostitelju naj se pošlje zahteva. Ko strežnik prejme neveljavno glavo gostitelja, ga običajno pošlje prvemu virtualnemu gostitelju na seznamu. To pomeni ranljivost, ki jo napadalci lahko uporabijo za pošiljanje poljubnih glav gostiteljev na prvi virtualni gostitelj v strežniku.

Manipulacija glavnega strežnika je običajno povezana z aplikacijami PHP, čeprav je to mogoče tudi z drugimi tehnologijami spletnega razvoja. Napadi na gostiteljske glave delujejo kot pripomočki za druge vrste napadov, kot je zastrupitev s spletnim predpomnilnikom. Njegove posledice lahko vključujejo izvajanje občutljivih operacij s strani napadalcev, na primer ponastavitev gesla.

Injekcija LDAP

LDAP je protokol, ki je zasnovan tako, da olajša iskanje virov (naprav, datotek, drugih uporabnikov) v omrežju. Zelo je uporaben za intranete, in ko ga uporabljamo kot del enotnega sistema za prijavo, ga lahko uporabimo za shranjevanje uporabniških imen in gesel. Poizvedbe LDAP vključujejo uporabo posebnih kontrolnih znakov, ki vplivajo na njen nadzor. Napadalci lahko potencialno spremenijo predvideno vedenje poizvedbe LDAP, če lahko vanj vstavijo kontrolne znake.

Ponovno je osnovna težava, ki omogoča napade injekcije LDAP, nepravilno potrjen uporabniški vnos. Če se besedilo, ki ga uporabnik pošlje v aplikacijo, uporabi kot del poizvedbe LDAP, ne da bi jo saniral, poizvedba lahko na koncu pridobi seznam vseh uporabnikov in ga pokaže napadalcu, samo z zvezdico (*) na desni strani postavite v vhodni niz.

Preprečevanje napadov injekcij

Kot smo videli v tem članku, so vsi napadi injekcije usmerjeni proti strežnikom in aplikacijam z odprtim dostopom do katerega koli uporabnika interneta. Odgovornost za preprečevanje teh napadov se porazdeli med razvijalce aplikacij in skrbnike strežnikov.

Razvijalci aplikacij morajo poznati tveganja, povezana z napačno potrditvijo vnosa uporabnikov, in se naučiti najboljših praks za sanitiziranje vnosa uporabnikov z namenom preprečevanja tveganj. Skrbniki strežnikov morajo občasno pregledati svoje sisteme, da bi odkrili ranljivosti in jih čim prej popravili. Obstaja veliko možnosti za izvajanje teh revizij na zahtevo ali samodejno.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map