Trumpai: norėdami patikrinti duomenų bazę dėl kenkėjiško kodo, skaitymo užklausomis peržiūrėkite eksportą ar kopiją ieškodami įterptų skriptų, svetimų adresų ir užmaskuoto kodo turinyje ir nustatymuose. Be to, patikrinkite trigerius, suplanuotus įvykius, saugomas procedūras ir duomenų bazės naudotojus. Valykite tik po įvertinimo ir niekada aklu ieškojimu ir pakeitimu, nes kitaip suges serializuoti duomenys.
Daugelio išvalymų aklas taškas
Po įsilaužimo dauguma operatorių tikrina failus. Jie pakeičia CMS branduolį, ištrina įtartinus PHP failus ir iš naujo įdiegia plėtinius. Po to svetainė atrodo švari, o po savaitės vėl nukreipia į svetimus puslapius. Priežastis dažnai slypi duomenų bazėje, kuri per išvalymą buvo perimta nepakeista.
Užpuolikams duomenų bazė yra patraukli slėptuvė. Skriptas valdiklyje pateikiamas kiekviename puslapyje. Pakeistas adreso nustatymas nukreipia visus lankytojus. Papildoma administratoriaus paskyra atveria duris vėlesniam laikui. Nė vienas iš šių dalykų nepastebimas failų skenavimo metu.
Po PHP2Shell, pažeidžiamumų CVE-2026-109618 ir CVE-2026-109619, leidžiančių vykdyti kodą be prisijungimo, duomenų bazė todėl priklauso kiekvienai patikrai. Kas gali vykdyti kodą serveryje, paprastai gali perskaityti duomenų bazės prisijungimo duomenis iš konfigūracijos ir ten rašyti ką tik nori. Kaip programa apskritai bendrauja su duomenų baze, paaiškina PHP ir duomenų bazės: PDO ir mysqli.
Kur kenkėjiškas kodas slepiasi duomenų bazėje
| Radimo vieta | Tipinis turinys | Poveikis |
|---|---|---|
| Turinys (straipsniai, puslapiai, produktai) | <script> blokai, nematomos nuorodos, <iframe> |
kenkėjiškas kodas ar šlamštas lankytojams |
| Nustatymai ir parinktys | pakeistas svetainės adresas, svetimi skriptai valdikliuose ar temos parinktyse | nukreipimai, skriptai visuose puslapiuose |
| Naudotojų lentelės | papildomi administratoriai | nuolatinė prieiga |
| Trigeriai | kodas, kuris kiekvieną kartą įrašant keičia turinį | kenkėjiškas kodas sugrįžta po išvalymo |
| Suplanuoti įvykiai | pasikartojančios užduotys duomenų bazės serveryje | pakeitimai be prieigos per žiniatinklį |
| Duomenų bazės naudotojai | papildomos paskyros su plačiomis teisėmis | prieiga aplenkiant CMS |
Paskutinės trys eilutės praleidžiamos ypač dažnai, nes jos yra ne CMS lentelėse, o pačiame duomenų bazės serveryje.
Internetinėse parduotuvėse viena radimo vieta nusipelno ypatingo dėmesio: nustatymai, per kuriuos papildomi skriptai įtraukiami į kasą ir užsakymo užbaigimą. Svetimas skriptas čia gali nuskaityti klientų įvestis, kol jos užšifruotos perduodamos mokėjimo paslaugai. Todėl tikslingai patikrinkite visus antraštės ir poraštės kodo laukus, sekimo įtraukimus ir dizaino nustatymus, veikiančius kasos puslapiuose.
Pagalvokite ir apie kitas duomenų bazes tame pačiame serveryje. Testinės ir pereinamosios (staging) kopijos, seni projektų variantai ar kitų svetainių duomenų bazės dažnai yra šalia ir pasiekiamos tais pačiais prisijungimo duomenimis. Tai, kas rasta gyvoje duomenų bazėje, reikėtų patikrinti ir ten, prieš kopiją vėliau vėl naudojant kaip pagrindą.
Duomenų bazės patikra dėl kenkėjiško kodo: turinys ir nustatymai
Dirbkite su eksportu. Jis kartu yra įrodymų išsaugojimas ir paieškos pagrindas. Eksportą galima peržiūrėti kaip tekstinį failą neapkraunant veikiančios duomenų bazės:
# Sukurti nuoseklų eksportą (prisijungimo duomenys bus paklausti)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256
# Suskaičiuoti tipinius šablonus eksporte
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
Paskutinė užklausa išvardija visus duomenų bazėje pasitaikančius domenus pagal dažnumą. Svetimi domenai, kurių niekas komandoje nepažįsta, yra svarbiausi kandidatai. Tikslinėms užklausoms pačioje duomenų bazėje tinka SELECT komandos. Pavyzdyje naudojamos WordPress lentelės; kitų sistemų prefiksas ir lentelių pavadinimai pateikti jų dokumentacijoje:
-- Nustatymai su skriptais ar įtartinomis funkcijomis
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;
Įrašai su labai dideliu turiniu nusipelno ypatingo dėmesio. Pagrindą apie WordPress specifines slėptuves pateikia gidas Užpakalinių durų paieška WordPress.
Trigeriai, įvykiai ir duomenų bazės paskyros
Trigeriai ir suplanuoti įvykiai daugelyje žiniatinklio programų apskritai nenumatyti. Jei jie egzistuoja, kas nors turėtų galėti paaiškinti, kodėl. Šios užklausos skaito tik iš MySQL ir MariaDB sistemos lentelių:
-- Trigeriai visose duomenų bazėse
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;
-- Suplanuoti įvykiai
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;
-- Saugomos procedūros ir funkcijos
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');
-- Duomenų bazės naudotojai
SELECT user, host FROM mysql.user ORDER BY user;
Jei jūsų programa naudoja PostgreSQL ar kitą duomenų bazės sistemą, sistemos lentelės ir komandos vadinasi kitaip; principas lieka tas pats. Analizei rekomenduojama turėti atskirą duomenų bazės naudotoją, kuris gali tik skaityti. Taip net rašybos klaida užklausoje nieko nepakeis, o patikra nepalieka pėdsakų duomenyse.
Trigeris, kuris įrašant straipsnį prideda kodą, paaiškina, kodėl kenkėjiškas kodas sugrįžta po kiekvieno išvalymo. Nežinomi duomenų bazės naudotojai priklauso paskyrų patikrai taip pat, kaip ir administratoriaus paskyros CMS; daugiau apie tai skyriuje Svetimų administratoriaus paskyrų paieška CMS ir serveryje.
Išvalyti švariai nesunaikinant duomenų
Išvalymas yra jautriausia dalis. Ši tvarka pasiteisino:
- Įvertinti radinius: kiekvienas atitikmuo priskiriamas kaip žinomas, nekenksmingai paaiškinamas arba svetimas. Sekimo ir žemėlapių kodai dažnai yra teisėti.
- Uždaryti įsilaužimo kelią: atnaujinti PHP į ištaisytą versiją (8.5.12, 8.4.27, 8.3.36, 8.2.35 arba patvirtintas atgalinis pataisų perkėlimas), iš naujo paleisti visus darbinius procesus (worker), atnaujinti programą.
- Šalinti tikslingai: svetimą turinį valyti per programą arba įrankiais, kurie teisingai tvarko serializuotus duomenis. Svetimus trigerius, įvykius ir paskyras ištrinti.
- Pakeisti prisijungimo duomenis: naujas duomenų bazės slaptažodis, įrašytas programos konfigūracijoje, programos naudotojo teisės apribotos jo paties duomenų baze.
- Patikrinti iš naujo: po kelių dienų pakartoti paieškos užklausas.
Nieko nekeiskite ieškodami ir pakeisdami SQL eksporte. Serializuoti PHP duomenys kartu saugo kiekvienos simbolių eilutės ilgį. Pasikeitus ilgiui, nustatymas tampa neskaitomas ir svetainė gali neveikti.
Nukreipimai, pasitaikantys nepaisant švarios duomenų bazės, turi priežastį kitame sluoksnyje. Susiaurinti padeda straipsnis Svetainė nukreipia į svetimus puslapius.
Kaip PHP SOS padeda konkrečiai?
- Duomenų bazę išsaugome su kontroline suma ir eksportą peržiūrime dėl skriptų, svetimų domenų ir užmaskuoto kodo.
- Tikriname trigerius, įvykius, procedūras ir duomenų bazės naudotojus, esančius už CMS ribų.
- Radinius valome vykdydami kenkėjiškų programų šalinimą, nepažeisdami serializuotų duomenų.
- Apribojame programos naudotojo teises ir po išvalymo pakartojame patikrą.
Dažni klausimai
Ar kenkėjiškas kodas gali slypėti duomenų bazėje?
Taip. Užpuolikai JavaScript rašo į straipsnius, produktų aprašymus ar valdiklius, keičia adresų nustatymus nukreipimams arba sukuria administratoriaus paskyras. MySQL ir MariaDB papildomai duomenis gali keisti trigeriai ir suplanuoti įvykiai. Failų skenavimas nieko iš to neranda.
Kaip peržiūrėti duomenų bazę nieko nesugadinant?
Dirbkite su eksportu ar kopija ir naudokite tik SELECT užklausas. Eksportą be to galima peržiūrėti kaip tekstinį failą su grep. Pakeitimai atliekami tik tada, kai kiekvienas radinys įvertintas ir yra atsarginė kopija.
Kodėl radinių nereikėtų valyti ieškant ir pakeičiant eksporte?
Daugelis CMS nustatymus saugo kaip serializuotus PHP duomenis, kuriuose kartu saugomas kiekvienos simbolių eilutės ilgis. Pakeitimas pakeičia ilgį, bet ne jo nurodymą, ir nustatymas tampa neskaitomas. Valykite per programą arba įrankiais, kurie supranta serializuotus duomenis.
Ar kiekvienas skriptas duomenų bazėje yra įtartinas?
Ne. Sekimo kodai, žemėlapiai, vaizdo įrašai ar pokalbių valdikliai taip pat saugomi kaip skriptas. Lemia tai, ar kas nors komandoje pažįsta įrašą ir tikslo adresą.