Kako prepoznati i sprečiti SQL injection

Šta je SQL injection

SQL injection (SQLi) je jedan od najstarijih i najopasnijih tipova napada na web aplikacije. Napad funkcioniše 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, menja 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 celokupne baze podataka (korisničkih naloga, lozinki, ličnih podataka), modifikacijom ili brisanjem podataka, zaobilaženjem autentifikacije (prijava bez lozinke), izvršavanjem komandi na operativnom sistemu servera i potpunom kompromitacijom servera.

Kako SQL injection funkcioniše

Osnovni princip

Zamislite login formu koja proverava 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 provere, napadač može u polje za korisničko ime uneti specijalnu vrednost koja menja logiku upita. Na primer, 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 provera lozinke.

Tipovi SQL injection napada

Postoji nekoliko tipova SQL injection napada. In-band SQLi je najčešći tip gde 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 kombinovanje rezultata malicioznog upita sa legitimnim). Blind SQLi je tip gde 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 zahteva 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šćeni 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.

Automatizovani alati

Za sistematsko testiranje, koristite specijalizovane 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, proverite sledeće: neobični zapisi u web server logovima (URL-ovi sa SQL ključnim rečima), nove ili izmenjene korisničke naloge u bazi (posebno admin naloge), izmenjene podatke bez vašeg znanja, nove fajlove na serveru (web shell-ovi) i povećan saobraćaj 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. Umesto da se korisnički unos direktno ubaci u SQL upit kao tekst, prepared statement razdvaja strukturu upita od podataka. Prvo se definiše struktura upita sa placeholder-ima za podatke, a zatim se podaci šalju zasebno. Baza podataka tretira podatke isključivo kao vrednosti, 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 vrednosti. MySQLi extension podržava prepared statements sa ? placeholder-ima i bind_param() za vezivanje vrednosti 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 vrednosti - ako polje treba da sadrži broj, proverite 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 umesto da šalje sirove SQL upite. Međutim, stored procedure same po sebi nisu garancija bezbednosti - ako procedure interno konstruišu 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 eliminišu 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 zamenjuje poznavanje SQL bezbednosti, ali značajno smanjuje površinu napada.

Princip najmanjih privilegija

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

WAF zaštita od SQL injection-a

Kako WAF detektuje SQLi

Web Application Firewall (WAF) analizira HTTP zahteve i blokira one koji sadrže SQL injection obrasce. WAF prepoznaje SQL ključne reči u neočekivanim mestima (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 zahteva koje ukazuju na pokušaj injection-a.

Ograničenja WAF-a

WAF nije zamena 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 vrednosti. Međutim, ranjivosti se najčešće pojavljuju u pluginima i temama koje ne koriste $wpdb->prepare() ili konstruišu 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 bezbednosne zakrpe često adresiraju SQLi ranjivosti. Koristite samo plugine i teme iz pouzdanih izvora (WordPress.org repozitorijum, poznati komercijalni provajderi). Instalirajte bezbednosni plugin (Wordfence, Sucuri, iThemes Security) koji uključuje WAF zaštitu. Pogledajte i naš vodič za zaštitu sajta od hakera. Uklonite nekorišćene 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.
• Poverenje 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, loggujte 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šćenje root naloga za aplikaciju daje napadaču potpunu kontrolu nad bazom u slučaju uspešnog napada.

Zaključak

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