# Andmebaasi kontrollimine sissetoodud koodi suhtes

> Andmebaasi kontroll kahjuliku koodi suhtes: leiate sissetoodud skriptid, võõrad aadressid, trigerid ja kontod lugevate päringutega ilma andmeid hävitamata.

Allikas: https://phpsos.de/et/blog/datenbank-auf-schadcode-pruefen/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** Andmebaasi kontrollimiseks kahjuliku koodi suhtes otsite ekspordist või koopiast lugevate päringutega sissetoodud skripte, võõraid aadresse ja hägustatud koodi sisus ja sätetes. Kontrollige lisaks trigereid, ajastatud sündmusi, salvestatud protseduure ja andmebaasikasutajaid. Puhastage alles pärast hindamist ja mitte kunagi pimeda otsi-ja-asenda abil, sest serialiseeritud andmed lähevad muidu katki.

## Paljude puhastuste pime laik

Pärast sissemurdmist kontrollib enamik haldajaid faile. Nad asendavad CMS-i tuuma, kustutavad kahtlased PHP-failid ja paigaldavad laiendused uuesti. Veebisait näeb pärast seda puhas välja ja nädala pärast suunab see taas võõrastele lehtedele. Põhjus on sageli andmebaasis, mis võeti puhastamisel muutmata kujul üle.

Ründajatele on andmebaas atraktiivne peidupaik. Vidinas olev skript väljastatakse igal lehel. Muudetud aadressisäte suunab kõik külastajad ümber. Täiendav administraatorikonto avab ukse hilisemaks. Failide skannimisel ei jää neist ükski silma.

Pärast PHP2Shelli, aukude CVE-2026-109618 ja CVE-2026-109619 koos autentimiseta koodi käivitamisega, kuulub andmebaas seetõttu iga kontrolli juurde. Kes saab serveris koodi käivitada, saab tavaliselt lugeda andmebaasi ligipääsuandmeid konfiguratsioonist ja sinna meelevaldselt kirjutada. Kuidas rakendus andmebaasiga üldse suhtleb, selgitab [PHP ja andmebaasid: PDO ja mysqli](https://phpsos.de/et/php/php-und-datenbanken/).

## Kus kahjulik kood andmebaasis peidus on

| Leiukoht | Tüüpiline sisu | Mõju |
|---|---|---|
| Sisu (postitused, lehed, tooted) | `<script>`-plokid, nähtamatud lingid, `<iframe>` | kahjulik kood või rämps külastajatele |
| Sätted ja suvandid | muudetud veebisaidi aadress, võõrad skriptid vidinates või teemasuvandites | ümbersuunamised, skriptid kõigil lehtedel |
| Kasutajatabelid | täiendavad administraatorid | püsiv ligipääs |
| Trigerid | kood, mis muudab salvestamisel iga kord sisu | kahjulik kood naaseb pärast puhastamist |
| Ajastatud sündmused | korduvad ülesanded andmebaasiserveris | muudatused ilma veebiligipääsuta |
| Andmebaasikasutajad | täiendavad kontod laiade õigustega | ligipääs CMS-ist mööda |

Viimased kolm rida jäävad eriti sageli märkamata, sest need ei asu CMS-i tabelites, vaid andmebaasiserveris endas.

Veebipoodide puhul väärib üks leiukoht erilist tähelepanu: sätted, mille kaudu kassasse ja tellimuse lõpetamisse ühendatakse täiendavaid skripte. Võõras skript selles kohas võib kliendi sisestusi kaasa lugeda, enne kui need krüpteeritult maksete teenusepakkujale lähevad. Kontrollige seetõttu sihipäraselt kõiki päise- ja jaluse koodi välju, jälgimislisandeid ja kujundussätteid, mis kassalehtedel mõjuvad.

Mõelge ka teistele andmebaasidele samas serveris. Testi- ja staging-koopiad, vanad projektiseisud või teiste veebisaitide andmebaasid asuvad sageli kõrvuti ja on samade ligipääsuandmetega kättesaadavad. Mis tööandmebaasist leitakse, tuleks kontrollida ka seal, enne kui koopia hiljem taas aluseks võetakse.

## Andmebaasi kontroll kahjuliku koodi suhtes: sisu ja sätted

Töötage ekspordil. See on korraga tõendite kindlustamine ja otsingu alus. Ekspordi saab tekstifailina läbi otsida, töötavat andmebaasi koormamata:

```bash
# Tehke järjepidev eksport (ligipääsuandmeid küsitakse)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256

# Loendage ekspordis tüüpilisi mustreid
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
```

Viimane päring loetleb kõik andmebaasis esinevad domeenid sageduse järgi. Võõrad domeenid, mida keegi meeskonnas ei tunne, on kõige olulisemad kandidaadid. Sihipäraste päringute jaoks andmebaasis endas sobivad SELECT-käsud. Näide kasutab WordPressi tabeleid; teiste süsteemide eesliide ja tabelinimed on nende dokumentatsioonis:

```sql
-- Sätted, milles on skripte või kahtlaseid funktsioone
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;
```

Väga suure sisuga kirjed väärivad erilist tähelepanu. Taustateavet WordPressi-spetsiifiliste peidukohtade kohta pakub juhend [Tagauste leidmine WordPressis](https://phpsos.de/et/ratgeber/backdoor-wordpress-finden/).

## Trigerid, sündmused ja andmebaasikontod

Trigerid ja ajastatud sündmused ei ole paljudes veebirakendustes üldse ette nähtud. Kui need eksisteerivad, peaks keegi oskama selgitada, miks. Need päringud loevad ainult MySQL-i ja MariaDB süsteemitabeleid:

```sql
-- Trigerid kõigis andmebaasides
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;

-- Ajastatud sündmused
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;

-- Salvestatud protseduurid ja funktsioonid
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

-- Andmebaasikasutajad
SELECT user, host FROM mysql.user ORDER BY user;
```

Kui teie rakendus kasutab PostgreSQL-i või muud andmebaasisüsteemi, on süsteemitabelite ja käskude nimed teised; põhimõte jääb samaks. Analüüsiks soovitame eraldi andmebaasikasutajat, kes tohib ainult lugeda. Nii ei saa isegi päringu kirjaviga midagi muuta ja kontroll ei jäta andmetesse jälgi.

Trigger, mis lisab postituse salvestamisel koodi, seletab, miks kahjulik kood naaseb pärast iga puhastamist. Tundmatud andmebaasikasutajad kuuluvad kontode kontrolli juurde samamoodi nagu administraatorikontod CMS-is; rohkem selle kohta artiklis [Võõraste administraatorikontode leidmine CMS-is ja serveris](https://phpsos.de/et/blog/fremde-admin-konten-finden/).

## Puhas puhastamine ilma andmeid hävitamata

Puhastamine on kõige delikaatsem osa. See järjekord on end õigustanud:

1. **Hinnake leide:** iga tabamus liigitatakse tuntuks, kahjutult seletatavaks või võõraks. Jälgimis- ja kaardikoodid on sageli legitiimsed.
2. **Sulgege sissepääs:** viige PHP parandatud seisu (8.5.12, 8.4.27, 8.3.36, 8.2.35 või kinnitatud tagasiportimine), taaskäivitage kõik töölised, uuendage rakendust.
3. **Eemaldage sihipäraselt:** puhastage võõras sisu rakenduse kaudu või tööriistadega, mis serialiseeritud andmeid õigesti käsitlevad. Kustutage võõrad trigerid, sündmused ja kontod.
4. **Vahetage ligipääsuandmed:** uus andmebaasi parool, kandke see rakenduse konfiguratsiooni, piirake rakenduse kasutaja õigused oma andmebaasiga.
5. **Kontrollige järele:** korrake otsingupäringuid mõne päeva pärast.

> **Oluline:**
> Ärge asendage midagi SQL-ekspordis otsi-ja-asenda abil. Serialiseeritud PHP-andmed salvestavad iga sõne pikkuse kaasa. Kui pikkus muutub, muutub säte loetamatuks ja veebisait võib tööst välja langeda.

Ümbersuunamised, mis esinevad ka puhta andmebaasi korral, tulenevad mõnest teisest kihist. Piiramisel aitab artikkel [Veebisait suunab külastajad võõrastele lehtedele](https://phpsos.de/et/blog/website-leitet-um/).

## Kuidas PHP SOS konkreetselt aitab?

- Kindlustame andmebaasi kontrollsummaga ja otsime ekspordist skripte, võõraid domeene ja hägustatud koodi.
- Kontrollime trigereid, sündmusi, protseduure ja andmebaasikasutajaid, mis asuvad väljaspool CMS-i.
- Puhastame leiud [pahavara eemaldamise](https://phpsos.de/et/leistungen/malware-entfernung/) raames, serialiseeritud andmeid kahjustamata.
- Piirame rakenduse kasutaja õigusi ja kordame kontrolli pärast puhastamist.


## Korduma kippuvad küsimused

**Kas kahjulik kood võib peituda andmebaasis?**  
Jah. Ründajad kirjutavad JavaScripti postitustesse, tootekirjeldustesse või vidinatesse, muudavad ümbersuunamiste jaoks aadressisätteid või loovad administraatorikontosid. MySQL-is ja MariaDB-s võivad andmeid lisaks muuta trigerid ja ajastatud sündmused. Failide skannimine ei leia neist ühtegi.

**Kuidas otsin andmebaasist, midagi katki tegemata?**  
Töötage ekspordil või koopial ja kasutage ainult SELECT-päringuid. Ekspordi saab lisaks tekstifailina grep-iga läbi otsida. Muudatusi tehakse alles siis, kui iga leid on hinnatud ja varukoopia olemas.

**Miks ei tohiks leide ekspordis otsi-ja-asenda abil puhastada?**  
Paljud CMS-id salvestavad sätted serialiseeritud PHP-andmetena, kus iga sõne pikkus salvestatakse kaasa. Asendamine muudab pikkust, kuid mitte selle märget, ja säte muutub loetamatuks. Puhastage rakenduse kaudu või tööriistadega, mis serialiseeritud andmetest aru saavad.

**Kas iga skript andmebaasis on kahtlane?**  
Ei. Jälgimiskoodid, kaardid, videod või vestlusvidinad salvestatakse samuti skriptina. Otsustav on, kas keegi meeskonnas tunneb kirjet ja sihtaadressi.

## Allikad

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [php.net: turvateated](https://www.php.net/)