Kako prepoznati in preprečiti SQL injection

Kaj je SQL injection

SQL injection (SQLi) je eden najstarejših in najnevarnejših tipov napadov na spletne aplikacije. Napad deluje tako, da napadalec vbrizga zlonamerno SQL kodo v polja za vnos podatkov (obrazci, URL parametri, piškotki), ki jih aplikacija uporablja za ustvarjanje SQL poizvedb proti podatkovni bazi. Če aplikacija ne validira in ne sanitizira uporabniških vnosov, preden jih vgradi v SQL poizvedbo, lahko napadalec manipulira s poizvedbo, da bere, spreminja ali briše podatke iz baze.

Glede na seznam OWASP Top 10 so injection napadi že leta med tremi najbolj kritičnimi spletnimi ranljivostmi. Uspešen SQL injection napad lahko privede do kraje celotne podatkovne baze (uporabniških računov, gesel, osebnih podatkov), modifikacije ali brisanja podatkov, zaobitja avtentifikacije (prijava brez gesla), izvajanja ukazov na operacijskem sistemu strežnika in popolne kompromitacije strežnika.

Kako SQL injection deluje

Osnovni princip

Predstavljajte si prijavni obrazec, ki preverja uporabniško ime in geslo. Aplikacija ustvari SQL poizvedbo, ki izgleda približno takole: SELECT * FROM users WHERE username = 'vneseno_ime' AND password = 'vneseno_geslo'. Če aplikacija preprosto vstavi uporabnikov vnos v poizvedbo brez kakršnega koli preverjanja, lahko napadalec v polje za uporabniško ime vnese posebno vrednost, ki spremeni logiko poizvedbe. Na primer, vnos, ki vsebuje apostrof, sledi mu pa SQL koda, lahko zapre string literal in doda pogoj, ki je vedno resničen, s čimer se zaobide preverjanje gesla.

Tipi SQL injection napadov

Obstaja več tipov SQL injection napadov. In-band SQLi je najpogostejši tip, kjer napadalec uporablja isti komunikacijski kanal za pošiljanje napada in prejemanje rezultatov. Deli se na Error-based SQLi (uporablja sporočila o napakah baze za izvlek informacij) in Union-based SQLi (uporablja UNION operator za kombiniranje rezultatov zlonamerne poizvedbe z legitimno). Blind SQLi je tip, kjer napadalec ne vidi neposrednih rezultatov, vendar lahko sklepa informacije na podlagi vedenja aplikacije. Boolean-based blind SQLi pošilja poizvedbe, ki vračajo true ali false, in na podlagi razlike v odgovoru sklepa podatke znak za znakom. Time-based blind SQLi uporablja SQL funkcije za pavzo (SLEEP, WAITFOR DELAY), da ugotovi, ali je pogoj resničen, na podlagi časa odziva. Out-of-band SQLi uporablja drug kanal za izvlek podatkov, kot so DNS ali HTTP zahteve, ki jih baza pošlje na napadalčev strežnik.

Prepoznavanje SQL injection ranljivosti

Ročno testiranje

Najpreprostejši način za testiranje SQL injection ranljivosti je vstavljanje posebnih znakov v polja za vnos. Apostrof (') je prvi test - če aplikacija vrne napako podatkovne baze, obstaja potencialna ranljivost. Dvojni apostrof ('') ne bi smel povzročiti napake, če jo je prvi povzročil. SQL komentarji (-- ali #) se lahko uporabijo za komentiranje preostanka poizvedbe. Logični operatorji (OR 1=1, AND 1=2) lahko razkrijejo boolean-based ranljivosti. SLEEP ukaz ('; WAITFOR DELAY '0:0:5'--) razkrije time-based ranljivosti, če stran zamuja z odzivom.

Avtomatizirana orodja

Za sistematsko testiranje uporabite specializirana orodja. SQLMap je najbolj znano odprtokodno orodje za samodejno detekcijo in izkoriščanje SQL injection ranljivosti - podpira vse tipe SQLi in večino podatkovnih baz. Burp Suite Professional ima vgrajen skener za SQL injection in druge spletne ranljivosti. OWASP ZAP je brezplačna alternativa Burp Suite-u s solidnim SQLi skenerjem. Acunetix in Netsparker sta komercialna skenerja spletnih ranljivosti z napredno SQLi detekcijo.

Znaki kompromitacije

Če sumite, da je bila vaša stran že tarča SQL injection napada, preverite naslednje: nenavadne zapise v dnevnikih spletnega strežnika (URL-ji s SQL ključnimi besedami), nove ali spremenjene uporabniške račune v bazi (še posebej admin račune), spremenjene podatke brez vaše vednosti, nove datoteke na strežniku (web shell-i) in povečan promet proti specifičnim stranem z nenavadnimi parametri. Preglejte tudi dnevniške datoteke podatkovne baze za nepričakovane poizvedbe.

Preprečevanje - Prepared Statements

Kaj so prepared statements

Prepared statements (parametrizirane poizvedbe) so najučinkovitejša zaščita pred SQL injection-om. Namesto da se uporabniški vnos neposredno vstavi v SQL poizvedbo kot besedilo, prepared statement loči strukturo poizvedbe od podatkov. Najprej se definira struktura poizvedbe s placeholder-ji za podatke, nato pa se podatki pošljejo ločeno. Podatkovna baza obravnava podatke izključno kot vrednosti, nikoli kot SQL kodo, s čimer je injection nemogoč.

Implementacija v različnih jezikih

PHP s PDO (PHP Data Objects) uporablja metodo prepare() za pripravo poizvedbe s placeholder-ji (:username, :password) in execute() z nizom vrednosti. MySQLi razširitev podpira prepared statements s ? placeholder-ji in bind_param() za vezavo vrednosti s tipi podatkov. Python s sqlite3 ali psycopg2 uporablja ? ali %s placeholder-je. Java uporablja razred PreparedStatement z metodami setString(), setInt(). Node.js knjižnice, kot sta mysql2 in pg, podpirajo parametrizirane poizvedbe s ? ali $1 placeholder-ji. Ne glede na programski jezik je princip isti - nikoli ne združujte uporabniških vnosov s SQL poizvedbo kot nize.

Dodatne metode preprečevanja

Input validacija

Poleg prepared statements-ov vedno validirajte uporabniške vnose. Whitelist validacija dovoljuje samo pričakovane vrednosti - če mora polje vsebovati številko, preverite, da je dejansko številka pred obdelavo. Za besedilna polja omejite dovoljene znake, dolžino vnosa in obliko (regex). Nikoli se ne zanašajte samo na client-side validacijo (JavaScript), saj jo lahko napadalec zaobide - validacija mora biti implementirana na strežniku.

Stored Procedures

Stored procedures so SQL koda, ki se shrani in izvaja na strežniku podatkovne baze. Kadar so pravilno napisane (brez dinamičnega SQL-a znotraj procedure), zagotavljajo dodaten sloj zaščite, ker aplikacija pokliče proceduro s parametri namesto pošiljanja surovih SQL poizvedb. Vendar stored procedures same po sebi niso garancija varnosti - če procedure interno konstruirajo dinamične poizvedbe iz parametrov, ranljivost še vedno obstaja.

ORM (Object-Relational Mapping)

ORM knjižnice, kot so Eloquent (Laravel), SQLAlchemy (Python), Hibernate (Java) in TypeORM (Node.js), samodejno uporabljajo prepared statements za vse poizvedbe, s čimer odpravljajo večino tveganja SQL injection-a. Vendar pa večina ORM-ov dovoljuje surove SQL poizvedbe za kompleksne operacije - v teh primerih morate ročno uporabiti prepared statements. ORM ne nadomesti poznavanja SQL varnosti, vendar znatno zmanjša površino napada.

Princip najmanjših privilegijev

Konfigurirajte podatkovno bazo tako, da aplikacija uporablja račun z minimalnimi potrebnimi privilegiji. Spletna aplikacija običajno potrebuje privilegije SELECT, INSERT, UPDATE in DELETE na specifičnih tabelah. Ne dodeljujte privilegijev DROP, ALTER, CREATE ali FILE aplikacijskemu računu. Če napadalec uspe izvesti SQL injection, omejeni privilegiji preprečijo brisanje tabel, modifikacijo strukture baze in dostop do datotečnega sistema strežnika.

WAF zaščita pred SQL injection-om

Kako WAF detektira SQLi

Web Application Firewall (WAF) analizira HTTP zahtevke in blokira tiste, ki vsebujejo SQL injection vzorce. WAF prepozna SQL ključne besede na nepričakovanih mestih (SELECT, UNION, DROP v URL parametrih), posebne znake, ki se uporabljajo v SQLi napadih (apostrofi, komentarji, logični operatorji), znane SQLi payload-e iz baze podpisov in anomalije v strukturi zahtevka, ki nakazujejo na poskus injection-a.

Omejitve WAF-a

WAF ni nadomestilo za varno kodo. Izkušeni napadalci lahko zaobidejo WAF z uporabo encoding tehnik (URL encoding, Unicode, double encoding), komentarjev in presledkov za razbijanje podpisov, alternativnih SQL sintaks, ki jih WAF ne prepozna, in postopnega testiranja, da ugotovijo, katera pravila WAF uporablja. WAF je dodaten sloj zaščite (defense in depth), vendar mora biti primarna zaščita v kodi aplikacije skozi prepared statements in input validacijo.

SQL injection v WordPress-u

WordPress zaščitni mehanizmi

WordPress jedro uporablja metodo $wpdb->prepare() za vse poizvedbe proti bazi, kar je WordPress implementacija prepared statements-ov. Ta metoda uporablja placeholder-je v slogu sprintf (%s za nize, %d za integerje, %f za float-e) in samodejno escape-a vrednosti. Vendar se ranljivosti najpogosteje pojavijo v vtičnikih in temah, ki ne uporabljajo $wpdb->prepare() ali konstruirajo poizvedbe z ročnim združevanjem nizov.

Zaščita WordPress strani

Za zaščito WordPress strani pred SQL injection-om redno posodabljajte WordPress core, vtičnike in teme, saj varnostni popravki pogosto naslavljajo SQLi ranljivosti. Uporabljajte samo vtičnike in teme iz zaupanja vrednih virov (repozitorij WordPress.org, znani komercialni ponudniki). Namestite varnostni vtičnik (Wordfence, Sucuri, iThemes Security), ki vključuje WAF zaščito. Oglejte si tudi naš vodnik za zaščito strani pred hekerji. Odstranite neuporabljene vtičnike in teme, saj se lahko izkoristijo tudi deaktivirani vtičniki. Omejite dostop do podatkovne baze - WordPress potrebuje samo enega uporabnika z dostopom do svoje baze.

Pogoste napake, ki puščajo stran ranljivo

• Dinamičen SQL v kodi: Združevanje uporabniškega vnosa s SQL poizvedbo kot niz je glavni vzrok SQL injection ranljivosti. Vedno uporabljajte prepared statements.
• Zaupanje client-side validaciji: JavaScript validacijo je mogoče zaobiti - vsa validacija mora obstajati na strežniku.
• Podrobna sporočila o napakah: Prikazovanje SQL napak uporabnikom razkriva strukturo baze in olajša napad. V produkciji beležite napake interno, uporabnikom pa prikazujte generično sporočilo.
• Zastarela programska oprema: Stare različice CMS-ov, ogrodij in knjižnic imajo pogosto znane SQLi ranljivosti z javno dostopnimi exploit-i.
• En uporabnik baze za vse: Uporaba root računa za aplikacijo daje napadalcu popoln nadzor nad bazo v primeru uspešnega napada.

Zaključek

SQL injection je resna grožnja, ki lahko popolnoma kompromitira vašo stran in podatke uporabnikov. Preprečevanje je relativno preprosto - uporabljajte prepared statements za vse interakcije z bazo, validirajte uporabniške vnose na strežniku, uporabljajte princip najmanjših privilegijev in posodabljajte programsko opremo. WAF zagotavlja dodaten sloj zaščite, vendar ne nadomesti varne kode. Pri BeoHosting hosting storitvi vsi strežniki prihajajo s konfiguriranim ModSecurity WAF-om, ki detektira in blokira SQL injection poskuse, vendar priporočamo, da tudi vaša koda sledi najboljšim praksam varnega programiranja.