# Verificarea bazei de date pentru cod introdus

> Verificați baza de date pentru cod malițios: găsiți scripturi introduse, adrese străine, trigger-e și conturi cu interogări de citire, fără a distruge date.

Sursa: https://phpsos.de/ro/blog/datenbank-auf-schadcode-pruefen/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Pentru a verifica baza de date pentru cod malițios, căutați într-un export sau într-o copie, cu interogări de citire, scripturi introduse, adrese străine și cod ofuscat în conținut și în setări. Verificați în plus trigger-ele, evenimentele programate, procedurile stocate și utilizatorii bazei de date. Curățați abia după evaluare și niciodată prin căutare și înlocuire oarbă, deoarece altfel datele serializate se strică.

## Punctul orb al multor curățări

După o intruziune, majoritatea operatorilor verifică fișierele. Înlocuiesc nucleul CMS-ului, șterg fișierele PHP suspecte și reinstalează extensiile. Site-ul pare după aceea curat, iar o săptămână mai târziu redirecționează din nou către pagini străine. Motivul se află adesea în baza de date, preluată neschimbată la curățare.

Pentru atacatori, baza de date este o ascunzătoare atractivă. Un script dintr-un widget este livrat pe fiecare pagină. O setare de adresă modificată redirecționează toți vizitatorii. Un cont de administrator suplimentar deschide ușa pentru mai târziu. Nimic din toate acestea nu iese în evidență la o scanare de fișiere.

După PHP2Shell, vulnerabilitățile CVE-2026-109618 și CVE-2026-109619, cu execuție de cod fără autentificare, baza de date face de aceea parte din orice verificare. Cine poate executa cod pe server poate, de regulă, citi din configurație datele de acces ale bazei de date și scrie acolo orice. Cum comunică aplicația, de fapt, cu baza de date explică [PHP și bazele de date: PDO și mysqli](https://phpsos.de/ro/php/php-und-datenbanken/).

## Unde se ascunde codul malițios în baza de date

| Loc de descoperire | Conținut tipic | Efect |
|---|---|---|
| Conținut (articole, pagini, produse) | blocuri `<script>`, linkuri invizibile, `<iframe>` | cod malițios sau spam pentru vizitatori |
| Setări și opțiuni | adresa site-ului modificată, scripturi străine în widgeturi sau în opțiunile temei | redirecționări, scripturi pe toate paginile |
| Tabele de utilizatori | administratori suplimentari | acces durabil |
| Trigger-e | cod care modifică conținutul la fiecare salvare | codul malițios revine după curățare |
| Evenimente programate | sarcini recurente în serverul de baze de date | modificări fără acces web |
| Utilizatori ai bazei de date | conturi suplimentare cu drepturi extinse | acces pe lângă CMS |

Ultimele trei rânduri sunt ratate deosebit de des, pentru că nu se află în tabelele CMS-ului, ci în serverul de baze de date însuși.

La magazinele online, un loc de descoperire merită atenție specială: setările prin care sunt incluse scripturi suplimentare în checkout și la finalizarea comenzii. Un script străin în acest loc poate citi datele introduse de clienți înainte să ajungă criptate la prestatorul de plăți. Verificați de aceea țintit toate câmpurile pentru codul din antet și din subsol, includerile de tracking și setările de design care acționează asupra paginilor de checkout.

Gândiți-vă și la alte baze de date de pe același server. Copiile de test și de staging, stările vechi ale proiectului sau bazele de date ale altor site-uri se află adesea alături și sunt accesibile cu aceleași date de acces. Ce se găsește în baza de date live ar trebui verificat și acolo, înainte ca o copie să mai servească ulterior drept bază.

## Verificarea bazei de date pentru cod malițios: conținut și setări

Lucrați pe un export. El este totodată conservare a probelor și bază de căutare. Exportul poate fi căutat ca fișier text, fără a încărca baza de date în funcțiune:

```bash
# Crearea unui export consistent (datele de acces sunt cerute interactiv)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256

# Numărarea tiparelor tipice din export
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
```

Ultima interogare listează, în ordinea frecvenței, toate domeniile care apar în baza de date. Domeniile străine, pe care nimeni din echipă nu le cunoaște, sunt candidații cei mai importanți. Pentru interogări țintite chiar în baza de date sunt potrivite comenzile SELECT. Exemplul folosește tabele WordPress; prefixul și numele tabelelor altor sisteme se găsesc în documentația lor:

```sql
-- Setări cu scripturi sau funcții suspecte
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;
```

Înregistrările cu conținut foarte mare merită atenție specială. Informații de fond despre ascunzătorile specifice WordPress oferă ghidul [Găsirea backdoor-urilor în WordPress](https://phpsos.de/ro/ratgeber/backdoor-wordpress-finden/).

## Trigger-e, evenimente și conturi de baze de date

Trigger-ele și evenimentele programate nu sunt prevăzute deloc în multe aplicații web. Dacă există, cineva ar trebui să poată explica de ce. Aceste interogări citesc doar din tabelele de sistem MySQL și MariaDB:

```sql
-- Trigger-e din toate bazele de date
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;

-- Evenimente programate
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;

-- Proceduri și funcții stocate
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

-- Utilizatorii bazei de date
SELECT user, host FROM mysql.user ORDER BY user;
```

Dacă aplicația dumneavoastră folosește PostgreSQL sau alt sistem de baze de date, tabelele de sistem și comenzile se numesc altfel; principiul rămâne același. Pentru analiză se recomandă un utilizator separat al bazei de date, care are voie doar să citească. Astfel, nici o greșeală de tastare într-o interogare nu poate modifica nimic, iar verificarea nu lasă urme în date.

Un trigger care atașează cod la salvarea unui articol explică de ce codul malițios revine după fiecare curățare. Utilizatorii necunoscuți ai bazei de date fac parte din verificarea conturilor la fel ca și conturile de administrator din CMS; mai multe la [Găsirea conturilor de administrator străine în CMS și pe server](https://phpsos.de/ro/blog/fremde-admin-konten-finden/).

## Curățarea corectă, fără a distruge date

Curățarea este partea cea mai delicată. Această ordine s-a dovedit eficientă:

1. **Evaluați descoperirile:** Fiecare rezultat este încadrat ca cunoscut, explicabil inofensiv sau străin. Codurile de tracking și de hărți sunt adesea legitime.
2. **Închideți punctul de intrare:** Aduceți PHP la o versiune corectată (8.5.12, 8.4.27, 8.3.36, 8.2.35 sau backport confirmat), reporniți toți workerii, actualizați aplicația.
3. **Eliminați țintit:** Curățați conținutul străin prin aplicație sau cu unelte care tratează corect datele serializate. Ștergeți trigger-ele, evenimentele și conturile străine.
4. **Schimbați datele de acces:** Parolă nouă pentru baza de date, introdusă în configurația aplicației, drepturile utilizatorului aplicației limitate la propria bază de date.
5. **Verificați din nou:** Repetați interogările de căutare după câteva zile.

> **Important:**
> Nu înlocuiți nimic prin căutare și înlocuire în exportul SQL. Datele PHP serializate stochează și lungimea fiecărui șir de caractere. Dacă lungimea se schimbă, setarea devine ilizibilă, iar site-ul poate cădea.

Redirecționările care apar în ciuda unei baze de date curate au cauza într-un alt strat. Articolul [Site-ul redirecționează către pagini străine](https://phpsos.de/ro/blog/website-leitet-um/) ajută la delimitare.

## Cum ajută PHP SOS concret?

- Salvăm baza de date cu sumă de control și căutăm în export scripturi, domenii străine și cod ofuscat.
- Verificăm trigger-ele, evenimentele, procedurile și utilizatorii bazei de date care se află în afara CMS-ului.
- Curățăm descoperirile în cadrul [eliminării malware-ului](https://phpsos.de/ro/leistungen/malware-entfernung/), fără a deteriora datele serializate.
- Limităm drepturile utilizatorului aplicației și repetăm verificarea după curățare.


## Întrebări frecvente

**Poate fi ascuns cod malițios în baza de date?**  
Da. Atacatorii scriu JavaScript în articole, descrieri de produse sau widgeturi, modifică setările de adresă pentru redirecționări sau creează conturi de administrator. În MySQL și MariaDB, trigger-ele și evenimentele programate pot modifica suplimentar datele. O scanare de fișiere nu găsește nimic din toate acestea.

**Cum caut în baza de date fără să stric ceva?**  
Lucrați pe un export sau pe o copie și folosiți doar interogări SELECT. Un export poate fi căutat în plus ca fișier text, cu grep. Modificările se fac abia după ce fiecare descoperire a fost evaluată și există o copie de siguranță.

**De ce să nu curăț descoperirile cu căutare și înlocuire în export?**  
Multe CMS-uri stochează setările ca date PHP serializate, în care se salvează și lungimea fiecărui șir de caractere. O înlocuire modifică lungimea, dar nu și indicația, iar setarea devine ilizibilă. Curățați prin aplicație sau cu unelte care înțeleg datele serializate.

**Este suspect orice script din baza de date?**  
Nu. Codurile de tracking, hărțile, videoclipurile sau widgeturile de chat sunt stocate tot ca script. Decisiv este dacă cineva din echipă cunoaște înregistrarea și adresa-țintă.

## Surse

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [php.net: anunțuri de securitate](https://www.php.net/)