Smisleno ograničiti post_max_size i upload_max_filesize

Ukratko: post_max_size ograničava ukupnu veličinu POST zahtjeva, a upload_max_filesize pojedinu datoteku; zadano je prema PHP priručniku 8M i 2M. Vrijednosti moraju odgovarati granicama u web-poslužitelju i u aplikaciji, inače prijenosi propadaju bez jasne poruke. Do ažuriranja zbog PHP2Shella php.net savjetuje post_max_size = 8M bez prijenosa ili 32M s prijenosima, upload_max_filesize ispod toga, postavljeno tako da ga aplikacije ne mogu nadjačati.

Kad obrazac za prijave odjednom šuti

Nakon prijelaznih mjera za PHP2Shell mnogi su administratori snizili post_max_size. Nekoliko dana kasnije kadrovska služba javlja da prijave više ne stižu. Obrazac se jednostavno iznova učita, poruke o pogrešci nema. Razlog: zahtjev s tri PDF privitka bio je veći od nove granice i PHP je odbacio podatke obrasca.

Primjer pokazuje osnovni problem. Granice prijenosa djeluju na više mjesta istodobno i svako mjesto reagira drukčije kad se prekorači. Tko poznaje lanac, vrijednosti može postaviti tako da štite, a da ne ometaju rad. Kako PHP interno obrađuje prijenose, objašnjava članak Kako PHP obrađuje prijenose datoteka; sigurno programiranje funkcija prijenosa opisuje vodič Sigurno implementirati prijenose datoteka u PHP-u.

Lanac granica prijenosa

Zahtjev prolazi kroz više granica prije nego ga aplikacija vidi. Sljedeći podaci potječu iz dokumentacije Nginxa, Apachea i PHP-a:

Iz toga proizlazi jednostavno pravilo: upload_max_filesize manji od post_max_size, post_max_size manji od granice u web-poslužitelju. PHP priručnik uz to preporučuje da memory_limit općenito bude veći od post_max_size. Tijekom prijelazne mjere za PHP2Shell s memory_limit=-1 tu ulogu preuzima granica putem kontejnera ili cgroupa; više o tome u članku Pravilno postaviti memory_limit.

post_max_size nakon PHP2Shella: što php.net savjetuje

U sigurnosnoj obavijesti od 21. 10. 2026. php.net za poslužitelje bez ažuriranja navodi niske granice zahtjeva kao jednu od prijelaznih mjera. One smanjuju rizik pojedinih putova napada, ali izričito nisu potpuna zaštita:

1. Bez prijenosa datoteka: post_max_size = 8M.
2. S prijenosima datoteka: post_max_size = 32M.
3. U oba slučaja: upload_max_filesize držati ispod post_max_size.
4. Dodatno razmotriti: granice u web-poslužitelju ili proxyju za dekodiranu veličinu zahtjeva, broj ulaznih polja, broj multipart dijelova, broj redaka zaglavlja i dubinu ugniježđivanja. Prema php.net-u te granice moraju obuhvatiti i zahtjeve bez upotrebljivog podatka Content-Length.

Vrijednosti pripadaju tamo gdje ih aplikacije ne mogu nadjačati. Budući da se post_max_size i upload_max_filesize prema priručniku mogu mijenjati na razini direktorija, .user.ini ili kod mod_php-a .htaccess mogli bi ih inače ponovno povisiti:

; FPM pool web-stranice, s prijenosima (prijelazno do ažuriranja)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5

U web-poslužitelju granicu postavite malo iznad, kako prevelik zahtjev uopće ne bi stigao do PHP-a:

# Nginx, u server ili location bloku
client_max_body_size 32m;

# Apache, u VirtualHostu: 32 MiB u bajtovima
LimitRequestBody 33554432

Zatim ponovno učitajte sve PHP workere i web-poslužitelj. Pregled svih prijelaznih mjera nalazi se na stranici Hitne mjere ako još ne možete zakrpati. Mogu li se i kako zahtjevi za prijenos dodatno filtrirati na proxyju, razmatra članak Filtrirati zahtjeve za prijenos na rubu.

Odrediti pravu vrijednost za Vašu web-stranicu

Umjesto paušalnih vrijednosti isplati se kratka inventura. Popišite sve obrasce s prijenosima i zabilježite najveću legitimnu datoteku i najveći broj istodobnih datoteka. Iz toga proizlazi potreba: upload_max_filesize pokriva najveću pojedinačnu datoteku, post_max_size zbroj svih datoteka jednog zahtjeva plus malo rezerve za polja obrasca.

Ako potreba premašuje 32M, ne odgovara prijelaznoj preporuci php.net-a. To je tada dodatni razlog da se ažuriranje provede ranije. Veliki prijenosi mogu se obavljati i putem zasebne poddomene sa zasebnim poolom, kako bi ostatak web-stranice zadržao uske granice.

Nakon ažuriranja na 8.5.12, 8.4.27, 8.3.36, 8.2.35 ili potvrđeni backport vrijednosti možete ponovno uskladiti sa stvarnom potrebom. Ipak ne bi smjele biti velikodušnije nego što je nužno: svaka granica koja premašuje potrebu povećava napadnu površinu bez koristi. Ako web-stranici prijenosi uopće nisu potrebni, file_uploads = Off je najčišće rješenje.

Ispravno tumačiti simptome pogrešaka

Kad prijenosi propadaju, ponašanje otkriva koja granica djeluje. Stranica s pogreškom 413 potječe od web-poslužitelja. Obrazac koji se bez poruke iznova učita ili javlja „nevažeći zahtjev“ upućuje na prazne $_POST podatke, dakle na post_max_size. Poruka aplikacije o pojedinoj datoteci odgovara upload_max_filesize. A polja koja nedostaju u vrlo velikim obrascima, primjerice kod varijanti proizvoda, govore u prilog max_input_vars. PHP zapisnik pogrešaka pri prekoračenom post_max_size u pravilu sadrži upozorenje s veličinom zahtjeva.

Da korisnici ne ostanu bespomoćni, aplikacija bi trebala prepoznati taj slučaj. PHP priručnik za to predlaže jednostavan put: obrazac u adresi prosljeđuje oznaku, primjerice ?processed=1. Ako oznaka stigne, a $_POST i $_FILES su prazni, zahtjev je bio prevelik i aplikacija može prikazati razumljivu poruku s dopuštenom veličinom.

Kako PHP SOS konkretno pomaže?

• Bilježimo sve putove prijenosa na Vašim web-stranicama i utvrđujemo stvarno potrebne veličine.
• Granice web-poslužitelja, PHP-a i poola postavljamo usklađeno i zaključane od nadjačavanja, uključujući prijelazne vrijednosti php.net-a.
• Nakon prijelaza testiramo obrasce, uvoze i prijenose te ciljano prilagođavamo vrijednosti.
• U sklopu ojačavanja poslužitelja nakon ažuriranja vrijednosti vraćamo na trajnu potrebu.

Česta pitanja

Izvori

• php.net: sigurnosna obavijest od 21. 10. 2026.
• PHP priručnik: osnovne postavke (post_max_size)
• Nginx dokumentacija: client_max_body_size
• Apache dokumentacija: LimitRequestBody