# Datubāzes pārbaude, vai tajā nav ielikta koda

> Datubāzes pārbaude uz ļaunprātīgu kodu: kā ar lasāmiem vaicājumiem atrast ielikto kodu un skriptus, svešas adreses, trigerus un kontus, nesabojājot datus.

Avots: https://phpsos.de/lv/blog/datenbank-auf-schadcode-pruefen/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Lai pārbaudītu datubāzi uz ļaunprātīgu kodu, ar lasāmiem vaicājumiem pārmeklējiet eksportu vai kopiju, meklējot ielikto kodu un skriptus, svešas adreses un apslēptu kodu saturā un iestatījumos. Pārbaudiet arī trigerus, ieplānotos notikumus, saglabātās procedūras un datubāzes lietotājus. Attīriet tikai pēc izvērtēšanas un nekad ar aklu meklēšanu un aizstāšanu, jo serializēti dati citādi sabojājas.

## Daudzu attīrīšanu aklais plankums

Pēc ielaušanās lielākā daļa uzturētāju pārbauda failus. Viņi nomaina CMS kodolu, dzēš aizdomīgus PHP failus un no jauna uzstāda paplašinājumus. Pēc tam vietne izskatās tīra, un nedēļu vēlāk tā atkal pāradresē uz svešām lapām. Iemesls bieži ir datubāzē, kas attīrīšanā tika pārņemta nemainīta.

Uzbrucējiem datubāze ir pievilcīga slēptuve. Skripts logrīkā tiek piegādāts katrā lapā. Mainīts adrešu iestatījums novirza visus apmeklētājus. Papildu administratora konts atver durvis vēlākam laikam. Nekas no tā netiek pamanīts failu skenēšanā.

Pēc PHP2Shell, ievainojamībām CVE-2026-109618 un CVE-2026-109619 ar koda izpildi bez pieteikšanās, datubāze tāpēc pieder pie katras pārbaudes. Kas var izpildīt kodu serverī, tas parasti var nolasīt datubāzes piekļuves datus no konfigurācijas un tur rakstīt pēc patikas. Kā lietojumprogramma vispār sazinās ar datubāzi, izskaidro [PHP un datubāzes: PDO un mysqli](https://phpsos.de/lv/php/php-und-datenbanken/).

## Kur datubāzē slēpjas ļaunprātīgs kods

| Atrašanās vieta | Tipisks saturs | Ietekme |
|---|---|---|
| Saturs (raksti, lapas, produkti) | `<script>` bloki, neredzamas saites, `<iframe>` | ļaunprātīgs kods vai surogātpasts apmeklētājiem |
| Iestatījumi un opcijas | mainīta vietnes adrese, svešie skripti logrīkos vai tēmas opcijās | pāradresācijas, skripti visās lapās |
| Lietotāju tabulas | papildu administratori | pastāvīga piekļuve |
| Trigeri | kods, kas katrā saglabāšanā maina saturu | ļaunprātīgs kods atgriežas pēc attīrīšanas |
| Ieplānoti notikumi | atkārtoti uzdevumi datubāzes serverī | izmaiņas bez piekļuves caur tīmekli |
| Datubāzes lietotāji | papildu konti ar plašām tiesībām | piekļuve apejot CMS |

Pēdējās trīs rindas īpaši bieži tiek palaistas garām, jo tās atrodas nevis CMS tabulās, bet pašā datubāzes serverī.

Interneta veikalos vienai atrašanās vietai jāpievērš īpaša uzmanība: iestatījumiem, caur kuriem kasē un pasūtījuma noslēgumā tiek iekļauti papildu skripti. Svešs skripts šajā vietā var nolasīt klientu ievadi, pirms tā šifrēta nonāk pie maksājumu pakalpojuma sniedzēja. Tāpēc mērķtiecīgi pārbaudiet visus laukus galvenes un kājenes kodam, izsekošanas iekļaušanai un dizaina iestatījumiem, kas darbojas kases lapās.

Padomājiet arī par citām datubāzēm tajā pašā serverī. Testa un starpposma kopijas, veci projektu stāvokļi vai citu vietņu datubāzes bieži atrodas blakus un ir sasniedzamas ar tiem pašiem piekļuves datiem. Kas atrasts dzīvajā datubāzē, tas jāpārbauda arī tur, pirms kopija vēlāk atkal tiek izmantota kā pamats.

## Datubāzes pārbaude uz ļaunprātīgu kodu: saturs un iestatījumi

Strādājiet uz eksporta. Tas vienlaikus ir pierādījumu nodrošinājums un meklēšanas pamats. Eksportu var pārmeklēt kā teksta failu, neapgrūtinot darbojošos datubāzi:

```bash
# Izveidot konsekventu eksportu (piekļuves dati tiek pieprasīti)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256

# Saskaitīt tipiskus paraugus eksportā
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
```

Pēdējais vaicājums uzskaita visus domēnus, kas datubāzē sastopami, pēc biežuma. Svešie domēni, ko neviens komandā nepazīst, ir svarīgākie kandidāti. Mērķtiecīgiem vaicājumiem pašā datubāzē der SELECT komandas. Piemērs izmanto WordPress tabulas; citu sistēmu prefikss un tabulu nosaukumi atrodami to dokumentācijā:

```sql
-- Iestatījumi ar skriptiem vai aizdomīgām funkcijām
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;
```

Ieraksti ar ļoti lielu saturu pelna īpašu uzmanību. Fona informāciju par WordPress specifiskajām slēptuvēm sniedz ceļvedis [Slēpto piekļuvju atrašana WordPress](https://phpsos.de/lv/ratgeber/backdoor-wordpress-finden/).

## Trigeri, notikumi un datubāzes konti

Trigeri un ieplānoti notikumi daudzās tīmekļa lietojumprogrammās nemaz nav paredzēti. Ja tie pastāv, kādam jāspēj izskaidrot, kāpēc. Šie vaicājumi tikai lasa no MySQL un MariaDB sistēmas tabulām:

```sql
-- Trigeri visās datubāzēs
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;

-- Ieplānoti notikumi
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;

-- Saglabātās procedūras un funkcijas
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

-- Datubāzes lietotāji
SELECT user, host FROM mysql.user ORDER BY user;
```

Ja jūsu lietojumprogramma izmanto PostgreSQL vai citu datubāzu sistēmu, sistēmas tabulu un komandu nosaukumi ir citi; princips paliek tas pats. Analīzei ieteicams atsevišķs datubāzes lietotājs, kam atļauts tikai lasīt. Tā pat drukas kļūda vaicājumā neko nevar mainīt, un pārbaude neatstāj pēdas datos.

Trigeris, kas, saglabājot rakstu, pievieno kodu, izskaidro, kāpēc ļaunprātīgs kods atgriežas pēc katras attīrīšanas. Nezināmi datubāzes lietotāji pieder pie kontu pārbaudes tāpat kā administratoru konti CMS; vairāk par to sadaļā [Svešu administratoru kontu atrašana CMS un serverī](https://phpsos.de/lv/blog/fremde-admin-konten-finden/).

## Tīra attīrīšana, nesabojājot datus

Attīrīšana ir jutīgākā daļa. Šī secība ir sevi apliecinājusi:

1. **Novērtēt atradumus:** katrs trāpījums tiek klasificēts kā zināms, nekaitīgi izskaidrojams vai svešs. Izsekošanas un karšu kodi bieži ir leģitīmi.
2. **Aizvērt ieejas vārtus:** PHP atjaunināt uz labotu stāvokli (8.5.12, 8.4.27, 8.3.36, 8.2.35 vai apstiprināts backport), pārstartēt visus worker procesus, atjaunināt lietojumprogrammu.
3. **Mērķtiecīgi noņemt:** svešu saturu attīrīt caur lietojumprogrammu vai ar rīkiem, kas pareizi apstrādā serializētus datus. Svešus trigerus, notikumus un kontus dzēst.
4. **Nomainīt piekļuves datus:** jauna datubāzes parole, ierakstīt lietojumprogrammas konfigurācijā, lietojumprogrammas lietotāja tiesības ierobežot līdz savai datubāzei.
5. **Pārbaudīt vēlreiz:** meklēšanas vaicājumus atkārtot pēc dažām dienām.

> **Svarīgi:**
> Neaizstājiet neko ar meklēšanu un aizstāšanu SQL eksportā. Serializēti PHP dati glabā katras rakstzīmju virknes garumu. Ja garums mainās, iestatījums kļūst nelasāms un vietne var atteikt.

Pāradresācijām, kas parādās, neraugoties uz tīru datubāzi, cēlonis ir citā slānī. Sašaurināšanā palīdz raksts [Vietne pāradresē uz svešām lapām](https://phpsos.de/lv/blog/website-leitet-um/).

## Kā PHP SOS palīdz konkrēti?

- Mēs nodrošinām datubāzi ar kontrolsummu un pārmeklējam eksportu, meklējot skriptus, svešus domēnus un apslēptu kodu.
- Mēs pārbaudām trigerus, notikumus, procedūras un datubāzes lietotājus, kas atrodas ārpus CMS.
- Mēs attīrām atradumus [ļaunprogrammatūras noņemšanas](https://phpsos.de/lv/leistungen/malware-entfernung/) ietvaros, nebojājot serializētus datus.
- Mēs ierobežojam lietojumprogrammas lietotāja tiesības un pēc attīrīšanas pārbaudi atkārtojam.


## Biežāk uzdotie jautājumi

**Vai ļaunprātīgs kods var slēpties datubāzē?**  
Jā. Uzbrucēji ieraksta JavaScript rakstos, produktu aprakstos vai logrīkos, maina adrešu iestatījumus pāradresācijām vai izveido administratoru kontus. MySQL un MariaDB papildus trigeri un ieplānoti notikumi var mainīt datus. Failu skenēšana neatrod neko no tā.

**Kā pārmeklēt datubāzi, neko nesabojājot?**  
Strādājiet uz eksporta vai kopijas un izmantojiet tikai SELECT vaicājumus. Eksportu turklāt var pārmeklēt kā teksta failu ar grep. Izmaiņas veic tikai tad, kad katrs atradums ir novērtēts un ir rezerves kopija.

**Kāpēc atradumus nevajadzētu labot ar meklēšanu un aizstāšanu eksportā?**  
Daudzi CMS iestatījumus glabā kā serializētus PHP datus, kuros kopā ar to saglabāts katras rakstzīmju virknes garums. Aizstāšana maina garumu, bet ne norādi, un iestatījums kļūst nelasāms. Attīriet caur lietojumprogrammu vai ar rīkiem, kas saprot serializētus datus.

**Vai katrs skripts datubāzē ir aizdomīgs?**  
Nē. Izsekošanas kodi, kartes, video vai tērzēšanas logrīki arī tiek glabāti kā skripts. Izšķirošais ir, vai kāds komandā pazīst ierakstu un mērķa adresi.

## Avoti

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [php.net: drošības paziņojumi](https://www.php.net/)