# Fișiere PHP în directorul de upload: interpretarea corectă a constatărilor

> Fișier PHP în folderul uploads? Interpretați constatarea, verificați accesările în log, deosebiți substituenții inofensivi de webshell-uri și acționați.

Sursa: https://phpsos.de/ro/blog/php-dateien-im-upload-ordner/  
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:** Un fișier PHP în directorul de upload este un semnal de alarmă serios, deoarece acolo ar trebui să se afle doar imagini și documente. Nu deschideți niciodată fișierul în browser, ci citiți-l ca text, verificați marcajele de timp și proprietarul și căutați numele fișierului în logurile de acces. De obicei sunt inofensivi doar substituenții goi, precum un `index.php` fără conținut; tratați tot restul ca o posibilă intruziune.

## De ce PHP nu are ce căuta în directorul de upload

Directoarele de upload sunt destinate conținutului pe care îl încarcă vizitatorii sau redactorii: imagini, PDF-uri, videoclipuri. Utilizatorul serverului web are voie să scrie acolo, altfel upload-urile nu funcționează. Exact aceasta face aceste directoare atractive pentru atacatori. Cine poate scrie fișiere printr-o vulnerabilitate le depune acolo unde scrierea este permisă.

Fișierele PHP noi în directoarele de upload sau de cache se numără, conform rapoartelor de care dispunem, printre semnalele generale de alarmă după o intruziune. Pentru PHP2Shell nu există Indicators of Compromise confirmate; o constatare nu spune deci nimic despre vulnerabilitatea prin care a ajuns fișierul. Cum se construiesc în siguranță funcțiile de upload descrie [Implementarea sigură a upload-urilor de fișiere în PHP](https://phpsos.de/ro/ratgeber/datei-upload-sicher/).

Dacă un astfel de fișier poate face daune decide configurația serverului web. Dacă el execută fișiere PHP din directorul de upload, orice fișier depus acolo devine o posibilă telecomandă. Dacă execuția este blocată acolo, fișierul rămâne un corp străin, dar inițial fără efect. Multe instalări nu au configurat niciodată această blocare.

## Cum ajunge un fișier PHP în directorul de upload?

Pentru evaluare ajută să cunoașteți căile posibile. Fiecare duce la alte întrebări ulterioare.

| Cale | Context tipic | Întrebare ulterioară |
|---|---|---|
| Formular de upload nesigur | verificarea doar a extensiei sau a tipului raportat de browser | Ce formulare acceptă fișiere? |
| Vulnerabilitate într-un plugin sau temă | slăbiciune cunoscută într-o extensie depășită | Ce extensii sunt depășite? |
| Date de acces furate | cont de administrator, FTP sau hosting | Ce autentificări au existat recent? |
| Execuție de cod printr-o vulnerabilitate | de exemplu în interpretor, cum este posibil la PHP2Shell | Era PHP vulnerabil în acea perioadă? |
| Plugin legitim | substituenți, rar fișiere de cache | Aparține fișierul pachetului original? |

Mai multe căi pot coincide. Un atacator care execută cod printr-o vulnerabilitate poate depune fișierul doar pentru a reveni mai comod mai târziu.

## Listarea sistematică a locurilor de descoperire

Înainte de a evalua un fișier individual, faceți-vă o imagine de ansamblu. Comenzile doar citesc. Căile sunt exemple pentru WordPress; la alte sisteme adaptați calea de upload.

```bash
# Fișiere asemănătoare PHP în directorul de upload, cu dimensiune, proprietar, mtime și ctime
find /var/www/html/wp-content/uploads -type f \
  \( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
  -printf '%s Bytes  %u  m:%T+  c:%C+  %p\n'

# Determinarea tipului de fișier după conținut, nu după extensie (imaginile cu conținut PHP ies în evidență)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
```

Alte sisteme folosesc alte directoare de scriere, de exemplu `fileadmin` la TYPO3, `images` la Joomla sau directorul media de sub `public` la Shopware 6. Se adaugă directoarele de cache și temporare ale aplicației. La instalările multisite și la mai multe site-uri pe un server există corespunzător multe directoare de upload; fiecare aparține căutării.

Și fișierele `.htaccess` și `.user.ini` din directorul de upload sunt suspecte. Cu ele se poate reactiva execuția PHP în acest director sau modifica configurația.

## Fișier PHP în folderul uploads: interpretarea corectă a constatării

Nu fiecare potrivire este la fel de gravă. Încadrarea următoare ajută la prima evaluare. Ea nu înlocuiește o investigație amănunțită.

| Constatare | Prima încadrare |
|---|---|
| `index.php` cu zero octeți sau doar un comentariu | de regulă substituent împotriva listării directoarelor, comparați cu pluginul |
| Fișier PHP cu conținut într-un director lunar | suspiciune ridicată |
| Dublă extensie precum `bild.jpg.php` sau `.php.png` | suspiciune ridicată, camuflaj tipic |
| Imagine care conține, conform `file`, cod PHP | suspiciune ridicată, poate fi executată prin includere |
| `.htaccess` sau `.user.ini` în directorul de upload | suspiciune, verificați configurația |
| Fișierul aparține utilizatorului serverului web, ctime după 17.10. | se potrivește cu o intruziune prin site |

Citiți fișierele suspecte doar ca text, de exemplu cu `head -c 2000 datei.php` sau `less`. Ies în evidență rândurile foarte lungi, șirurile de caractere codificate și numele de funcții precum `eval` sau `base64_decode`. Cum recunoașteți codul ofuscat arată [Recunoașterea codului PHP ofuscat](https://phpsos.de/ro/blog/verschleierter-php-code/).

## A fost apelat fișierul? O privire în log

Cea mai importantă întrebare după constatare este: a folosit cineva fișierul? Răspunsul se află în logurile de acces ale serverului web. Căutați numele fișierului, inclusiv în loguri arhivate.

```bash
# Apelările fișierului suspect în logurile curente și comprimate (numele ca exemplu)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null

# Doar apelările reușite, cu adresa IP și momentul
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
```

Multe cereri POST reușite de la puține adrese indică folosirea activă ca webshell. Lipsa potrivirilor nu înseamnă automat alarmă încheiată, deoarece logurile pot fi rotite, șterse sau incomplete. Dacă site-ul rulează în spatele unui CDN sau al unui proxy, acolo se află alte jurnale; la shared hosting, furnizorul pune de obicei la dispoziție logurile de acces în zona de clienți. Fiți atenți și la cereri către alte fișiere noi de la aceleași adrese, deoarece ele duc adesea la alte componente. Păstrați logurile începând din 20 octombrie. Cum evaluați temeinic logurile se află în ghidul [Evaluarea logurilor serverului web după un atac](https://phpsos.de/ro/ratgeber/logfiles-auswerten/).

> **Acționați imediat:**
> Dacă logul arată apelări reușite ale unui fișier PHP necunoscut, porniți de la premisa unei intruziuni. Păstrați fișierul și logurile, restrângeți accesul la server și verificați dacă pot fi afectate date cu caracter personal.

## După evaluare: ordinea corectă

1. **Păstrați:** Copiați fișierul cu suma de control și marcajele de timp, păstrați logurile.
2. **Clarificați proveniența:** Verificați formularele de upload, pluginurile și perioada dinaintea constatării.
3. **Căutați alte componente:** fișiere suplimentare, cronjob-uri, conturi noi de administrator.
4. **Blocați execuția:** Interziceți PHP în directorul de upload la nivel de server web, așa cum descrie articolul [Interzicerea execuției PHP în directoarele de upload](https://phpsos.de/ro/blog/php-in-uploads-verbieten/).
5. **Curățați și schimbați accesurile:** abia apoi eliminați fișierul și reînnoiți toate parolele.

## Cum ajută PHP SOS concret?

- **Evaluarea constatării:** Verificăm fișierul fără a-l executa și îl încadrăm.
- **Clarificarea utilizării:** Evaluăm logurile și reconstituim cine și când a apelat fișierul.
- **Curățare completă:** Prin [eliminarea malware-ului](https://phpsos.de/ro/leistungen/malware-entfernung/) căutăm toate componentele, închidem cauza și schimbăm accesurile.
- **Prevenirea repetării:** Blocăm execuția PHP în directoarele de scriere și monitorizăm fișierele noi.


## Întrebări frecvente

**Este periculos orice fișier PHP din directorul de upload?**  
Nu orice. Unele pluginuri depun un index.php gol, pentru ca conținutul directorului să nu fie listat. Tot restul, mai ales fișierele cu conținut, nume neobișnuit sau dublă extensie, ar trebui tratat ca un caz suspect.

**Am voie să deschid fișierul suspect în browser?**  
Nu. O apelare prin site execută codul. Citiți fișierul doar ca text pe server sau într-o copie, de exemplu cu less sau head.

**Cum aflu dacă fișierul a fost folosit?**  
Căutați numele fișierului în logurile de acces ale serverului web. Cererile cu status 200 și metoda POST arată că fișierul a fost apelat. Adresele IP și momentele corespunzătoare ajută la investigația ulterioară.

**Este suficient să șterg fișierul și să blochez PHP în directorul de upload?**  
Ambele sunt necesare, dar nu suficiente. Clarificați în plus cum a ajuns fișierul acolo, căutați alte componente și schimbați datele de acces. Altfel atacatorul revine pe aceeași cale.

## Surse

- [OWASP Cheat Sheet Series (printre altele File Upload)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: anunțuri de securitate](https://www.php.net/)