Testiranje za SQL ranjivosti injekcije

SQL Injection napadi predstavljaju ogromne rizike za web aplikacije koje ovise o pozadini baze podataka za generiranje dinamičkog sadržaja. U ovoj vrsti napada, hakeri manipuliraju web aplikacijom u pokušaju da ubace svoje SQL naredbe u one koje je izdala baza podataka. Na primjer, pogledajte članak SQL injekcijski napadi na bazama podataka. U ovom članku razmatramo nekoliko načina testiranja web aplikacija kako bismo utvrdili jesu li ranjivi na SQL injekcijske napade.

Automatizirano SQL injekcijsko skeniranje

Jedna mogućnost je korištenje automatskog skenera za ranjivost web aplikacija, kao što su HP WebInspect, IBM's AppScan ili Cenzic's Hailstorm. Ovi alati pružaju jednostavan, automatizirani način analize web aplikacija za potencijalne SQL Injection ranjivosti. Međutim, oni su prilično skupi, i kreću se do 25.000 dolara po sjedalu.

Ručni SQL injekcijski testovi

Što je loš programer za aplikacije? Možete izvesti neke osnovne testove kako biste procijenili svoje web aplikacije za SQL Injection ranjivosti koristeći ništa više od web preglednika. Prvo, riječ opreznosti: testovi koje opisujemo samo traže osnovne nedostatke SQL Injection. Oni neće otkriti napredne tehnike i pomalo su dosadne koristiti. Ako si to možete priuštiti, idi s automatskim skenerom. Međutim, ako ne možete nositi tu cijenu, ručno testiranje je odličan prvi korak.Najjednostavniji način za procjenu je li aplikacija ranjiva je eksperimentirati s neškodljivim napadima ubrizgavanja koji ne utječu na vašu bazu podataka ako uspiju, ali će vam dati dokaze da trebate riješiti problem. Na primjer, pretpostavimo da ste imali jednostavnu web-aplikaciju koja pregledava pojedinca u bazi podataka i kao rezultat daje podatke za kontakt. Ta stranica može upotrebljavati sljedeći format URL-a:

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

Možemo pretpostaviti da ova stranica obavlja pretraživanje baze podataka, koristeći upit sličan sljedećem:

SELECT telefon

FROM mapu

WHERE prezime = 'chapple' i firstname = 'mike'

Pokušajmo malo eksperimentirati. Uz gore navedenu pretpostavku možemo napraviti jednostavnu izmjenu URL-a koji testovi za SQL injekcijske napade:

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

Ako web aplikacija nije pravilno zaštićena od SQL ubrizgavanja, ona jednostavno povezuje ovo lažno ime u SQL izraz koji izvršava protiv baze podataka, što rezultira:

SELECT telefon

FROM mapu

WHERE prezime = 'chapple' i firstname = 'mike'

I (odaberite broj (*) iz lažnog)> 0

OR '1' = '1'

Primijetit ćete da je gornja sintaksa malo drugačija od one u izvornom URL-u. Preuzeli smo slobodu pretvaranja varijable kodiranih URL-a za njihove ASCII ekvivalente kako bismo lakše pratili primjer. Na primjer,% 3d je šifriranje URL-a za znak '='. Dodali smo i nekoliko prekida linija za slične svrhe.

Procjena rezultata

Test dolazi kada pokušate učitati web stranicu s gore navedenim URL-om. Ako je web aplikacija dobro ponaša, uklonit će pojedinačne citate iz unosa prije nego što će proslijediti upit u bazu podataka. To će jednostavno rezultirati čudnim traženjem za nekoga s imenom koja uključuje hrpu SQL. Poruka o pogrešci iz aplikacije vidljiva je slično kao u nastavku:

Greška: Nije pronađen nijedan korisnik s imenom mike + AND + (odaberite + broj (*) + iz lažnog) +% 3e0 + OR + 1% 3d1

Chapple!

S druge strane, ako je aplikacija ranjiva na SQL injekciju, ona će proslijediti izjavu izravno u bazu podataka, što rezultira jednom od dvije mogućnosti. Prvo, ako vaš poslužitelj ima omogućene detaljne poruke o pogreškama (koje ne biste trebale), vidjet ćete nešto ovako:

Microsoft OLE DB Provider za pogrešku ODBC pogonitelja '80040e37'

Microsoft ODBC SQL Server Driver SQL Server Nevažeći naziv objekta 'lažan'.

/directory.asp, redak 13

S druge strane, ako vaš web poslužitelj ne prikaže detaljne poruke o pogrešci, dobit ćete općenitiju pogrešku, kao što su:

Interna pogreška poslužiteljaPoslužitelj je naišao na internu pogrešku ili pogrešnu konfiguraciju i nije mogao ispuniti vaš zahtjev.

Obratite se administratoru poslužitelja da biste obavijestili o vremenu nastanka pogreške i bilo čega što ste mogli učiniti da bi mogao uzrokovati pogrešku.

Dodatne informacije o ovoj pogrešci mogu biti dostupne u dnevniku pogrešaka poslužitelja.

Ako primite jednu od dvije gore navedene pogreške, vaša je aplikacija ranjiva na napad SQL injekcije. Neki koraci koje možete poduzeti da biste zaštitili svoje aplikacije od napada SQL Injection uključuju:

• Provesti provjeru parametara na svim aplikacijama. Na primjer, ako tražite da netko unese broj kupca, provjerite je li unos numerički prije nego što izvršite upit.
• Ograničite dozvole računa koji izvršavaju SQL upite. Primjenjuje se pravilo najmanje povlastice. Ako račun koji je upotrijebljen za izvršavanje upita nema dozvolu za njegovo izvršavanje, neće uspjeti.
• Upotrijebite pohranjene postupke (ili slične tehnike) kako biste spriječili korisnike da izravno stupaju u interakciju s SQL kodom.