# Filtriranje zahtev za nalaganje na robu: priložnosti in tveganja

> Filtriranje multipart/form-data na proxyju ali v WAF: kdaj neuradni prehodni ukrep pomaga, kaj pokvari in kako ga varno uvedete.

Vir: https://phpsos.de/sl/blog/upload-anfragen-am-rand-filtern/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Filtriranje zahtev za nalaganje na robu pomeni zavrniti zahteve POST vrste `multipart/form-data` na proxyju, spletnem strežniku ali v WAF, če ne gredo na znano pot za nalaganje. Strokovni avtorji to predlagajo kot začasen, neuraden ukrep proti PHP2Shell. Lahko pokvari obrazce in nalaganja ter nikoli ne nadomešča posodobitve. Postopajte v treh korakih: beležite, določite izjeme, šele nato zaprite, s stalnim datumom konca.

## Predlog iz strokovne razprave

Dokler strežnik ni popravljen, upravljavci iščejo vse, kar zmanjšuje tveganje. V strokovni razpravi o PHP2Shell se je pojavil predlog: zahteve POST v obliki `multipart/form-data`, torej v obliki za nalaganje datotek in nekatere obrazce, dovoliti samo tam, kjer jih aplikacija res pričakuje. Vse druge se na proxyju ali v požarnem zidu spletnih aplikacij zavrnejo.

Pomembna je umestitev. Predlog ne izvira od php.net, ampak od strokovnih avtorjev, in je izrecno mišljen kot začasen ukrep. php.net navaja lastne prehodne ukrepe, zbrane pod [Takojšnji ukrepi, če popravka še ne morete namestiti](https://phpsos.de/sl/php2shell/sofortmassnahmen-ohne-patch/). Filter jih lahko dopolni, ne nadomesti.

Tu opisujemo, kako ga uvedete nadzorovano. Podrobnosti o tem, zakaj bi lahko pomagal proti katerim napadom, namerno izpuščamo.

## Kaj filter prinese in kje škoduje

Ideja za njim je zmanjšanje napadalne površine. Večina strani spletnega mesta ne potrebuje nalaganja datotek. Če take zahteve sprejema samo še nekaj znanih poti, velik del možnih poskusov napada PHP sploh ne doseže več.

Slaba stran je enako jasna. Vsaka funkcija, ki pošilja zahteve multipart in je ni na seznamu izjem, odpove. To ne zadeva samo očitnih obrazcev za nalaganje.

| Funkcija | Pogosto uporablja multipart/form-data | Tveganje ob zapori |
|---|---|---|
| Kontaktni in prijavni obrazci s prilogo | da | zahteve se izgubijo |
| Upravljanje medijev v zaledju CMS | da | uredništvo ne more nalagati slik |
| Uvoz izdelkov ali strank | da | vmesniki se tiho pokvarijo |
| Obrazci brez priloge | včasih | odvisno od gradnika obrazcev |
| Vmesniki in povratna sporočila zunanjih storitev | redko, a mogoče | izpad se opazi pozno |

Poleg tega obstaja načelna težava: Cloudflare, ki je sam uvedel zaščitna pravila proti PHP2Shell, opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. Kako obe ravni združite, opisuje [WAF ali posodobitev: zakaj potrebujete oboje](https://phpsos.de/sl/blog/waf-oder-update/).

## Korak 1: najprej beležite, nato zaprite

Preden karkoli blokirate, ugotovite, katere poti sploh prejemajo zahteve multipart. Standardni dnevniki vrste vsebine ne kažejo. Za Nginx zato začasno ustvarite lasten zapisnik:

```nginx
# v bloku http
map $uri $upload_pfad {
    default 0;
    ~^/kontakt/upload\.php$ 1;
    ~^/admin/medien/ 1;
}

map "$request_method:$upload_pfad:$content_type" $multipart_fremd {
    default 0;
    "~*^POST:0:multipart/form-data" 1;
}

log_format multipart '$time_iso8601 $remote_addr "$request" "$content_type" $status';

# v bloku server
# Pozor: access_log v bloku server nadomesti podedovani zapisnik,
# zato tu znova navedite običajni dnevnik.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;
```

Vnosi v `$upload_pfad` so primeri. Začnite s praznim seznamom izjem, nato testni zapisnik pokaže vse multipart POST. Pod Apache enako uspe z okoljsko spremenljivko:

```apache
# v VirtualHost
SetEnvIfNoCase Content-Type "^multipart/form-data" ist_multipart
CustomLog ${APACHE_LOG_DIR}/multipart-test.log combined env=ist_multipart
```

Pustite zapisnik teči nekaj dni, idealno v obdobju, ko so bili aktivni tudi uredništvo, kandidati in vmesniki.

## Korak 2: določite izjeme in zaprite nadzorovano

Iz testnega zapisnika izpeljite poti, ki nalaganja legitimno potrebujejo. Seznam uskladite z odgovornimi: kdo ureja vsebine, kateri obrazci obstajajo, katere storitve pošiljajo podatke?

1. Seznam izjem ustvarite iz zapisnika in poizvedb ter ga vnesite v `$upload_pfad` oziroma v vrstice `RewriteCond`.
2. Filter najprej aktivirajte v testnem okolju ali v mirnem časovnem oknu.
3. Sami preizkusite vse obrazce, nalaganja in poti naročil.
4. Spremljajte dnevnik napak za zavrnjene zahteve (status 403) in seznam po potrebi dopolnite.
5. Določite datum konca: po posodobitvi PHP in ponovnem zagonu vseh delavcev se filter spet odstrani.

V Nginx v bloku strežnika za to dodate zaporo:

```nginx
# v bloku server, po ovrednotenju faze beleženja
if ($multipart_fremd) {
    return 403;
}
```

V Apache nalogo prevzame `mod_rewrite`. Po dokumentaciji Apache se več pogojev poveže z IN:

```apache
RewriteEngine On
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/kontakt/upload\.php$
RewriteCond %{REQUEST_URI} !^/admin/medien/
RewriteRule ^ - [F]
```

Če uporabljate CDN ali oblačni WAF, je isto logiko pogosto mogoče upodobiti kot lastno pravilo. Tudi tam velja: najprej v načinu beleženja, nato zaprite.

> **Pomembno:**
> Filter ni nadomestilo za posodobitev PHP in ni razlog, da bi jo odlagali. PHP2Shell je odpravljen samo s PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ali potrjenim backportom, ki mu sledi ponovni zagon vseh procesov PHP.

## Pravilna umestitev ukrepa

Filter nalaganj sodi v vrsto drugih predlogov, ki trenutno krožijo. Nekateri so smiselni, drugi škodljivi. Pregled, katere nasvete strokovni avtorji zavračajo, na primer blokiranje vseh zahtev s piškotkom seje, daje [Nevarni napačni nasveti za PHP2Shell](https://phpsos.de/sl/blog/gefaehrliche-falschtipps/).

Kako PHP nalaganja obdeluje notranje in zakaj ima pri tem oblika `multipart/form-data` posebno vlogo, pojasnjuje [Kako PHP obdeluje nalaganje datotek](https://phpsos.de/sl/php/datei-uploads-intern/). Za večino podjetij pa najpomembnejši korak ni filter, ampak jasen termin za posodobitev.

## Sklep: orodje za dneve, ne za mesece

Filter nalaganj na robu je tipičen primer zasilnega ukrepa: lahko zmanjša napadalno površino v prehodnem času, vendar ima stranske učinke in nima uradne podpore php.net. Pravilno uporabljen, s fazo beleženja, usklajenim seznamom izjem, preizkusi in stalnim datumom konca, je upravičen. Brez teh korakov tvegate izgubljene prijave, blokirana uredništva in tihe napake vmesnikov.

Odločitev zato sprejmite zavestno in zabeležite, kdo jo je sprejel in kdaj. In imejte v mislih vrstni red: najprej pride posodobitev PHP s ponovnim zagonom vseh delavcev, prehodni ukrepi php.net premostijo čas do tega, filter pa je kvečjemu dodatna plast.

## Kako PHP SOS pomaga konkretno?

- **Ocena razmer:** razjasnimo, ali je filter nalaganj v vaši situaciji sploh smiseln ali je posodobitev mogoča hitreje.
- **Beleženje in ovrednotenje:** vzpostavimo fazo beleženja in seznam izjem izpeljemo iz pravih dostopov.
- **Nadzorovana zapora:** filter aktiviramo, preizkusimo obrazce in poti naročil ter spremljamo zavrnjene zahteve.
- **Čist umik:** v okviru [WAF in virtualnega popravljanja](https://phpsos.de/sl/leistungen/waf-virtuelles-patching/) filter po posodobitvi znova odstranimo.


## Pogosta vprašanja

**Ali je filtriranje zahtev multipart uradno priporočilo php.net?**  
Ne. php.net navaja druge prehodne ukrepe, na primer meje za post_max_size in izklop session.upload_progress. Filtriranje na robu je predlog iz strokovnih prispevkov in je izrecno mišljeno samo kot začasen ukrep.

**Katere funkcije lahko zaradi filtra odpovedo?**  
Vse, kar pošilja datoteke ali obrazce v obliki multipart in ni na vašem seznamu izjem: kontaktni obrazci s prilogo, prijavni obrazci, upravljanje medijev v CMS, funkcije uvoza, nekateri vmesniki in povratna sporočila plačil. Zato pred zaporo pride faza beleženja.

**Ali filter nadomešča posodobitev PHP?**  
Ne. V najboljšem primeru zmanjša napadalno površino v prehodnem času. Cloudflare sam opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. PHP2Shell je odpravljen samo s popravljeno različico PHP in ponovnim zagonom vseh delavcev.

**Ali naj namesto tega blokiram zahteve s PHPSESSID?**  
Ne. Ta kroženi nasvet strokovni avtorji izrecno zavračajo. Ohromi prijave in košarice, ne da bi zagotavljal zanesljivo zaščito.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [Nginx: ngx_http_map_module](https://nginx.org/en/docs/http/ngx_http_map_module.html)
- [Apache: mod_rewrite](https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html)
- [Blog Cloudflare](https://blog.cloudflare.com/)