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 opisujem traže samo 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 iz mape 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 iz direktorija WHERE prezime = 'chapple' i firstname = 'mike' I (odaberite broj (*) od lažnog)> 0 ILI '1' = '1'

Primijetit ćete da je gornja sintaksa malo drugačija od one u izvornom URL-u. Uzeo sam slobodu pretvaranja varijable kodiranih URL-ova za njihove ekvivalente ASCII kako bi lakše slijedio primjer. Na primjer,% 3d je šifriranje URL-a za znak '='. Također sam dodao neke prekide u sličnim svrhama.

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 koje uključuje hrpu SQL! Poruka o pogrešci iz aplikacije vidljiva je slično kao u nastavku:

Pogreška: Nije pronađen nijedan korisnik s imenom mike + AND + (odaberite + brojati (*) + od 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šci (koje ne biste trebale!), Vidjet ćete nešto ovako:

Microsoft OLE DB Provider za pogreške 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žitelja Posluž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 injectiona! 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.