Röviden: Az adatbázis kártékony kód szempontjából való ellenőrzéséhez csak olvasó lekérdezésekkel kutasson át egy exportot vagy egy másolatot bejuttatott szkriptek, idegen címek és elrejtett kód után a tartalmakban és a beállításokban. Ellenőrizze emellett a triggereket, az ütemezett eseményeket, a tárolt eljárásokat és az adatbázis-felhasználókat. Csak az értékelés után tisztítson, és soha ne vakon, keresés és csere útján, mert a szerializált adatok különben összetörnek.
Sok tisztítás vakfoltja
Egy behatolás után a legtöbb üzemeltető a fájlokat ellenőrzi. Lecserélik a CMS magját, törlik a gyanús PHP-fájlokat, és újratelepítik a bővítményeket. A weboldal ezután tisztának látszik, és egy hét múlva újra idegen oldalakra irányít át. Az ok gyakran az adatbázisban van, amelyet a tisztításkor változatlanul átvettek.
A támadók számára az adatbázis vonzó rejtekhely. Egy widgetben lévő szkript minden oldalon kiszolgálódik. Egy megváltoztatott címbeállítás minden látogatót elterel. Egy további rendszergazdai fiók ajtót nyit későbbre. Ezek közül egy fájlvizsgálatnál semmi sem tűnik fel.
A PHP2Shell, vagyis a CVE-2026-109618 és CVE-2026-109619 rések után, amelyek bejelentkezés nélküli kódvégrehajtást tesznek lehetővé, az adatbázis ezért minden ellenőrzéshez hozzátartozik. Aki kódot tud futtatni a szerveren, az általában a konfigurációból ki tudja olvasni az adatbázis hozzáférési adatait, és ott tetszése szerint írhat. Hogyan beszél egyáltalán az alkalmazás az adatbázissal, azt a PHP és adatbázisok: PDO és mysqli magyarázza.
Hol rejlik kártékony kód az adatbázisban
| Lelőhely | Tipikus tartalom | Hatás |
|---|---|---|
| Tartalmak (bejegyzések, oldalak, termékek) | <script>-blokkok, láthatatlan linkek, <iframe> |
kártékony kód vagy spam a látogatók számára |
| Beállítások és opciók | megváltoztatott weboldalcím, idegen szkriptek widgetekben vagy téma-opciókban | átirányítások, szkriptek minden oldalon |
| Felhasználói táblák | további adminisztrátorok | tartós hozzáférés |
| Triggerek | kód, amely minden mentéskor módosítja a tartalmakat | a kártékony kód a tisztítás után visszatér |
| Ütemezett események | ismétlődő feladatok az adatbázis-szerveren | módosítások webes hozzáférés nélkül |
| Adatbázis-felhasználók | további, széles jogkörű fiókok | hozzáférés a CMS megkerülésével |
Az utolsó három sort különösen gyakran átnézik, mert nem a CMS táblái között vannak, hanem magán az adatbázis-szerveren.
Webshopoknál egy lelőhely különös figyelmet érdemel: azok a beállítások, amelyekkel további szkripteket ágyaznak be a pénztárba és a rendelés lezárásába. Egy idegen szkript ezen a helyen kiolvashatja az ügyfelek beviteleit, mielőtt titkosítva továbbmennek a fizetési szolgáltatóhoz. Ezért célzottan ellenőrizze az összes mezőt a fejléc- és láblécbeli kód, a követőbeágyazások és a pénztároldalakon ható dizájnbeállítások számára.
Gondoljon emellett az ugyanazon a szerveren lévő további adatbázisokra is. A teszt- és staging-másolatok, a régi projektállapotok vagy más weboldalak adatbázisai gyakran mellette vannak, és ugyanazokkal a hozzáférési adatokkal elérhetők. Amit az éles adatbázisban megtalálnak, azt ott is érdemes ellenőrizni, mielőtt egy másolat később ismét alapul szolgál.
Az adatbázis ellenőrzése kártékony kódra: tartalmak és beállítások
Egy exporton dolgozzon. Egyszerre bizonyítékrögzítés és keresési alap. Az export szöveges fájlként átkutatható anélkül, hogy a futó adatbázist terhelné:
# Konzisztens export készítése (a hozzáférési adatokat bekéri)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256
# Tipikus minták megszámolása az exportban
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
Az utolsó lekérdezés gyakoriság szerint felsorolja az adatbázisban előforduló összes domaint. A csapatból senki által nem ismert idegen domainek a legfontosabb jelöltek. Az adatbázison belüli célzott lekérdezésekhez a SELECT-parancsok alkalmasak. A példa WordPress-táblákat használ; más rendszerek előtagját és táblaneveit azok dokumentációja tartalmazza:
-- Beállítások szkriptekkel vagy gyanús függvényekkel
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;
A nagyon nagy tartalmú bejegyzések különös figyelmet érdemelnek. A WordPress-specifikus rejtekhelyekről a Hátsó ajtók keresése a WordPressben útmutató ad háttérinformációkat.
Triggerek, események és adatbázis-fiókok
A triggereket és az ütemezett eseményeket sok webalkalmazás egyáltalán nem tervezi be. Ha léteznek, valakinek meg kell tudnia magyarázni, miért. Ezek a lekérdezések csak a MySQL és a MariaDB rendszertábláiból olvasnak:
-- Triggerek az összes adatbázisban
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;
-- Ütemezett események
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;
-- Tárolt eljárások és függvények
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');
-- Adatbázis-felhasználók
SELECT user, host FROM mysql.user ORDER BY user;
Ha az alkalmazása PostgreSQL-t vagy más adatbázisrendszert használ, a rendszertáblák és a parancsok másképp hívják, az elv ugyanaz marad. Az elemzéshez ajánlott egy külön adatbázis-felhasználó, amely csak olvashat. Így még egy elírás sem módosíthat semmit egy lekérdezésben, és az ellenőrzés nem hagy nyomot az adatokban.
Egy trigger, amely egy bejegyzés mentésekor kódot fűz hozzá, megmagyarázza, miért tér vissza a kártékony kód minden tisztítás után. Az ismeretlen adatbázis-felhasználók ugyanúgy a fiókellenőrzéshez tartoznak, mint a CMS rendszergazdai fiókjai; erről bővebben az Idegen rendszergazdai fiókok keresése CMS-ben és szerveren cikkben.
Tisztán megtisztítani, adatok károsítása nélkül
A tisztítás a legkényesebb rész. Ez a sorrend vált be:
- A találatok értékelése: Minden találatot ismertnek, ártalmatlanul megmagyarázhatónak vagy idegennek minősítenek. A követő- és térképkódok gyakran jogosak.
- A behatolási pont lezárása: Hozza a PHP-t javított állapotra (8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy megerősített backport), indítsa újra az összes workert, frissítse az alkalmazást.
- Célzott eltávolítás: Az idegen tartalmakat az alkalmazáson keresztül vagy olyan eszközökkel tisztítsa, amelyek helyesen kezelik a szerializált adatokat. Az idegen triggereket, eseményeket és fiókokat törölje.
- Hozzáférési adatok cseréje: Új adatbázis-jelszó, az alkalmazás konfigurációjába beírva, az alkalmazás-felhasználó jogait korlátozza a saját adatbázisára.
- Utóellenőrzés: A keresőlekérdezéseket néhány nap múlva ismételje meg.
Ne cseréljen le semmit keresés és csere útján az SQL-exportban. A szerializált PHP-adatok minden karakterlánc hosszát is tárolják. Ha a hossz megváltozik, a beállítás olvashatatlanná válik, és a weboldal kieshet.
Az átirányítások, amelyek tiszta adatbázis mellett is fellépnek, egy másik rétegben gyökereznek. A A weboldal idegen oldalakra irányít át cikk segít a behatárolásban.
Hogyan segít konkrétan a PHP SOS?
- Az adatbázist ellenőrző összeggel mentjük, és az exportot szkriptek, idegen domainek és elrejtett kód után kutatjuk át.
- Ellenőrizzük a CMS-en kívül lévő triggereket, eseményeket, eljárásokat és adatbázis-felhasználókat.
- A találatokat a kártevő-eltávolítás keretében tisztítjuk meg, a szerializált adatok károsítása nélkül.
- Korlátozzuk az alkalmazás-felhasználó jogait, és a tisztítás után megismételjük az ellenőrzést.
Gyakori kérdések
Lehet kártékony kód az adatbázisban?
Igen. A támadók JavaScriptet írnak a bejegyzésekbe, termékleírásokba vagy widgetekbe, módosítják az átirányításokhoz használt címbeállításokat, vagy rendszergazdai fiókokat hoznak létre. A MySQL-ben és a MariaDB-ben ezenkívül triggerek és ütemezett események is módosíthatnak adatokat. Egy fájlvizsgálat ezek közül semmit sem talál meg.
Hogyan kutassam át az adatbázist anélkül, hogy valamit elrontanék?
Egy exporton vagy egy másolaton dolgozzon, és csak SELECT-lekérdezéseket használjon. Az export ráadásul szöveges fájlként a grep paranccsal átkutatható. Módosítás csak akkor történjen, ha minden találatot értékeltek, és van mentés.
Miért ne tisztítsam meg a találatokat keresés és csere útján az exportban?
Sok CMS szerializált PHP-adatokként tárolja a beállításokat, amelyekben minden karakterlánc hossza is el van mentve. A csere megváltoztatja a hosszt, de a megadott értéket nem, és a beállítás olvashatatlanná válik. Az alkalmazáson keresztül vagy a szerializált adatokat értő eszközökkel tisztítson.
Minden szkript gyanús az adatbázisban?
Nem. A követőkódok, térképek, videók vagy csevegő-widgetek szintén szkriptként vannak tárolva. Az a döntő, hogy a csapatból valaki ismeri-e a bejegyzést és a cél címét.