Zmysluplné obmedzenie post_max_size a upload_max_filesize

Stručne: post_max_size obmedzuje celkovú veľkosť požiadavky POST, upload_max_filesize jednotlivý súbor; štandardne sú podľa príručky PHP 8M a 2M. Hodnoty musia zodpovedať limitom vo webovom serveri a v aplikácii, inak uploady zlyhávajú bez jasného hlásenia. Do aktualizácie k PHP2Shell php.net radí post_max_size = 8M bez uploadov alebo 32M s uploadmi a upload_max_filesize pod tým, nastavené tak, aby ich aplikácie neprepisovali.

Keď prihlasovací formulár zrazu mlčí

Po prechodných opatreniach k PHP2Shell mnohí administrátori znížili post_max_size. O pár dní neskôr hlási personálne oddelenie, že žiadosti o zamestnanie nechodia. Formulár sa jednoducho znova načíta, chybové hlásenie neexistuje. Dôvod: požiadavka s tromi prílohami PDF bola väčšia ako nová hranica a PHP údaje formulára zahodilo.

Príklad ukazuje základný problém. Limity uploadu pôsobia súčasne na viacerých miestach a každé miesto reaguje inak, keď sa prekročí. Kto reťazec pozná, môže hodnoty nastaviť tak, aby chránili bez narušenia prevádzky. Ako PHP spracúva uploady interne, vysvetľuje Ako PHP spracúva nahrávanie súborov; bezpečné programovanie funkcií uploadu opisuje Bezpečná implementácia nahrávania súborov v PHP.

Reťazec limitov uploadu

Požiadavka prechádza viacerými hranicami, kým ju aplikácia uvidí. Nasledujúce údaje pochádzajú z dokumentácií Nginx, Apache a PHP:

Z toho vyplýva jednoduché pravidlo: upload_max_filesize menší ako post_max_size, post_max_size menší ako hranica vo webovom serveri. Príručka PHP navyše odporúča, aby bol memory_limit vo všeobecnosti väčší ako post_max_size. Počas prechodného opatrenia k PHP2Shell s memory_limit=-1 túto úlohu preberá hranica cez kontajner alebo cgroup; viac v článku Správne nastavenie memory_limit.

post_max_size po PHP2Shell: čo radí php.net

V bezpečnostnej správe z 21. 10. 2026 uvádza php.net pre servery bez aktualizácie nízke limity požiadaviek ako jedno z prechodných opatrení. Znižujú riziko jednotlivých ciest útoku, no výslovne nie sú úplnou ochranou:

1. Bez nahrávania súborov: post_max_size = 8M.
2. S nahrávaním súborov: post_max_size = 32M.
3. V oboch prípadoch: upload_max_filesize držať pod post_max_size.
4. Dodatočne zvážiť: hranice vo webovom serveri alebo proxy pre dekódovanú veľkosť požiadavky, počet vstupných polí, počet častí multipart, počet riadkov hlavičky a hĺbku vnorenia. Podľa php.net musia tieto hranice zachytávať aj požiadavky bez použiteľného údaja Content-Length.

Hodnoty patria tam, kde ich aplikácie nemôžu prepísať. Keďže post_max_size a upload_max_filesize sa podľa príručky dajú meniť na úrovni adresára, mohol by ich inak opäť zvýšiť súbor .user.ini alebo pri mod_php súbor .htaccess:

; Pool FPM webu, s uploadmi (prechod do aktualizácie)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5

Vo webovom serveri nastavte hranicu tesne nad nimi, aby sa príliš veľké požiadavky k PHP vôbec nedostali:

# Nginx, v bloku server alebo location
client_max_body_size 32m;

# Apache, vo VirtualHost: 32 MiB v bajtoch
LimitRequestBody 33554432

Potom znova načítajte všetkých workerov PHP a webový server. Prehľad všetkých prechodných opatrení je pri Okamžité opatrenia, ak ešte nemôžete záplatovať. Či a ako sa dajú požiadavky uploadu navyše filtrovať na proxy, osvetľuje Filtrovanie požiadaviek uploadu na okraji.

Zistenie správnej hodnoty pre váš web

Namiesto plošných hodnôt sa oplatí krátka inventúra. Vypíšte všetky formuláre s uploadmi a zapíšte si najväčší legitímny súbor a najvyšší počet súborov súčasne. Z toho vyplýva potreba: upload_max_filesize pokrýva najväčší jednotlivý súbor, post_max_size súčet všetkých súborov jednej požiadavky plus malú rezervu pre polia formulára.

Ak potreba presahuje 32M, nezodpovedá prechodnému odporúčaniu php.net. To je potom ďalší dôvod, prečo aktualizáciu uprednostniť. Veľké uploady sa dajú vybavovať aj cez samostatnú subdoménu s vlastným poolom, aby si zvyšok webu zachoval úzke hranice.

Po aktualizácii na 8.5.12, 8.4.27, 8.3.36, 8.2.35 alebo potvrdený backport môžete hodnoty opäť prispôsobiť skutočnej potrebe. Štedrejšie, než je nutné, by však nemali byť: každá hranica, ktorá presahuje potrebu, zväčšuje útočnú plochu bez úžitku. Ak web nahrávanie súborov vôbec nepotrebuje, najčistejším riešením je file_uploads = Off.

Správne vyhodnotiť obrazy chýb

Ak uploady zlyhávajú, správanie prezrádza, ktorá hranica sa uplatňuje. Stránka s chybou 413 pochádza z webového servera. Formulár, ktorý sa bez hlásenia znova načíta alebo ohlási „neplatná požiadavka“, poukazuje na prázdne údaje $_POST, teda na post_max_size. Hlásenie aplikácie k jednotlivému súboru zodpovedá upload_max_filesize. A chýbajúce polia vo veľmi veľkých formulároch, napríklad pri variantoch produktov, hovoria v prospech max_input_vars. Chybový protokol PHP obsahuje pri prekročenom post_max_size spravidla upozornenie s veľkosťou požiadavky.

Aby používatelia nezostali bezradní, mala by aplikácia tento prípad rozpoznať. Príručka PHP na to navrhuje jednoduchú cestu: formulár odovzdá značku v adrese, napríklad ?processed=1. Ak značka dorazí, ale $_POST a $_FILES sú prázdne, požiadavka bola príliš veľká a aplikácia môže zobraziť zrozumiteľné hlásenie s povolenou veľkosťou.

Ako konkrétne pomáha PHP SOS?

• Zachytíme všetky cesty uploadu vašich webov a zistíme skutočne potrebné veľkosti.
• Limity webového servera, PHP a poolov nastavíme zosúladene a zablokované proti prepísaniu, vrátane prechodných hodnôt php.net.
• Po prechode otestujeme formuláre, importy a uploady a hodnoty cielene upravíme.
• V rámci sprísnenia servera po aktualizácii hodnoty vrátime na trvalú potrebu.

Časté otázky

Zdroje

• php.net: bezpečnostná správa z 21. 10. 2026
• Príručka PHP: základné nastavenia (post_max_size)
• Dokumentácia Nginx: client_max_body_size
• Dokumentácia Apache: LimitRequestBody