MSSQL Server Hardening – Deo 6: SQL Injection – kako autorizacija i audit ograničavaju štetu

Prethodnih pet delova serije bavilo se pojedinačnim slojevima zaštite — autentifikacijom, autorizacijom, auditom, backup-om i Availability Group konfiguracijom. Ovaj deo pokazuje kako se ti slojevi ponašaju zajedno u jednom konkretnom, veoma čestom scenariju: SQL injection napadu. Namerno ne pokrivamo kako se piše bezbedan aplikativni kod — to je posao razvojnog tima i van je opsega ovog bloga. Fokus je na tome šta se dešava na nivou baze kad prevencija na nivou aplikacije zakaže, jer je to deo koji sistem inženjer i auditor mogu direktno da provere i utiču na njega, nezavisno od toga ko piše aplikativni kod.

Zašto je ovo i dalje aktuelna tema

SQL injection je star, dobro poznat problem — a ipak, redovno se pojavljuju nove ranjivosti direktno u samom SQL Server-u koje ga koriste kao mehanizam za eskalaciju privilegija. Nedavan primer je CVE-2026-26116 — SQL injection ranjivost koja autentifikovanom napadaču sa niskim privilegijama omogućava da eskalira prava preko mreže. Ono što ovaj primer dobro ilustruje jeste da SQL injection nije isključivo problem "loše napisane aplikacije" — može postojati i na nivou same platforme, što dodatno naglašava zašto je odbrana u dubinu (defense in depth) neophodna, ne opciona.

Stored procedure nije automatski bezbedan

Čest, pogrešan zaključak je da korišćenje stored procedura samo po sebi rešava problem SQL injection-a. To nije tačno — stored procedura je bezbedna onoliko koliko su bezbedne njene unutrašnje operacije. Ako procedura prima parametar i zatim ga interno spaja (concatenate) u dinamički SQL string umesto da ga parametrizovano koristi, ranjivost i dalje postoji, samo je premeštena jedan sloj dublje, unutar same baze — često na mestu koje niko ne pregleda "jer je to stored procedura, pa je sigurno bezbedna".

Šta treba uraditi

• Pri pregledu postojećih stored procedura, posebno obratiti pažnju na upotrebu EXEC() ili sp_executesql sa dinamički sastavljenim stringom — ovo je znak da procedura možda nije zaista parametrizovana iznutra, bez obzira na to kako se poziva spolja
• Zahtevati od razvojnog tima da svaka nova stored procedura koja koristi dinamički SQL to radi isključivo preko parametrizovanog sp_executesql poziva, nikad preko direktne konkatenacije korisničkog unosa u string
• Tretirati stored procedure sa dinamičkim SQL-om kao rizičniji kod koji zaslužuje detaljniji bezbednosni pregled, ne kao podrazumevano bezbedno rešenje

Least privilege kao ograničavanje štete, ne kao prevencija

Ovo je ključna razlika koju vredi eksplicitno naglasiti, jer se često pogrešno shvata: princip najmanjih privilegija (opisan u drugom delu serije) ne sprečava SQL injection napad da se desi. On ograničava koliku štetu napadač može da napravi kad napad uspe. Ako aplikativni nalog ima samo SELECT i INSERT dozvole na tačno određenim tabelama, uspešan injection napad omogućava čitanje ili dodavanje podataka unutar tog ograničenog opsega — ali ne i brisanje tabela, izmenu šeme, ili, još ozbiljnije, izvršavanje komandi operativnog sistema preko xp_cmdshell opisanog u prvom delu serije.

Ovo je razlika između incidenta koji se otkrije, ograniči i sanira u okviru jednog dana, i incidenta koji rezultira potpunim gubitkom kontrole nad serverom. Ista aplikacija, ista ranjivost u kodu, potpuno različit ishod — u zavisnosti isključivo od toga koliko je aplikativni nalog bio ograničen na nivou baze pre nego što je do injection-a uopšte došlo.

Šta treba uraditi

• Za svaku aplikaciju koja pristupa bazi, jasno razgraničiti koje operacije su joj zaista potrebne (SELECT, INSERT, UPDATE, DELETE) i dodeliti samo te dozvole na tačno određenim tabelama, po principu iz drugog dela serije
• Za delove aplikacije koji samo čitaju podatke (izveštaji, pretraga, prikaz), koristiti poseban, isključivo SELECT nalog, odvojen od naloga koji ima pravo izmene podataka — ako je ranjiv baš taj deo aplikacije, šteta ostaje ograničena na čitanje
• Nikad ne dozvoliti aplikativnom nalogu DROP, ALTER, CREATE ili slična strukturna prava, osim ako aplikacija zaista, dokumentovano, tokom rada menja šemu baze — što je redak, ne uobičajen slučaj
• Proveriti da aplikativni nalog nema pristup sistemskim tabelama i pogledima koji otkrivaju informacije o drugim bazama, korisnicima ili kredencijalima na istoj instanci
• Potvrditi da xp_cmdshell (opisan u prvom delu serije) ostaje isključen na instancama koje hostuju bilo koju internet-facing ili manje pouzdanu aplikaciju — ovo je tačno scenario u kojem njegovo prisustvo pretvara injection napad u potpunu kompromitaciju servera

Audit kao mehanizam ranog otkrivanja

SQL Server Audit funkcija, opisana u trećem delu serije, ovde dobija konkretnu, praktičnu ulogu: obrasci ponašanja koji su tipični za injection napad često su vidljivi u audit logu pre nego što napad uspe, ili odmah nakon prvog uspešnog pokušaja — ako se audit prati aktivno, ne tek naknadno.

Šta treba uraditi

• Pratiti neuobičajene obrasce u upitima nad osetljivim tabelama — na primer, aplikativni nalog koji odjednom počne da izvršava upite van uobičajenog, očekivanog šablona za tu aplikaciju
• Postaviti alarm na neuspešne pokušaje pristupa objektima ili operacijama van dozvoljenog opsega naloga — ponovljeni pokušaji pristupa sistemskim tabelama ili izvršavanja administrativnih komandi sa aplikativnog naloga jak su indikator da nešto nije u redu
• Kombinovati audit podatke sa aplikativnim logovima gde je moguće — vremenska podudarnost neobičnog HTTP zahteva i neobičnog SQL upita znatno olakšava potvrdu da je reč o stvarnom napadu, ne o lažnom alarmu
• Redovno pregledati (ne samo prikupljati) audit podatke, po istom principu iz trećeg dela serije — audit koji se ne pregleda ne pomaže u ranom otkrivanju, samo u naknadnoj forenzici

Ovim se zaokružuje šesti deo serije, i sa njim prirodna celina koja povezuje prethodnih pet delova u jedan praktičan scenario. Bezbednost SQL Server-a nikad ne počiva na jednoj meri — parametrizovan kod na nivou aplikacije ostaje najvažnija, prva linija odbrane, ali least privilege, audit i sve ostalo pokriveno u ovoj seriji su ono što određuje razliku između sitnog incidenta i ozbiljne kompromitacije, u trenutku kad ta prva linija ipak popusti.