Provjera baze podataka na ubačeni kod

Ukratko: Da biste bazu podataka provjerili na zlonamjerni kod, upitima koji samo čitaju pretražite izvoz ili kopiju u potrazi za ubačenim skriptama, tuđim adresama i prikrivenim kodom u sadržajima i postavkama. Provjerite i okidače, planirane događaje, pohranjene procedure i korisnike baze podataka. Čistite tek nakon procjene i nikad slijepim traženjem i zamjenom, jer se serijalizirani podaci tako raspadaju.

Slijepa pjega mnogih čišćenja

Nakon provale većina operatera provjerava datoteke. Zamjenjuju jezgru CMS-a, brišu sumnjive PHP datoteke i ponovno instaliraju proširenja. Web-stranica nakon toga izgleda čisto, a tjedan dana kasnije ponovno preusmjerava na tuđe stranice. Uzrok je često u bazi podataka, koja je pri čišćenju preuzeta nepromijenjena.

Za napadače je baza podataka privlačno skrovište. Skripta u widgetu isporučuje se na svakoj stranici. Izmijenjena postavka adrese preusmjerava sve posjetitelje. Dodatni administratorski račun otvara vrata za kasnije. Ništa od toga ne upada u oči pri pretrazi datoteka.

Nakon PHP2Shella, ranjivosti CVE-2026-109618 i CVE-2026-109619 s izvršavanjem koda bez prijave, baza podataka stoga spada u svaku provjeru. Tko na poslužitelju može izvršavati kod, u pravilu može iz konfiguracije pročitati pristupne podatke baze podataka i tamo upisivati što god želi. Kako aplikacija uopće komunicira s bazom podataka, objašnjava članak PHP i baze podataka: PDO i mysqli.

Gdje se zlonamjerni kod skriva u bazi podataka

Posljednja tri retka posebno se često previđaju jer se ne nalaze u tablicama CMS-a, nego u samom poslužitelju baze podataka.

Kod web-shopova jedno mjesto nalaza zaslužuje osobitu pažnju: postavke putem kojih se dodatne skripte uključuju u blagajnu i završetak narudžbe. Tuđa skripta na tom mjestu može čitati unose kupaca prije nego što se šifrirani pošalju pružatelju usluga plaćanja. Zato ciljano provjerite sva polja za kod zaglavlja i podnožja, uključivanja praćenja i postavke dizajna koje djeluju na stranicama blagajne.

Mislite i na druge baze podataka na istom poslužitelju. Testne i staging kopije, stara stanja projekata ili baze podataka drugih web-stranica često se nalaze pokraj i dostupne su istim pristupnim podacima. Što se nađe u živoj bazi podataka, treba provjeriti i tamo prije nego što kopija kasnije ponovno posluži kao osnova.

Provjera baze podataka na zlonamjerni kod: sadržaji i postavke

Radite na izvozu. On je istodobno osiguranje dokaza i osnova za pretragu. Izvoz se može pretraživati kao tekstualna datoteka bez opterećenja pokrenute baze podataka:

# Izraditi konzistentan izvoz (pristupni podaci se traže)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256

# Prebrojiti tipične obrasce u izvozu
grep -oiE '<script[^>]{0,80}' export.sql | sort | uniq -c | sort -rn | head -30
grep -oiE '(eval\(|base64_decode|fromCharCode|document\.write|atob\()' export.sql | sort | uniq -c
grep -oiE 'https?://[a-z0-9.-]+' export.sql | sort | uniq -c | sort -rn | head -50

Posljednji upit ispisuje sve domene koje se pojavljuju u bazi podataka, poredane po učestalosti. Tuđe domene koje nitko u timu ne poznaje najvažniji su kandidati. Za ciljane upite u samoj bazi podataka prikladne su SELECT naredbe. Primjer koristi tablice WordPressa; prefiks i nazivi tablica drugih sustava nalaze se u njihovoj dokumentaciji:

-- Postavke sa skriptama ili sumnjivim funkcijama
SELECT option_name, LENGTH(option_value) AS laenge
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%base64_decode%'
ORDER BY laenge DESC;

Unosi s vrlo velikim sadržajem zaslužuju osobitu pažnju. Pozadinu o skrovištima specifičnima za WordPress nudi vodič Pronaći stražnja vrata u WordPressu.

Okidači, događaji i računi baze podataka

Okidači i planirani događaji u mnogim web-aplikacijama uopće nisu predviđeni. Ako postoje, netko bi trebao moći objasniti zašto. Ovi upiti samo čitaju iz sistemskih tablica MySQL-a i MariaDB-a:

-- Okidači u svim bazama podataka
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;

-- Planirani događaji
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;

-- Pohranjene procedure i funkcije
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

-- Korisnici baze podataka
SELECT user, host FROM mysql.user ORDER BY user;

Ako Vaša aplikacija koristi PostgreSQL ili drugi sustav baze podataka, sistemske tablice i naredbe zovu se drukčije; načelo ostaje isto. Za analizu se preporučuje zaseban korisnik baze podataka koji smije samo čitati. Tako ni tipkarska pogreška u upitu ne može ništa promijeniti, a provjera ne ostavlja tragove u podacima.

Okidač koji pri spremanju objave dodaje kod objašnjava zašto se zlonamjerni kod vraća nakon svakog čišćenja. Nepoznati korisnici baze podataka pripadaju provjeri računa jednako kao administratorski računi u CMS-u; više o tome u članku Pronaći tuđe administratorske račune u CMS-u i na poslužitelju.

Čisto očistiti bez uništavanja podataka

Čišćenje je najosjetljiviji dio. Ovaj se redoslijed pokazao dobrim:

1. Procijeniti nalaze: svaki se pogodak svrstava kao poznat, bezazleno objašnjiv ili tuđ. Kodovi za praćenje i karte često su legitimni.
2. Zatvoriti ulaz: PHP dovesti na ispravljeno stanje (8.5.12, 8.4.27, 8.3.36, 8.2.35 ili potvrđeni backport), ponovno pokrenuti sve workere, ažurirati aplikaciju.
3. Ciljano ukloniti: tuđe sadržaje čistiti putem aplikacije ili alatima koji ispravno obrađuju serijalizirane podatke. Tuđe okidače, događaje i račune izbrisati.
4. Promijeniti pristupne podatke: nova lozinka baze podataka, upisati je u konfiguraciju aplikacije, prava korisnika aplikacije ograničiti na vlastitu bazu podataka.
5. Ponovno provjeriti: upite za pretragu ponoviti nakon nekoliko dana.

Preusmjeravanja koja se javljaju unatoč čistoj bazi podataka imaju uzrok u drugom sloju. Pri sužavanju pomaže članak Web-stranica preusmjerava na tuđe stranice.

Kako PHP SOS konkretno pomaže?

• Bazu podataka osiguravamo s kontrolnim zbrojem, a izvoz pretražujemo na skripte, tuđe domene i prikriveni kod.
• Provjeravamo okidače, događaje, procedure i korisnike baze podataka koji se nalaze izvan CMS-a.
• Nalaze čistimo u sklopu uklanjanja zlonamjernog softvera, bez oštećivanja serijaliziranih podataka.
• Ograničavamo prava korisnika aplikacije i ponavljamo provjeru nakon čišćenja.

Česta pitanja

Izvori

• OWASP Top 10
• OWASP Cheat Sheets
• php.net: sigurnosne obavijesti