# Augšupielādes pieprasījumu filtrēšana malā: iespējas un riski

> multipart/form-data filtrēšana starpniekserverī vai WAF: kad neoficiālais pārejas pasākums palīdz, ko tas sabojā un kā to droši ieviest.

Avots: https://phpsos.de/lv/blog/upload-anfragen-am-rand-filtern/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Augšupielādes pieprasījumu filtrēšana malā nozīmē POST pieprasījumus ar tipu `multipart/form-data` starpniekserverī, tīmekļa serverī vai WAF noraidīt, ja tie nav adresēti zināmam augšupielādes ceļam. Speciālisti to iesaka kā pagaidu, neoficiālu pasākumu pret PHP2Shell. Tas var sabojāt veidlapas un augšupielādes un nekad neaizstāj atjauninājumu. Rīkojieties trijos soļos: protokolēt, noteikt izņēmumus, tikai tad bloķēt, ar noteiktu beigu datumu.

## Priekšlikums no speciālistu diskusijas

Kamēr serveris nav ielāpots, uzturētāji meklē visu, kas samazina risku. Speciālistu diskusijā par PHP2Shell parādījās arī priekšlikums: POST pieprasījumus formātā `multipart/form-data`, tātad failu augšupielādes un dažu veidlapu formātā, atļaut tikai tur, kur lietojumprogramma tos patiešām gaida. Visus pārējos starpniekserverī vai Web Application Firewall noraidīt.

Svarīgs ir ierindojums. Priekšlikums nenāk no php.net, bet no speciālistiem, un tas nepārprotami domāts kā pagaidu pasākums. php.net min savus pārejas pasākumus, apkopotus sadaļā [Tūlītēji pasākumi, ja vēl nevarat ielāpot](https://phpsos.de/lv/php2shell/sofortmassnahmen-ohne-patch/). Filtrs tos var papildināt, nevis aizstāt.

Mēs šeit aprakstām, kā to ieviest kontrolēti. Detaļas par to, kāpēc tas varētu palīdzēt pret kuriem uzbrukumiem, mēs apzināti izlaižam.

## Ko filtrs dod un kur tas kaitē

Doma aiz tā ir uzbrukuma virsmas samazināšana. Lielākajai daļai vietnes lapu failu augšupielādes nav vajadzīgas. Ja tādus pieprasījumus pieņem tikai daži, zināmi ceļi, liela daļa iespējamo uzbrukuma mēģinājumu PHP vairs nemaz nesasniedz.

Otra puse ir tikpat skaidra. Katra funkcija, kas sūta multipart pieprasījumus un nav izņēmumu sarakstā, atsakās. Tas attiecas ne tikai uz acīmredzamām augšupielādes veidlapām.

| Funkcija | Bieži izmanto multipart/form-data | Risks bloķējot |
|---|---|---|
| Kontakta un pieteikumu veidlapas ar pielikumu | jā | pieprasījumi pazūd |
| Mediju pārvaldība CMS aizmugurē | jā | redakcija nevar augšupielādēt attēlus |
| Produktu vai klientu imports | jā | saskarnes lūst klusi |
| Veidlapas bez pielikuma | dažkārt | atkarībā no veidlapu konstruktora |
| Ārējo pakalpojumu saskarnes un atpakaļziņas | reti, bet iespējams | atteice tiek pamanīta vēlu |

Pievienojas principiāla problēma: Cloudflare, kas pats ir ieviesis aizsardzības noteikumus pret PHP2Shell, brīdina, ka noteikumi tikai pēc pieprasījuma datiem nav pietiekami. Kā abus līmeņus domāt kopā, apraksta [WAF vai atjauninājums: kāpēc vajag abus](https://phpsos.de/lv/blog/waf-oder-update/).

## 1. solis: vispirms protokolēt, tad bloķēt

Pirms kaut ko bloķējat, noskaidrojiet, kuri ceļi vispār saņem multipart pieprasījumus. Standarta žurnāli satura tipu nerāda. Nginx tāpēc uz laiku izveidojiet savu protokolu:

```nginx
# http blokā
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';

# server blokā
# Uzmanību: access_log server blokā aizstāj mantoto protokolu,
# tāpēc parasto žurnālu šeit norādīt vēlreiz.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;
```

Ieraksti `$upload_pfad` ir piemēri. Sāciet ar tukšu izņēmumu sarakstu, tad testa protokols parāda visus multipart POST. Apache to pašu panāk ar vides mainīgo:

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

Ļaujiet protokolam darboties dažas dienas, ideālā gadījumā laika posmā, kurā aktīvas bija arī redakcija, kandidāti un saskarnes.

## 2. solis: noteikt izņēmumus un bloķēt kontrolēti

No testa protokola atvasiniet ceļus, kuriem augšupielādes leģitīmi vajadzīgas. Sarakstu salīdziniet ar atbildīgajiem: kurš uztur saturu, kādas veidlapas ir, kuri pakalpojumi sūta datus?

1. Izveidot izņēmumu sarakstu no protokola un jautājumiem un ierakstīt `$upload_pfad` resp. `RewriteCond` rindās.
2. Filtru vispirms aktivizēt testa vidē vai mierīgā laika logā.
3. Pašiem izspēlēt visas veidlapas, augšupielādes un pasūtījuma ceļus.
4. Kļūdu protokolā uzraudzīt noraidītos pieprasījumus (statuss 403) un sarakstu vajadzības gadījumā papildināt.
5. Noteikt beigu datumu: pēc PHP atjauninājuma un visu worker procesu pārstartēšanas filtrs tiek atkal noņemts.

Nginx šim nolūkam server blokā papildiniet bloķēšanu:

```nginx
# server blokā, pēc protokola fāzes izvērtēšanas
if ($multipart_fremd) {
    return 403;
}
```

Apache uzdevumu pārņem `mod_rewrite`. Vairāki nosacījumi saskaņā ar Apache dokumentāciju tiek savienoti ar UN:

```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]
```

Ja izmantojat CDN vai mākoņa WAF, to pašu loģiku bieži var atveidot kā savu noteikumu. Arī tur spēkā: vispirms protokolēšanas režīmā, tad bloķēt.

> **Svarīgi:**
> Filtrs neaizstāj PHP atjauninājumu un nav iemesls to atlikt. PHP2Shell ir novērsta tikai ar PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 vai apstiprinātu backport, kam seko visu PHP procesu pārstartēšana.

## Pasākuma pareiza ierindošana

Augšupielādes filtrs pieder rindā ar citiem priekšlikumiem, kas pašlaik cirkulē. Daži ir saprātīgi, citi kaitīgi. Pārskatu, kurus padomus speciālisti noraida, piemēram, bloķēt visus pieprasījumus ar sesijas sīkdatni, sniedz [Bīstami nepareizie padomi par PHP2Shell](https://phpsos.de/lv/blog/gefaehrliche-falschtipps/).

Kā PHP iekšēji apstrādā augšupielādes un kāpēc formātam `multipart/form-data` tur ir īpaša loma, izskaidro [Kā PHP apstrādā failu augšupielādes](https://phpsos.de/lv/php/datei-uploads-intern/). Lielākajai daļai uzņēmumu svarīgākais solis tomēr nav filtrs, bet skaidrs atjauninājuma termiņš.

## Secinājums: rīks dienām, nevis mēnešiem

Augšupielādes filtrs malā ir tipisks avārijas pasākuma piemērs: tas var samazināt uzbrukuma virsmu pārejas laikā, bet tam ir blakusefekti un nav php.net oficiāla atbalsta. Pareizi lietots, ar protokolēšanas fāzi, saskaņotu izņēmumu sarakstu, testiem un noteiktu beigu datumu, tas ir pamatojams. Bez šiem soļiem jūs riskējat ar pazudušiem pieteikumiem, bloķētām redakcijām un kluseniem saskarņu kļūmēm.

Pieņemiet lēmumu tāpēc apzināti un fiksējiet, kurš to kad pieņēma. Un paturiet prātā secību: vispirms nāk PHP atjauninājums ar visu worker procesu pārstartēšanu, php.net pārejas pasākumi pārlaiž laiku līdz tam, un filtrs ir augstākais papildu slānis.

## Kā PHP SOS palīdz konkrēti?

- **Novērtēt situāciju:** mēs noskaidrojam, vai augšupielādes filtrs jūsu situācijā vispār ir jēgpilns vai atjauninājums ir iespējams ātrāk.
- **Protokolēt un izvērtēt:** mēs ieviešam protokolēšanas fāzi un izņēmumu sarakstu atvasinām no īstiem piekļuvēm.
- **Bloķēt kontrolēti:** mēs aktivizējam filtru, testējam veidlapas un pasūtījuma ceļus un uzraugām noraidītos pieprasījumus.
- **Tīri atcelt:** [WAF un virtuālā ielāpošana](https://phpsos.de/lv/leistungen/waf-virtuelles-patching/) ietvaros mēs pēc atjauninājuma filtru atkal noņemam.


## Biežāk uzdotie jautājumi

**Vai multipart pieprasījumu filtrēšana ir oficiāls php.net ieteikums?**  
Nē. php.net min citus pārejas pasākumus, piemēram, post_max_size robežas un session.upload_progress izslēgšanu. Filtrēšana malā ir priekšlikums no speciālistu rakstiem un nepārprotami domāts tikai kā pagaidu pasākums.

**Kuras funkcijas var atteikt filtra dēļ?**  
Viss, kas sūta failus vai veidlapas multipart formātā un nav jūsu izņēmumu sarakstā: kontaktformas ar pielikumu, pieteikumu veidlapas, mediju pārvaldība CMS, importa funkcijas, dažas saskarnes un maksājumu atpakaļziņas. Tāpēc pirms bloķēšanas nāk protokolēšanas fāze.

**Vai filtrs aizstāj PHP atjauninājumu?**  
Nē. Tas augstākais samazina uzbrukuma virsmu pārejas laikā. Cloudflare pats norāda, ka noteikumi tikai pēc pieprasījuma datiem nav pietiekami. PHP2Shell ir novērsta tikai ar ielāpotu PHP versiju un visu worker procesu pārstartēšanu.

**Vai tā vietā man vajadzētu bloķēt pieprasījumus ar PHPSESSID?**  
Nē. Šo apritē esošo padomu speciālisti nepārprotami noraida. Tas paralizē pieteikšanos un preču groziņus, nedodot uzticamu aizsardzību.

## Avoti

- [php.net: drošības paziņojumi](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)
- [Cloudflare emuārs](https://blog.cloudflare.com/)