Interzicerea execuției PHP în dosarele de upload

Pe scurt: Pentru a interzice execuția PHP în upload-uri, aflați mai întâi toate dosarele în care are voie să scrie PHP, apoi blocați în fiecare dintre ele execuția scripturilor în configurația serverului, nu prin .htaccess. În Nginx, blocarea trebuie să se aplice înaintea blocului PHP general, în Apache aparține VirtualHost-ului cu AllowOverride None. security.limit_extensions = .php în pool-ul FPM și un test cu un fișier inofensiv încheie lucrarea.

De ce contează tocmai acum dosarele de upload

După o vulnerabilitate critică precum PHP2Shell, atacatorii rareori vor să execute cod o singură dată. Ei vor să revină, chiar dacă serverul este ulterior patchuit. Cea mai simplă cale pentru aceasta este un webshell: un mic fișier PHP, depus într-un dosar scriibil și apelat ulterior prin browser.

Un patch nu elimină un astfel de fișier. Cine a fost online nepatchuit începând cu 20 octombrie 2026 ar trebui de aceea nu doar să actualizeze, ci și să verifice dacă undeva se află fișiere PHP noi și să împiedice pe viitor executarea lor. Cum interpretați descoperirile descrie Fișiere PHP în dosarul de upload: interpretarea corectă a descoperirilor.

Blocarea execuției se aplică la a doua condiție. Ea nu împiedică depunerea unui fișier, dar împiedică serverul să îl trateze ca program.

Mai întâi inventarul: unde are voie PHP să scrie?

Majoritatea ghidurilor menționează doar dosarul de upload. În practică, o aplicație PHP scrie în mult mai multe locuri. Fiecare dintre ele, dacă este accesibil prin serverul web, are nevoie de blocare.

Ce dosare sunt acestea pe serverul dumneavoastră arată o căutare cu drepturile utilizatorului de execuție. Ea nu modifică nimic:

# Toate dosarele din /var/www în care utilizatorul PHP are voie să scrie
# (adaptați utilizatorul: www-data, nginx, apache sau utilizatorul propriu al pool-ului)
sudo -u www-data find /var/www -type d -writable 2>/dev/null | sort
# Există deja fișiere PHP în aceste dosare?
sudo -u www-data find /var/www -type d -writable -print0 2>/dev/null \
  | xargs -0 -I{} find {} -maxdepth 1 -type f -iname "*.ph*" 2>/dev/null

Dacă prima căutare returnează întregul webroot, codul programului aparține utilizatorului de execuție. Ar trebui să schimbați acest lucru înainte, așa cum descrie ghidul Drepturile de fișiere pe serverul web. Altfel nu există niciun dosar care să nu trebuiască blocat.

Interzicerea execuției PHP în upload-uri: Nginx

La Nginx decide ordinea. Potrivit documentației Nginx, expresiile regulate sunt verificate în ordinea din fișierul de configurare, iar prima potrivire câștigă. Dacă blocul general location ~ \.php$ se află înaintea blocării dumneavoastră, fișierul este executat. Un location simplu cu prefix, fără ^~, nu protejează din același motiv.

Sigură este o expresie regulată pentru toate dosarele blocate, plasată înaintea blocului PHP. Ea acoperă și extensiile rar folosite:

server {
    # ... configurația de bază ...

    # 1. Blocarea dosarelor scriibile, TREBUIE să fie înaintea blocului PHP
    location ~* ^/(uploads|media|cache|tmp|export)/.*\.(php\d?|phtml|phar|pht|phps)$ {
        deny all;
    }

    # 2. Blocul PHP general: se transmit doar fișierele existente
    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/seite1.sock;
    }
}

Adaptați numele dosarelor la inventarul dumneavoastră. La aplicațiile cu un singur punct de intrare, calea printr-o listă de permisiuni este și mai puternică; tiparul îl arată Configurarea sigură a Nginx pentru PHP.

Apache și PHP-FPM: blocarea la locul potrivit

În Apache, blocarea aparține configurației serverului sau VirtualHost-ului. Un .htaccess în dosarul de upload este nepotrivit, pentru că îl poate modifica oricine are voie să scrie acolo. Pentru întregul webroot se aplică de aceea AllowOverride None. Potrivit documentației Apache, AllowOverride este permis doar în blocuri <Directory> fără expresii regulate, deci îl stabiliți la webroot, iar blocarea prin <DirectoryMatch> dedesubt:

<Directory /var/www/seite1/public>
    AllowOverride None
    Require all granted
</Directory>

<DirectoryMatch "^/var/www/seite1/public/(uploads|media|cache|tmp|export)/">
    <FilesMatch "\.(php\d?|phtml|phar|pht|phps)$">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

Dacă rulează încă mod_php, completați în același bloc php_admin_flag engine off. La PHP-FPM acționează o a doua barieră în pool: security.limit_extensions stabilește ce extensii execută FPM, de fapt. Potrivit manualului PHP, valoarea implicită este .php .phar; se recomandă limitarea la .php.

; în pool, de ex. /etc/php/8.3/fpm/pool.d/seite1.conf
security.limit_extensions = .php

Testarea cu un fișier inofensiv

Dacă blocarea funcționează arată doar un test. Depuneți pe scurt în fiecare dosar blocat un fișier care afișează doar un text, apelați-l prin domeniu și ștergeți-l apoi.

1. Verificați configurația: nginx -t respectiv apachectl configtest, apoi reîncărcați.
2. Creați fișierul de test, de exemplu uploads/sperrtest.php, cu conținutul <?php echo 'ausgefuehrt';.
3. Apelați-l cu curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/uploads/sperrtest.php. Se așteaptă 403.
4. Dacă apare în schimb 200 și textul „ausgefuehrt”, blocarea nu funcționează. Verificați configurația și ordinea.
5. Ștergeți fișierul de test și repetați testul pentru fiecare dosar și fiecare site.

Cum se construiesc sigur funcțiile de upload în cod, cu verificarea tipului și depunerea în afara webroot-ului, găsiți în ghidul Implementarea sigură a încărcărilor de fișiere în PHP.

Concluzie: scrierea da, execuția nu

Blocarea execuției în dosarele scriibile este una dintre cele mai eficiente măsuri individuale împotriva ușilor dosnice durabile. Costă câteva rânduri de configurație și nu strică nimic la aplicațiile construite curat. Trei lucruri sunt decisive: un inventar complet, în loc de doar dosarul evident de upload, ordinea corectă în Nginx respectiv nivelul corect în Apache și un test real cu un fișier inofensiv.

Completat cu proprietari separați pentru codul programului, security.limit_extensions în pool și o căutare regulată de fișiere PHP noi, rezultă o stare în care un fișier depus este supărător, dar aproape inutilizabil. Asta nu înlocuiește nici actualizarea, nici căutarea urmelor, dar le ia atacatorilor una dintre cele mai importante unelte.

Cum ajută PHP SOS concret?

• Inventar: Stabilim toate dosarele scriibile pentru fiecare site și le verificăm pentru fișiere PHP existente.
• Stabilirea blocărilor: Introducem blocările de execuție în Nginx, Apache și PHP-FPM, în ordinea corectă și fără dependență de .htaccess.
• Testare: Verificăm fiecare blocare cu un fișier inofensiv și documentăm rezultatul.
• Curățare: La descoperiri preluăm conservarea urmelor și eliminarea malware-ului.

Întrebări frecvente

Surse

• Nginx: alegerea blocurilor location
• Apache: funcții de bază (AllowOverride, FilesMatch)
• Manualul PHP: configurația FPM (security.limit_extensions)
• OWASP Cheat Sheets (File Upload)