Testiranje za ranljivosti SQL Injection

Napadi SQL Injection predstavljajo ogromno tveganje za spletne aplikacije, ki so odvisne od baze podatkov baze podatkov in ustvarjajo dinamične vsebine. V tej vrsti napadov, hekerji manipulirajo s spletno aplikacijo, da bi ubadali svoje lastne ukaze SQL v tiste, ki jih je izdala baza podatkov. Na primer, glejte članek SQL Injection Attacks na podatkovne baze. V tem članku si oglejte več načinov, na katere lahko preizkusite svoje spletne aplikacije, da ugotovite, ali so ranljivi za napade SQL Injection.

Samodejno pregledovanje injekcij SQL

Ena od možnosti je uporaba avtomatiziranega skenerja ranljivosti spletnih aplikacij, kot so HP's WebInspect, IBM AppScan ali Cenzic's Hailstorm. Ta orodja ponujajo enostavne in avtomatizirane načine za analizo vaših spletnih aplikacij za morebitne ranljivosti SQL Injection. Vendar pa so precej drage, tečejo do 25.000 $ na sedež.

Ročni preizkusi SQL Injection

Kaj je slab razvijalec aplikacij? Lahko dejansko zaženete nekaj osnovnih preizkusov za ovrednotenje svojih spletnih aplikacij za ranljivost SQL Injection, ki uporabljajo nič več kot spletni brskalnik. Prvič, beseda previdno: preskusi, ki jih opisujem, iščejo osnovne napake SQL Injection. Ne bodo zaznali naprednih tehnik in so nekoliko dolgočasni za uporabo. Če si ga lahko privoščite, pojdite s samodejnim optičnim bralnikom. Če pa ne morete ravnati s to ceno, je ročno testiranje odličen prvi korak.

Najlažji način, kako oceniti, ali je program ranljiv, je preskus z neškodljivimi injekcijskimi napadi, ki dejansko ne bodo škodovali vaši podatkovni bazi, če bodo uspešni, vendar vam bo zagotovil dokaze, da morate odpraviti težavo. Predpostavimo, na primer, da imate preprosto spletno aplikacijo, ki poišče posameznika v bazi podatkov in kot rezultat zagotovi kontaktne podatke. Ta stran lahko uporablja naslednjo obliko URL-ja:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Predpostavljamo, da ta stran opravi iskanje po podatkovni bazi z uporabo poizvedbe, podobne naslednjim:

SELECT telefon FROM directory WHERE lastname = 'chapple' in firstname = 'mike'

Poskusimo malo poskusiti s tem. Z zgornjo domnevo lahko preprosto spremenimo URL, ki prikazuje preizkuse napadov SQL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

Če spletna aplikacija ni bila ustrezno zaščitena pred injektiranjem SQL, to preprosto prikliče to lažno ime v stavku SQL, ki jo izvaja proti bazi podatkov, kar ima za posledico:

SELECT telefon FROM directory WHERE lastname = 'chapple' in firstname = 'mike' IN (izberi count (*) iz ponaredkov)> 0 OR '1' = '1'

Opazili boste, da je zgornja sintaksa malo drugačna kot v prvotnem URL-ju. Sprejel sem spremenljivko spremenljivke URL za svoje ASCII ekvivalente, da bi lažje sledili temu primeru. Na primer,% 3d je URL-kodiranje za znak '='. Dodal sem tudi nekaj odmikov vrstic za podobne namene.

Vrednotenje rezultatov

Preizkus prihaja, ko poskušate naložiti spletno stran z zgoraj navedenim URL-jem. Če je spletna aplikacija dobro obnašana, bo pred odhodom poizvedbe v podatkovno bazo izločila enojne narekovaje. To bo preprosto rezultat čudnega iskanja za nekoga s prvim imenom, ki vključuje kup SQL! Prikaže se sporočilo o napaki iz aplikacije, podobne spodnji:

Napaka: Noben uporabnik ni najden z imenom mike + AND + (izberite + count (*) + iz + ponarejenega) +% 3e0 + OR + 1% 3d1 Chapple!

Po drugi strani pa, če je aplikacija občutljiva za injekcijo SQL, bo izjavo posredovala neposredno v bazo podatkov, kar ima za posledico eno od dveh možnosti. Najprej, če je vaš strežnik omogočil podrobna sporočila o napakah (ki jih ne smete!), Boste videli nekaj takega:

Microsoft OLE DB Ponudnik za ODBC gonilnike napake '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Neveljavno ime objekta 'ponaredek'. /directory.asp, vrstica 13

Po drugi strani pa, če vaš spletni strežnik ne prikazuje podrobnih sporočil o napakah, boste dobili bolj generično napako, na primer:

Notranja napaka strežnika Strežnik je naletel na notranjo napako ali napačno konfiguracijo in ni mogel dokončati vaše zahteve. Prosimo, obrnite se na skrbnika strežnika, da obvestite, kdaj je prišlo do napake, in vse, kar ste morda storili, ki je morda povzročil napako. Več informacij o tej napaki je na voljo v dnevniku o napakah strežnika.

Če prejmete eno od dveh zgornjih napak, je vaša aplikacija občutljiva za napad SQL injection! Nekateri koraki, ki jih lahko uporabite za zaščito vaših aplikacij pred napadi SQL Injection, vključujejo:

• Izvedite preverjanje parametrov za vse aplikacije. Če na primer zahtevate, da nekdo vpiše številko kupca, pred vnosom poizvedbe preverite, ali je vnos numeričen.
• Omejite dovoljenja računov, ki izvajajo poizvedbe SQL . Uporablja se pravilo najmanj privilegij. Če račun, uporabljen za izvedbo poizvedbe, nima dovoljenja za njegovo izvajanje, to ne bo uspelo!
• Uporabite shranjene postopke (ali podobne tehnike), da uporabnikom preprečite neposredno interakcijo s kodo SQL.