Upload-pyyntöjen suodatus reunalla: mahdollisuudet ja riskit

Lyhyesti: Upload-pyyntöjen suodatus reunalla tarkoittaa tyyppiä multipart/form-data olevien POST-pyyntöjen hylkäämistä välityspalvelimessa, verkkopalvelimessa tai WAF:ssa, jos ne eivät kohdistu tunnettuun upload-polkuun. Asiantuntijakirjoittajat ehdottavat tätä tilapäisenä, epävirallisena toimenpiteenä PHP2Shelliä vastaan. Se voi rikkoa lomakkeita ja latauksia eikä koskaan korvaa päivitystä. Edetkää kolmessa vaiheessa: kirjatkaa lokiin, määrittäkää poikkeukset, vasta sitten estäkää, kiinteällä päättymispäivällä.

Ehdotus ammattikeskustelusta

Kunnes palvelin on päivitetty, ylläpitäjät etsivät kaikkea, mikä vähentää riskiä. PHP2Shelliä koskevassa ammattikeskustelussa esitettiin ehdotus: sallitaan multipart/form-data -muotoiset POST-pyynnöt, eli tiedostolatausten ja joidenkin lomakkeiden muoto, enää vain siellä, missä sovellus todella odottaa niitä. Kaikki muut hylätään välityspalvelimessa tai Web Application Firewallissa.

Tärkeää on asiayhteys. Ehdotus ei ole php.net:ltä vaan asiantuntijakirjoittajilta, ja se on nimenomaisesti tarkoitettu tilapäiseksi toimenpiteeksi. php.net nimeää omat siirtymäajan toimenpiteensä, jotka on koottu kohtaan Pikatoimet, jos ette voi vielä päivittää. Suodatin voi täydentää niitä, ei korvata.

Kuvaamme tässä, miten otatte sen käyttöön hallitusti. Yksityiskohdat siitä, miksi se voisi auttaa mitäkin hyökkäyksiä vastaan, jätämme tietoisesti pois.

Mitä suodatin saa aikaan ja missä se vahingoittaa

Ajatus sen takana on hyökkäyspinta-alan pienentäminen. Useimmat verkkosivuston sivut eivät tarvitse tiedostolatauksia. Kun vain muutama tunnettu polku ottaa tällaisia pyyntöjä vastaan, suuri osa mahdollisista hyökkäysyrityksistä ei enää pääse PHP:lle lainkaan.

Kääntöpuoli on yhtä selvä. Jokainen toiminto, joka lähettää multipart-pyyntöjä ja puuttuu poikkeuslistalta, lakkaa toimimasta. Se koskee muitakin kuin ilmeisiä upload-lomakkeita.

Lisäksi on periaatteellinen ongelma: Cloudflare, joka on itse ottanut käyttöön suojasääntöjä PHP2Shelliä vastaan, varoittaa, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä. Miten ajattelette molemmat tasot yhdessä, kuvaa WAF vai päivitys: miksi tarvitsette molemmat.

Vaihe 1: ensin kirjaus lokiin, sitten esto

Ennen kuin estätte mitään, selvittäkää, mitkä polut ylipäätään saavat multipart-pyyntöjä. Vakiolokit eivät näytä sisältötyyppiä. Nginxille luotte siksi tilapäisesti oman lokin:

# http-lohkossa
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-lohkossa
# Huom: access_log server-lohkossa korvaa peritty lokin,
# siksi normaali loki on annettava tässä uudelleen.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;

$upload_pfad-merkinnät ovat esimerkkejä. Aloittakaa tyhjällä poikkeuslistalla, jolloin testiloki näyttää kaikki multipart-POST-pyynnöt. Apachella sama onnistuu ympäristömuuttujalla:

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

Antakaa lokin pyöriä muutaman päivän, mieluiten ajanjakson yli, jolloin myös toimitus, hakijat ja rajapinnat ovat olleet aktiivisia.

Vaihe 2: poikkeusten määrittäminen ja hallittu esto

Testilokista johdatte polut, jotka tarvitsevat latauksia oikeutetusti. Täsmäyttäkää lista vastuuhenkilöiden kanssa: kuka ylläpitää sisältöjä, mitä lomakkeita on, mitkä palvelut lähettävät tietoja?

1. Laatikaa poikkeuslista lokista ja kyselyistä ja kirjatkaa se kohtaan $upload_pfad tai RewriteCond-riveille.
2. Aktivoikaa suodatin ensin testiympäristössä tai rauhallisessa aikaikkunassa.
3. Käykää itse läpi kaikki lomakkeet, lataukset ja tilausreitit.
4. Seuratkaa virhelokia hylättyjen pyyntöjen (tila 403) varalta ja täydentäkää listaa tarvittaessa.
5. Määrittäkää päättymispäivä: PHP-päivityksen ja kaikkien workerien uudelleenkäynnistyksen jälkeen suodatin poistetaan taas.

Nginxissä lisäätte eston palvelinlohkoon:

# server-lohkossa, lokivaiheen arvioinnin jälkeen
if ($multipart_fremd) {
    return 403;
}

Apachessa tehtävän hoitaa mod_rewrite. Apachen dokumentaation mukaan useat ehdot yhdistetään JA-operaatiolla:

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]

Jos käytätte CDN:ää tai pilvi-WAF:ia, saman logiikan voi usein toteuttaa omana sääntönä. Sielläkin pätee: ensin lokitilassa, sitten esto.

Toimenpiteen oikea sijoittaminen

Upload-suodatin kuuluu muiden tällä hetkellä kiertävien ehdotusten joukkoon. Jotkin ovat järkeviä, toiset vahingollisia. Yleiskuvan siitä, mitkä vinkit asiantuntijakirjoittajat torjuvat, esimerkiksi kaikkien sessioevästeellisten pyyntöjen estämisen, antaa Vaaralliset virheelliset vinkit PHP2Shellistä.

Miten PHP käsittelee latauksia sisäisesti ja miksi multipart/form-data -muodolla on siinä erityinen rooli, selittää Miten PHP käsittelee tiedostolataukset. Useimmille yrityksille tärkein askel ei kuitenkaan ole suodatin vaan selvä päivämäärä päivitykselle.

Yhteenveto: työkalu päiviksi, ei kuukausiksi

Upload-suodatin reunalla on tyypillinen esimerkki hätätoimenpiteestä: se voi pienentää hyökkäyspintaa siirtymäaikana, mutta sillä on sivuvaikutuksia eikä virallista tukea php.net:ltä. Oikein käytettynä, lokivaiheen, sovitun poikkeuslistan, testien ja kiinteän päättymispäivän kanssa, se on perusteltavissa. Ilman näitä vaiheita riskeeraatte kadonneet hakemukset, tukkeutuneet toimitukset ja hiljaiset rajapintavirheet.

Tehkää päätös siksi tietoisesti ja kirjatkaa, kuka sen teki ja milloin. Ja pitäkää järjestys mielessä: ensin tulee PHP-päivitys kaikkien workerien uudelleenkäynnistyksellä, php.net:n siirtymäajan toimenpiteet kattavat ajan siihen asti, ja suodatin on korkeintaan lisäkerros.

Miten PHP SOS auttaa konkreettisesti?

• Tilanteen arviointi: Selvitämme, onko upload-suodatin tilanteessanne ylipäätään järkevä vai onko päivitys nopeammin mahdollinen.
• Kirjaus ja arviointi: Perustamme lokivaiheen ja johdamme poikkeuslistan todellisista käytöistä.
• Hallittu esto: Aktivoimme suodattimen, testaamme lomakkeet ja tilausreitit ja valvomme hylättyjä pyyntöjä.
• Siisti purkaminen: WAF:n ja virtuaalisen korjauksen yhteydessä poistamme suodattimen päivityksen jälkeen.

Usein kysytyt kysymykset

Lähteet

• php.net: tietoturvailmoitukset
• Nginx: ngx_http_map_module
• Apache: mod_rewrite
• Cloudflare-blogi