Nazaj na blog

SQL Injection v 2025: Se vedno nevarno, se vedno pogosto

October 09, 2024 3 min branja
SQL Injection v 2025: Se vedno nevarno, se vedno pogosto
Nazadnje posodobljeno:

SQL-vrivanje je bil prvič dokumentiran v poznih 1990-ih, a se dosledno pojavlja v OWASP Top 10 in ostaja ena najbolj vplivnih ranljivosti, ki jih odkrivam med penetracijskimi testi. Nekatere ocene postavljajo SQLi za več kot 30 % vseh kompromitacij spletnih aplikacij. Vprašanje ni, ali SQL-vrivanje obstaja -- vprašanje je, zakaj vztraja kljub desetletjem ozaveščenosti. Zastarele kodne baze, napačna uporaba ORM, bližnjice razvijalcev pod časovnim pritiskom in naraščajoča kompleksnost aplikacijskih skladov prispevajo k temu. SQL-vrivanje še skriva v paketnih uvozih, mehanizmih poročanja, administratorskih ploščah in integracijah tretjih oseb, ki sproti sestavljajo poizvedbe.

Pravilno parametrizacijo poizvedb in preverjanje dovoljenih vrednosti opisuje OWASP SQL Injection Prevention Cheat Sheet.

Kje še SQLi še vedno pojavlja

  • Dinamične klavzule ORDER BY -- Teh v večini gonilnikov ni mogoče parametrizirati, zato razvijalci neposredno združijo uporabniški vnos.
  • Funkcije iskanja in filtriranja -- Kompleksni obrazci dinamično sestavljajo klavzule WHERE, ko se število pogojev spreminja.
  • Zastareli shranjeni postopki -- Postopki z internim dinamičnim SQL (EXEC z združevanjem) ostajajo ranljivi tudi s parametriziranimi klici.
  • Surove poizvedbe ORM -- Djangov raw(), SQLAlchemyjev text() in ActiveRecordov find_by_sql() popolnoma obidejo zaščite ORM.
  • Funkcionalnost paketnega uvoza -- Uvoz CSV/Excel, ki dinamično generira stavke INSERT, je pogosto spregledan.

Sodobne tehnike obvoda

  • Obvod WAF -- Kodiranje URL/dvojno kodiranje, vgrajeni komentarji (SEL/**/ECT), manipulacija velikosti črk, normalizacija Unicode in znanstvena notacija izognejo pravilom na osnovi podpisov.
  • Vbrizgavanje drugega reda -- Vsebina se shrani prek legitimnega vnosa in sproži pozneje, ko druga poizvedba uporabi shranjeno vrednost brez sanitizacije. Težko zaznati, ker sta vbrizgavanje in sprožitev ločeni zahtevi.
  • Vbrizgavanje parametrov JSON/XML -- Vgnezdeni objekti JSON ali sekcije XML CDATA lahko skrijejo točke vbrizgavanja pred tradicionalnimi skenerji.
  • Onesnaževanje parametrov HTTP -- Podvojeni parametri (id=1&id=2 OR 1=1) zmedejo zaledne razčlenjevalnike različnih ogrodij.
  • Vzporednice vbrizgavanja NoSQL -- Vbrizgavanje operatorjev MongoDB ($gt, $ne, $regex) sledi isti logiki ekstrakcije proti nesanitiziranim operatorjem poizvedb.

Slepi SQL-vrivanje

  • Na osnovi logičnih vrednosti -- Različni odzivi aplikacije za pogoje true/false pridobivajo podatke bit za bitom.
  • Na časovni osnovi -- SLEEP(), WAITFOR DELAY ali pg_sleep() vnesejo merljive zakasnitve ob resničnih pogojih.
  • Izvenkanalno -- Ekstrakcija prek DNS z xp_dirtree (MSSQL) ali LOAD_FILE() s potmi UNC (MySQL), ko druge metode niso praktične.

Metodologija testiranja

  1. Preslikava točk vbrizgavanja -- Parametri URL, polja POST, glave HTTP (X-Forwarded-For), piškotki, telesa JSON/XML.
  2. Potrditev s časovnimi zamiki -- 5-sekundna zakasnitev je nezmotljiva potrditev.
  3. Določitev vrste baze -- @@version (MSSQL), version() (PostgreSQL/MySQL), banner FROM v$version (Oracle).
  4. Pridobivanje podatkov -- Najprej UNION (najhitrejša), nato logična, nato časovna metoda. Najprej shema, nato občutljivi podatki.
  5. Avtomatizacija s sqlmap -- --level=5 --risk=3 za temeljito testiranje; vedno ročno preverite ugotovitve z Burp Suite.

Prikaz vpliva

  • Pridobivanje podatkov -- Vzorčni zapisi iz občutljivih tabel za prikaz resnosti, omejeni na minimum za dokaz.
  • Obvod overitve -- Vsebine ' OR '1'='1 ali razbijanje pridobljenih zgoščenih gesel skrbnikov.
  • Izvajanje ukazov OS -- xp_cmdshell (MSSQL), INTO OUTFILE/LOAD_FILE() (MySQL), COPY TO/FROM PROGRAM (PostgreSQL).
  • Stopnjevanje pravic v bazi -- Nizko privilegiran uporabnik do DBA prek EXECUTE AS (MSSQL) ali preohlapnih dovoljenj.

Obramba v globino

  • Parametrizirane poizvedbe -- Primarna obramba brez izjem za vsako interakcijo s podatkovno bazo.
  • Najboljše prakse ORM -- Izključno uporabljajte graditelje poizvedb; parametrizirajte tudi surove poizvedbe.
  • Računi z najmanj privilegiji -- Samo SELECT/INSERT/UPDATE/DELETE na določenih tabelah. Nikoli ne dodelite FILE, EXECUTE ali skrbniških privilegijev.
  • WAF kot dopolnilna obramba -- Obramba v globino, vendar nikoli primarna omilitev. WAF je mogoče obiti; parametriziranih poizvedb ni.
  • Validacija vnosov -- Parametri ORDER BY naj sprejemajo le dovoljene stolpce z belega seznama, nikoli surovega uporabniškega vnosa.

SQL-vrivanje je tehnično resen z uporabo parametriziranih poizvedb. Vztraja zaradi človeških dejavnikov: zastarele kode, časovnega pritiska in nepopolnega razumevanja točk interakcije s podatkovno bazo. Naša naloga kot penetracijskih testerjev je najti te vrzeli, preden jih najdejo napadalci.

Sorodno branje: Testiranje varnosti API: Praktični vodic in Varnost GraphQL: Onkraj ranljivosti REST.

Vid Grosek

Vid Grosek

Etični heker & Penetracijski tester

Pomagam slovenskim podjetjem odkriti varnostne ranljivosti, preden jih odkrijejo napadalci. Z več kot 18 leti izkušenj v kibernetski varnosti.

Vse objave

Komentarji

Ni še komentarjev. Bodite prvi!

Dodaj komentar

Vam je bil članek všeč?

Prijavite se na newsletter za mesečne varnostne vpoglede.

Prijavite se