Begræns post_max_size og upload_max_filesize fornuftigt

Kort sagt: post_max_size begrænser den samlede størrelse af en POST-forespørgsel, upload_max_filesize den enkelte fil; standarderne er ifølge PHP-manualen 8M og 2M. Værdierne skal passe til grænserne i webserveren og i applikationen, ellers mislykkes uploads uden tydelig meddelelse. Indtil PHP2Shell-opdateringen råder php.net til post_max_size = 8M uden uploads eller 32M med uploads, upload_max_filesize derunder, sat så applikationer ikke overskriver det.

Når ansøgningsformularen pludselig tier

Efter overgangsforanstaltningerne til PHP2Shell har mange administratorer sænket post_max_size. Få dage senere melder personaleafdelingen, at ansøgninger ikke længere kommer frem. Formularen genindlæser bare, en fejlmeddelelse er der ikke. Årsagen: Forespørgslen med tre PDF-bilag var større end den nye grænse, og PHP har kasseret formulardataene.

Eksemplet viser grundproblemet. Upload-grænser virker flere steder samtidig, og hvert sted reagerer forskelligt, når det overskrides. Den, der kender kæden, kan sætte værdierne, så de beskytter uden at forstyrre driften. Hvordan PHP behandler uploads internt, forklarer Sådan behandler PHP filuploads; den sikre programmering af upload-funktioner beskriver Gennemfør filuploads i PHP sikkert.

Kæden af upload-grænser

En forespørgsel passerer flere grænser, før applikationen ser den. Oplysningerne nedenfor stammer fra dokumentationen til Nginx, Apache og PHP:

Heraf følger en enkel regel: upload_max_filesize mindre end post_max_size, post_max_size mindre end grænsen i webserveren. PHP-manualen anbefaler desuden, at memory_limit generelt er større end post_max_size. Under PHP2Shell-overgangsforanstaltningen med memory_limit=-1 overtager grænsen via container eller cgroup den rolle; mere herom under Sæt memory_limit rigtigt.

post_max_size efter PHP2Shell: hvad php.net råder til

I sikkerhedsmeddelelsen af 21.10.2026 nævner php.net for servere uden opdatering lave forespørgselsgrænser som en af overgangsforanstaltningerne. De mindsker risikoen ved enkelte angrebsveje, men er udtrykkeligt ingen fuldstændig beskyttelse:

1. Uden filuploads: post_max_size = 8M.
2. Med filuploads: post_max_size = 32M.
3. I begge tilfælde: Hold upload_max_filesize under post_max_size.
4. Overvej desuden: Grænser i webserveren eller proxyen for den afkodede forespørgselsstørrelse, antallet af inputfelter, antallet af multipart-dele, antallet af headerlinjer og indlejringsdybden. Ifølge php.net skal disse grænser også omfatte forespørgsler uden anvendelig Content-Length-angivelse.

Værdierne hører hjemme dér, hvor applikationer ikke kan overskrive dem. Fordi post_max_size og upload_max_filesize ifølge manualen kan ændres på mappeniveau, kunne en .user.ini eller ved mod_php en .htaccess ellers hæve dem igen:

; Websitets FPM-pool, med uploads (overgang indtil opdateringen)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5

I webserveren trækker I grænsen lige over, så for store forespørgsler slet ikke når frem til PHP:

# Nginx, i server- eller location-blokken
client_max_body_size 32m;

# Apache, i VirtualHost: 32 MiB i bytes
LimitRequestBody 33554432

Genindlæs derefter alle PHP-workers og webserveren. Oversigten over alle overgangsforanstaltninger står under Akutforanstaltninger, hvis I endnu ikke kan patche. Om og hvordan upload-forespørgsler desuden kan filtreres ved proxyen, belyser Filtrér upload-forespørgsler i kanten.

Find den rigtige værdi til jeres website

I stedet for generelle værdier er en kort beholdningsopgørelse umagen værd. Opregn alle formularer med uploads, og notér den største legitime fil og det højeste antal samtidige filer. Heraf fremgår behovet: upload_max_filesize dækker den største enkeltfil, post_max_size summen af alle filer i en forespørgsel plus lidt reserve til formularfelter.

Ligger behovet over 32M, passer det ikke til php.nets overgangsanbefaling. Så er det endnu en grund til at fremskynde opdateringen. Store uploads kan også afvikles via et eget subdomæne med egen pool, så det øvrige website beholder snævre grænser.

Efter opdateringen til 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en bekræftet backport kan I igen rette værdierne efter det faktiske behov. Rundhåndere end nødvendigt bør de alligevel ikke være: Hver grænse, der går ud over behovet, forøger angrebsfladen uden nytte. Har et website slet ikke brug for uploads, er file_uploads = Off den reneste løsning.

Tolk fejlbilleder rigtigt

Når uploads mislykkes, afslører adfærden, hvilken grænse der virker. En side med fejl 413 stammer fra webserveren. En formular, der genindlæser uden meddelelse eller melder "ugyldig forespørgsel", peger på tomme $_POST-data, altså post_max_size. En meddelelse fra applikationen om en enkelt fil passer til upload_max_filesize. Og manglende felter i meget store formularer, f.eks. ved produktvarianter, taler for max_input_vars. PHP-fejllogget indeholder ved overskredet post_max_size som regel en advarsel med forespørgslens størrelse.

For at brugerne ikke står rådvilde tilbage, bør applikationen genkende tilfældet. PHP-manualen foreslår en enkel vej: Formularen overfører en markør i adressen, f.eks. ?processed=1. Kommer markøren frem, men $_POST og $_FILES er tomme, var forespørgslen for stor, og applikationen kan vise en forståelig meddelelse med den tilladte størrelse.

Hvordan hjælper PHP SOS konkret?

• Vi registrerer alle upload-veje på jeres websites og finder ud af de faktisk nødvendige størrelser.
• Vi sætter webserver-, PHP- og poolgrænser konsistent og låst mod overskrivning, inklusive php.nets overgangsværdier.
• Vi tester formularer, importer og uploads efter omstillingen og tilpasser værdier målrettet.
• Inden for rammerne af serverhærdningen fører vi værdierne efter opdateringen tilbage til det varige behov.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelse af 21.10.2026
• PHP-manual: Kerneindstillinger (post_max_size)
• Nginx-dokumentation: client_max_body_size
• Apache-dokumentation: LimitRequestBody