Limitarea rezonabilă a post_max_size și upload_max_filesize

Pe scurt: post_max_size limitează dimensiunea totală a unei cereri POST, upload_max_filesize fișierul individual; potrivit manualului PHP, valorile implicite sunt 8M și 2M. Valorile trebuie să se potrivească cu limitele din serverul web și din aplicație, altfel încărcările eșuează fără mesaj clar. Până la actualizarea PHP2Shell, php.net recomandă post_max_size = 8M fără încărcări sau 32M cu încărcări, upload_max_filesize sub acestea, stabilite astfel încât aplicațiile să nu le suprascrie.

Când formularul de candidatură tace brusc

După măsurile provizorii pentru PHP2Shell, mulți administratori au redus post_max_size. Câteva zile mai târziu, departamentul de resurse umane raportează că nu mai ajung candidaturile. Formularul pur și simplu se reîncarcă, fără niciun mesaj de eroare. Motivul: cererea cu trei atașamente PDF a fost mai mare decât noua limită, iar PHP a eliminat datele formularului.

Exemplul arată problema de fond. Limitele de upload acționează simultan în mai multe locuri, iar fiecare loc reacționează diferit când este depășit. Cine cunoaște lanțul poate stabili valorile astfel încât să protejeze fără a perturba activitatea. Cum procesează PHP intern încărcările explică Cum procesează PHP încărcările de fișiere; programarea sigură a funcțiilor de upload o descrie Implementarea sigură a încărcărilor de fișiere în PHP.

Lanțul limitelor de upload

O cerere trece prin mai multe limite înainte ca aplicația să o vadă. Datele următoare provin din documentațiile Nginx, Apache și PHP:

De aici rezultă o regulă simplă: upload_max_filesize mai mic decât post_max_size, post_max_size mai mic decât limita din serverul web. Manualul PHP recomandă, în plus, ca memory_limit să fie, în general, mai mare decât post_max_size. În timpul măsurii provizorii PHP2Shell cu memory_limit=-1, acest rol îl preia limita prin container sau cgroup; mai multe la Setarea corectă a memory_limit.

post_max_size după PHP2Shell: ce recomandă php.net

În anunțul de securitate din 21.10.2026, php.net indică, pentru serverele fără actualizare, limite scăzute ale cererilor drept una dintre măsurile provizorii. Ele reduc riscul unor căi de atac individuale, dar nu sunt în mod explicit o protecție completă:

1. Fără încărcări de fișiere: post_max_size = 8M.
2. Cu încărcări de fișiere: post_max_size = 32M.
3. În ambele cazuri: păstrați upload_max_filesize sub post_max_size.
4. Luați în considerare suplimentar: limite în serverul web sau în proxy pentru dimensiunea decodată a cererii, numărul câmpurilor de intrare, numărul părților multipart, numărul liniilor de antet și adâncimea de imbricare. Potrivit php.net, aceste limite trebuie să cuprindă și cererile fără o indicație utilizabilă Content-Length.

Valorile aparțin unde aplicațiile nu le pot suprascrie. Deoarece, potrivit manualului, post_max_size și upload_max_filesize pot fi modificate la nivel de director, un .user.ini sau, la mod_php, un .htaccess le-ar putea ridica din nou:

; Pool-ul FPM al site-ului, cu încărcări (tranziție până la actualizare)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5

În serverul web trageți limita puțin mai sus, pentru ca cererile prea mari să nu mai ajungă deloc la PHP:

# Nginx, în blocul server sau location
client_max_body_size 32m;

# Apache, în VirtualHost: 32 MiB în octeți
LimitRequestBody 33554432

Apoi reîncărcați toți workerii PHP și serverul web. Prezentarea tuturor măsurilor provizorii se află la Măsuri imediate dacă nu puteți încă aplica patchul. Dacă și cum pot fi filtrate suplimentar cererile de upload la proxy analizează Filtrarea cererilor de upload la margine.

Stabilirea valorii potrivite pentru site-ul dumneavoastră

În locul unor valori generale merită o scurtă inventariere. Listați toate formularele cu încărcări și notați cel mai mare fișier legitim și cel mai mare număr de fișiere simultane. De aici rezultă necesarul: upload_max_filesize acoperă cel mai mare fișier individual, post_max_size suma tuturor fișierelor unei cereri plus o mică rezervă pentru câmpurile de formular.

Dacă necesarul depășește 32M, el nu se potrivește cu recomandarea provizorie de la php.net. Atunci este un motiv în plus de a devansa actualizarea. Încărcările mari pot fi tratate și printr-un subdomeniu propriu, cu pool propriu, pentru ca restul site-ului să păstreze limite strânse.

După actualizarea la 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau la un backport confirmat, puteți alinia din nou valorile la necesarul real. Totuși, ele nu ar trebui să fie mai generoase decât este nevoie: orice limită care depășește necesarul mărește suprafața de atac fără beneficiu. Dacă un site nu are nevoie deloc de încărcări, file_uploads = Off este cea mai curată soluție.

Interpretarea corectă a tiparelor de erori

Când încărcările eșuează, comportamentul trădează care limită se aplică. O pagină cu eroarea 413 provine de la serverul web. Un formular care se reîncarcă fără mesaj sau raportează „cerere nevalidă” indică date $_POST goale, deci post_max_size. Un mesaj al aplicației despre un singur fișier se potrivește cu upload_max_filesize. Iar câmpurile lipsă în formulare foarte mari, de exemplu la variante de produs, indică max_input_vars. Jurnalul de erori PHP conține, de regulă, la depășirea post_max_size, un avertisment cu dimensiunea cererii.

Pentru ca utilizatorii să nu rămână descumpăniți, aplicația ar trebui să recunoască acest caz. Manualul PHP sugerează în acest scop o cale simplă: formularul transmite un marker în adresă, de exemplu ?processed=1. Dacă markerul ajunge, dar $_POST și $_FILES sunt goale, cererea a fost prea mare, iar aplicația poate afișa un mesaj ușor de înțeles, cu dimensiunea admisă.

Cum ajută PHP SOS concret?

• Inventariem toate căile de upload ale site-urilor dumneavoastră și stabilim dimensiunile necesare în realitate.
• Stabilim coerent limitele serverului web, ale PHP și ale pool-ului, blocate împotriva suprascrierii, inclusiv valorile provizorii de la php.net.
• Testăm formularele, importurile și încărcările după trecere și ajustăm țintit valorile.
• În cadrul securizării serverului readucem valorile, după actualizare, la necesarul permanent.

Întrebări frecvente

Surse

• php.net: anunț de securitate din 21.10.2026
• Manualul PHP: setări Core (post_max_size)
• Documentația Nginx: client_max_body_size
• Documentația Apache: LimitRequestBody