# Fișiere de backup în webroot: .zip, .sql și .bak

> Fișierele de backup din webroot le poate descărca oricine. Găsiți fișierele .zip, .sql și .bak, blocați-le și verificați dacă au fost accesate.

Sursa: https://phpsos.de/ro/blog/backup-dateien-im-webroot/  
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:** Fișierele de backup din webroot, adică dump-urile de baze de date (`.sql`), arhivele (`.zip`, `.tar.gz`) și copiile de siguranță (`.bak`, `.old`, `~`), le poate descărca oricine cunoaște sau ghicește numele fișierului. Căutați regulat asemenea fișiere cu `find`, mutați copiile de siguranță în afara directorului public, blocați în serverul web extensiile tipice și verificați în jurnalele de acces dacă au fost deja accesate.

## Backup-ul care devine scurgere

Chiar înainte de o actualizare, cineva face repede o copie de siguranță: `backup.zip` în directorul principal, alături `datenbank.sql`. Actualizarea reușește, fișierele rămân acolo. Luni mai târziu sunt tot acolo, cu întregul cod, toate datele clienților și datele de acces ale site-ului.

Acest tipar se numără printre cele mai frecvente constatări la verificările serverelor web. Nu are nevoie de un exploit și nici de o vulnerabilitate în PHP. Un server web livrează din webroot ce se află acolo, iar arhivele sau fișierele SQL nu le execută, ci le oferă la descărcare.

O arhivă a site-ului conține nu doar date, ci și codul împreună cu configurarea. Cine o descarcă poate căuta în liniște vulnerabilități și cunoaște datele de acces la baza de date.

Scannerele automate caută țintit nume tipice precum `backup.zip`, `site.tar.gz` sau `dump.sql`, adesea combinate cu numele domeniului sau cu o dată. Cine crede că un nume de fișier neobișnuit protejează subestimează cât de sistematic decurge această căutare.

## Ce fișiere sunt vizate

Fișierele de backup din webroot apar în mai multe forme:

| Tip | Extensii tipice | Ce conțin |
|---|---|---|
| Dump-uri de baze de date | `.sql`, `.sql.gz`, `.dump` | Date ale clienților, comenzi, hash-uri de parole, setări |
| Arhive ale site-ului | `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.rar`, `.7z` | Întreg codul, configurarea, upload-uri |
| Copii ale unor fișiere individuale | `.bak`, `.old`, `.orig`, `.save`, `.php~`, `.copy` | Adesea fișiere de configurare cu date de acces |
| Resturi de editor | `.swp`, `.swo`, `~` la sfârșit | Părți din fișiere editate chiar atunci |
| Copii de siguranță ale pluginurilor | Subdirectoare proprii în CMS | Copii de siguranță complete, uneori cu nume ghicibile |

Deosebit de delicate sunt copiile fișierelor de configurare. Fișierul original `config.php` este executat de server, iar conținutul său rămâne ascuns. Copia `config.php.bak` este livrată ca text, împreună cu parola bazei de date.

## Găsirea backup-urilor din webroot: căutarea pe server

Căutarea următoare listează fișierele suspecte de sub webroot-uri, cu dată și dimensiune. Adaptați căile la serverul dumneavoastră:

```bash
find /var/www /srv/www -type f \( \
  -iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
  -iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
  -iname '*.rar' -o -iname '*.7z' -o \
  -iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
  -iname '*~' -o -iname '*.swp' \) \
  -printf '%TY-%Tm-%Td  %10s  %p\n' 2>/dev/null | sort
```

Nu fiecare rezultat este o problemă. Unele arhive sunt puse intenționat la dispoziție pentru descărcare, de exemplu manuale. Fiecare fișier merită însă o decizie conștientă. Fiți atenți în special la fișierele mari și la directoarele pluginurilor de backup. La shared hosting fără acces shell ajută prezentarea fișierelor din panoul de hosting sau o interogare prin SFTP.

> **Acționați imediat:**
> Dacă găsiți în webroot un dump de bază de date cu date ale clienților, mutați-l imediat din directorul public și salvați jurnalele de acces înainte ca acestea să fie rotite. Abia apoi clarificați dacă fișierul a fost accesat.

## A fost fișierul deja descărcat?

Răspunsul se află în jurnalele de acces ale serverului web. Se caută accesările reușite, adică status 200, la fișierele găsite:

```bash
# Accesări reușite ale extensiilor tipice de backup (format de jurnal Combined)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
  | awk '$9 == 200 {print $4, $1, $7, $10}'
```

Ieșirea arată momentul, adresa, calea și dimensiunea răspunsului. Dacă dimensiunea transferată corespunde dimensiunii fișierului, fișierul a fost încărcat integral. Cât de departe în timp ajung jurnalele depinde de rotație. Dacă nu ajung până la data creării fișierului, o accesare anterioară nu poate fi exclusă. Detaliat descrie acest lucru [Analiza jurnalelor serverului web după un atac](https://phpsos.de/ro/ratgeber/logfiles-auswerten/). Fără acces la jurnalele brute, de exemplu la shared hosting, cereți furnizorului de hosting jurnalele pentru perioada respectivă.

Dacă a fost accesat un dump cu date cu caracter personal sau acest lucru nu poate fi exclus, începe verificarea unei obligații de notificare. Bazele le rezumă [Obligația de notificare RGPD: 72 de ore după incident](https://phpsos.de/ro/compliance/dsgvo-meldepflicht-72-stunden/); evaluarea în cazul individual aparține responsabilului dumneavoastră cu protecția datelor. Datele de acces din fișierele accesate le înlocuiți în orice caz.

## Pluginuri de backup, panouri și mutări

Multe descoperiri provin de la pluginuri de backup ale CMS-urilor și magazinelor. Ele depun adesea copiile într-un subdirector al webroot-ului, uneori cu nume formate din dată și domeniu, care pot fi ghicite. Verificați în fiecare plugin trei setări: Unde se face copia? Sunt șterse copiile locale după încărcarea către o țintă externă? Este directorul local protejat împotriva accesului direct?

Copiile de siguranță din panourile de hosting se află de regulă în afara webroot-ului, de exemplu în directorul home. Devine problematic când cineva copiază o asemenea copie în webroot, pentru că descărcarea în browser este mai comodă decât prin SFTP. Pentru mutări se aplică de aceea: transfer prin SFTP sau direct între servere, niciodată printr-un link public.

Dacă agenții sau furnizori de servicii se ocupă de site-urile dumneavoastră, această regulă ar trebui să figureze și în contract, împreună cu obligația de a face ordine după lucrările de mentenanță. Indicații oferă [Contracte cu furnizorii IT: reglementarea clară a obligațiilor de securitate](https://phpsos.de/ro/blog/dienstleistervertrag-sicherheit/).

## Prevenire durabilă: loc de stocare și blocări

Pentru ca problema să nu se repete, sunt necesare două niveluri. Primul este organizatoric: copiile de siguranță au un loc fix în afara webroot-ului și, în plus, în afara serverului. Cum arată o copie de siguranță rezistentă descrie ghidul [Backup-uri după regula 3-2-1](https://phpsos.de/ro/ratgeber/backups-3-2-1/).

Al doilea nivel este tehnic: serverul web refuză în principiu extensiile tipice de backup, chiar dacă totuși rămâne un fișier acolo.

```nginx
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
    return 404;
}
location ~ ~$ {
    return 404;
}
```

Arhivele precum `.zip` le blocați doar dacă site-ul dumneavoastră nu oferă descărcări în acest format, sau țintit în directoarele în care nu se află descărcări. Ajută complementar o căutare automată regulată cu notificare și o scurtă regulă în echipă: fără copii de siguranță și copii în webroot, nici pentru cinci minute. Cazuri înrudite, precum fișierele de configurare ascunse, tratează [Protejarea corectă a datelor de acces și a fișierelor .env](https://phpsos.de/ro/blog/env-dateien-schuetzen/).

## Cum ajută PHP SOS concret?

- Căutăm în webroot-urile dumneavoastră dump-uri, arhive, copii și copii de siguranță ale pluginurilor și evaluăm fiecare descoperire.
- Verificăm pe baza jurnalelor de acces dacă fișierele au fost accesate și documentăm rezultatul pentru evaluarea dumneavoastră privind protecția datelor.
- Configurăm blocări în serverul web și o căutare automată regulată.
- Mutăm copiile de siguranță într-un loc protejat, în afara webroot-ului.

Aceste lucrări fac parte din [întărirea serverului pentru servere web PHP](https://phpsos.de/ro/leistungen/server-haertung/) oferită de noi.


## Întrebări frecvente

**De ce ajung backup-urile, de fapt, în webroot?**  
De obicei din comoditate: un dump este generat pentru o mutare, un plugin depune copii de siguranță în propriul director sau, înainte de o modificare, se face repede o copie a unui fișier cu extensia .bak. Apoi fișierul este uitat.

**Cât de periculos este un fișier precum config.php.bak?**  
Foarte. Un fișier cu extensia .php este executat de server, iar conținutul său rămâne ascuns. O copie cu altă extensie este livrată în schimb de server, de regulă, ca text, împreună cu parola bazei de date și cheile.

**Este un dump de bază de date accesibil public o breșă de date?**  
Dacă conține date cu caracter personal și a fost accesat sau o accesare nu poate fi exclusă, intră în discuție o obligație de notificare conform RGPD. Evaluarea în cazul individual o preiau responsabilul dumneavoastră cu protecția datelor sau consilierea juridică.

**Unde ar trebui să se afle backup-urile în schimb?**  
În afara webroot-ului și, în plus, în afara serverului, conform regulii 3-2-1. Cel puțin o copie ar trebui stocată astfel încât serverul web însuși să nu o poată șterge sau modifica.

## Surse

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [RGPD art. 33: notificarea către autoritatea de supraveghere](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Documentația Nginx](https://nginx.org/en/docs/)