Kako prepoznati i spriječiti SQL injection

Šta je SQL injection

SQL injection (SQLi) je jedan od najstarijih i najopasnijih tipova napada na web aplikacije. Napad funkcionira tako što napadač ubacuje maliciozni SQL kod u polja za unos podataka (forme, URL parametre, kolačiće) koja aplikacija koristi za kreiranje SQL upita ka bazi podataka. Ako aplikacija ne validira i ne sanitizuje korisničke unose pre nego što ih ugradi u SQL upit, napadač može manipulisati upitom da čita, mijenja ili briše podatke iz baze.

Prema OWASP Top 10 listi, injection napadi su godinama među tri najkritičnije web ranjivosti. Uspešan SQL injection napad može rezultirati krađom cjelokupne baze podataka (korisničkih računa, lozinki, osobnih podataka), modifikacijom ili brisanjem podataka, zaobilaženjem autentifikacije (prijava bez lozinke), izvršavanjem komandi na operacijskom sistemu servera i potpunom kompromitacijom servera.

Kako SQL injection funkcionira

Osnovni princip

Zamislite login formu koja provjerava korisničko ime i lozinku. Aplikacija kreira SQL upit koji izgleda otprilike ovako: SELECT * FROM users WHERE username = 'uneto_ime' AND password = 'uneta_lozinka'. Ako aplikacija jednostavno ubaci korisnikov unos u upit bez ikakve provjere, napadač može u polje za korisničko ime uneti specijalnu vrijednost koja mijenja logiku upita. Na primjer, unos koji sadrži apostrof praćen SQL kodom može zatvoriti string literal i dodati uslov koji je uvek tačan, čime se zaobilazi provjera lozinke.

Tipovi SQL injection napada

Postoji nekoliko tipova SQL injection napada. In-band SQLi je najčešći tip gdje napadač koristi isti komunikacioni kanal za slanje napada i primanje rezultata. Deli se na Error-based SQLi (koristi poruke o greškama baze za izvlačenje informacija) i Union-based SQLi (koristi UNION operator za kombiniranje rezultata malicioznog upita sa legitimnim). Blind SQLi je tip gdje napadač ne vidi direktne rezultate ali može zaključiti informacije na osnovu ponašanja aplikacije. Boolean-based blind SQLi šalje upite koji vraćaju true ili false i na osnovu razlike u odgovoru zaključuje podatke karakter po karakter. Time-based blind SQLi koristi SQL funkcije za pauzu (SLEEP, WAITFOR DELAY) da utvrdi da li je uslov tačan na osnovu vremena odgovora. Out-of-band SQLi koristi drugi kanal za izvlačenje podataka, poput DNS ili HTTP zahtijeva koje baza šalje ka napadačevom serveru.

Prepoznavanje SQL injection ranjivosti

Manuelno testiranje

Najjednostavniji način za testiranje SQL injection ranjivosti je ubacivanje specijalnih karaktera u polja za unos. Apostrof (') je prvi test - ako aplikacija vrati grešku baze podataka, postoji potencijalna ranjivost. Dvostruki apostrof ('') ne bi trebalo da izazove grešku ako je prvi izazvao. SQL komentari (-- ili #) mogu biti korišteni za komentarisanje ostatka upita. Logički operatori (OR 1=1, AND 1=2) mogu otkriti boolean-based ranjivosti. SLEEP komanda ('; WAITFOR DELAY '0:0:5'--) otkriva time-based ranjivosti ako stranica kasni sa odgovorom.

Automatizirani alati

Za sistematsko testiranje, koristite specijalizirane alate. SQLMap je najpoznatiji open-source alat za automatsku detekciju i eksploataciju SQL injection ranjivosti - podržava sve tipove SQLi i većinu baza podataka. Burp Suite Professional ima ugrađeni skener za SQL injection i druge web ranjivosti. OWASP ZAP je besplatna alternativa Burp Suite-u sa solidnim SQLi skenerom. Acunetix i Netsparker su komercijalni web vulnerability skeneri sa naprednom SQLi detekcijom.

Znači kompromitacije

Ako sumnjate da je vaš sajt već bio meta SQL injection napada, provjerite sljedeće: neobični zapisi u web server logovima (URL-ovi sa SQL ključnim rečima), nove ili izmijenjene korisničke račune u bazi (posebno admin račune), izmijenjene podatke bez vašeg znanja, nove fajlove na serveru (web shell-ovi) i povećan promet ka specifičnim stranicama sa neobičnim parametrima. Pregledajte i log fajlove baze podataka za neočekivane upite.

Prevencija - Prepared Statements

Šta su prepared statements

Prepared statements (parametrizovani upiti) su najefikasnija zaštita od SQL injection-a. Umjesto da se korisnički unos direktno ubaci u SQL upit kao tekst, prepared statement razdvaja strukturu upita od podataka. Prvo se definira struktura upita sa placeholder-ima za podatke, a zatim se podaci šalju zasebno. Baza podataka tretira podatke isključivo kao vrijednosti, nikada kao SQL kod, čime je injection nemoguć.

Implementacija u različitim jezicima

PHP sa PDO (PHP Data Objects) koristi prepare() metodu za pripremu upita sa placeholder-ima (:username, :password) i execute() sa nizom vrijednosti. MySQLi extension podržava prepared statements sa ? placeholder-ima i bind_param() za vezivanje vrijednosti sa tipovima podataka. Python sa sqlite3 ili psycopg2 koristi ? ili %s placeholder-e. Java koristi PreparedStatement klasu sa setString(), setInt() metodama. Node.js biblioteke poput mysql2 i pg podržavaju parametrizovane upite sa ? ili $1 placeholder-ima. Bez obzira na programski jezik, princip je isti - nikada ne spajajte korisničke unose sa SQL upitom kao stringove.

Dodatne metode prevencije

Input validacija

Pored prepared statements-a, uvek validirajte korisničke unose. Whitelist validacija dozvoljava samo očekivane vrijednosti - ako polje treba da sadrži broj, provjerite da je zaista broj pre obrade. Za tekstualna polja, ograničite dozvoljene karaktere, dužinu unosa i format (regex). Nikada se ne oslanjajte samo na client-side validaciju (JavaScript) jer je napadač može zaobići - validacija mora biti implementirana na serveru.

Stored Procedures

Stored procedures su SQL kod koji se čuva i izvršava na serveru baze podataka. Kada su pravilno napisane (bez dinamičkog SQL-a unutar procedure), pružaju dodatni sloj zaštite jer aplikacija poziva proceduru sa parametrima umjesto da šalje sirove SQL upite. Međutim, stored procedure same po sebi nisu jamstva sigurnosti - ako procedure interno konstruiraju dinamičke upite od parametara, ranjivost i dalje postoji.

ORM (Object-Relational Mapping)

ORM biblioteke poput Eloquent (Laravel), SQLAlchemy (Python), Hibernate (Java) i TypeORM (Node.js) automatski koriste prepared statements za sve upite, čime eliminiraju većinu SQL injection rizika. Međutim, većina ORM-ova dozvoljava sirove SQL upite za kompleksne operacije - u tim slučajevima morate ručno koristiti prepared statements. ORM ne zamjenjuje poznavanje SQL sigurnosti, ali značajno smanjuje površinu napada.

Princip najmanjih privilegija

Konfigurirajte bazu podataka tako da aplikacija koristi račun sa minimalnim potrebnim privilegijama. Web aplikacija obično treba SELECT, INSERT, UPDATE i DELETE privilegije na specifičnim tabelama. Ne dodjeljujte DROP, ALTER, CREATE ili FILE privilegije aplikativnom računu. Ako napadač uspe da izvrši SQL injection, ograničene privilegije sprječavaju brisanje tabela, modifikaciju strukture baze i pristup fajl sistemu servera.

WAF zaštita od SQL injection-a

Kako WAF detektira SQLi

Web Application Firewall (WAF) analizira HTTP zahtjeve i blokira one koji sadrže SQL injection obrasce. WAF prepoznaje SQL ključne reči u neočekivanim mjestima (SELECT, UNION, DROP u URL parametrima), specijalne karaktere koji se koriste u SQLi napadima (apostrofi, komentari, logički operatori), poznate SQLi payload-e iz baze potpisa i anomalije u strukturi zahtijeva koje ukazuju na pokušaj injection-a.

Ograničenja WAF-a

WAF nije zamjena za siguran kod. Iskusni napadači mogu zaobići WAF koristeći encoding tehnike (URL encoding, Unicode, double encoding), komentare i razmake za razbijanje potpisa, alternativne SQL sintakse koje WAF ne prepoznaje i postepeno testiranje da utvrde koja pravila WAF koristi. WAF je dodatni sloj zaštite (defense in depth), ali primarna zaštita mora biti u kodu aplikacije kroz prepared statements i input validaciju.

SQL injection u WordPress-u

WordPress zaštitni mehanizmi

WordPress jezgro core koristi $wpdb->prepare() metodu za sve upite ka bazi, što je WordPress implementacija prepared statements-a. Ova metoda koristi sprintf-stil placeholder-e (%s za stringove, %d za integere, %f za float-ove) i automatski escapuje vrijednosti. Međutim, ranjivosti se najčešće pojavljuju u pluginima i temama koje ne koriste $wpdb->prepare() ili konstruiraju upite ručnim spajanjem stringova.

Zaštita WordPress sajta

Za zaštitu WordPress sajta od SQL injection-a, ažurirajte WordPress core, plugine i teme redovno jer sigurnosne zakrpe često adresiraju SQLi ranjivosti. Koristite samo plugine i teme iz pouzdanih izvora (WordPress.org repozitorijum, poznati komercijalni pružatelji usluge). Instalirajte sigurnosni plugin (Wordfence, Sucuri, iThemes Security) koji uključuje WAF zaštitu. Pogledajte i naš vodič za zaštitu sajta od hakera. Uklonite nekorištene plugine i teme jer i deaktivirani plugini mogu biti eksploatisani. Ograničite pristup bazi podataka - WordPress treba samo jednog korisnika sa pristupom svojoj bazi.

Česte greške koje ostavljaju sajt ranjivim

• Dinamički SQL u kodu: Spajanje korisničkog unosa sa SQL upitom kao string je glavni uzrok SQL injection ranjivosti. Uvek koristite prepared statements.
• Povjerenje u client-side validaciju: JavaScript validacija se može zaobići - sva validacija mora postojati na serveru.
• Detaljne poruke o greškama: Prikazivanje SQL grešaka korisnicima otkriva strukturu baze i olakšava napad. U produkciji, logirajte greške interno a korisnicima prikazujte generičku poruku.
• Zastareli softver: Stare verzije CMS-a, framework-a i biblioteka često imaju poznate SQLi ranjivosti sa javno dostupnim eksploitima.
• Jedan korisnik baze za sve: Korištenje root računa za aplikaciju daje napadaču potpunu kontrolu nad bazom u slučaju uspješnog napada.

Zaključak

SQL injection je ozbiljna pretnja koja može potpuno kompromitirati vaš sajt i podatke korisnika. Prevencija je relativno jednostavna - koristite prepared statements za sve interakcije sa bazom, validirajte korisničke unose na serveru, primjenjujte princip najmanjih privilegija i držite softver ažurnim. WAF pruža dodatni sloj zaštite ali ne zamjenjuje siguran kod. Na BeoHosting hosting usluzi, svi serveri dolaze sa konfiguriranim ModSecurity WAF-om koji detektira i blokira SQL injection pokušaje, ali preporučujemo da i vaš kod sljedi najbolje prakse sigurnog programiranja.