Validácia a filtrovanie vstupov v PHP pomocou filter_var

Stručne: Vstupy v PHP validujete pomocou filter_var() alebo filter_input_array() a jasných pravidiel pre každé pole: typ, rozsah, dĺžka a povolené hodnoty. Čo nesedí, sa odmietne, nie mlčky prerobí. Validácia je dôležitá pre čisté údaje a menšiu útočnú plochu, nenahrádza však ani Prepared Statements proti SQL injection, ani kódovanie primerané kontextu proti XSS.

Prečo „filtrovať všetko“ nie je koncepcia

V mnohých starších projektoch PHP nájdete na začiatku každého súboru cyklus, ktorý posiela všetky hodnoty z $_GET a $_POST cez čistiacu funkciu. Pôsobí to bezpečne. V praxi to raz odstráni priveľa, napríklad apostrofy v priezviskách, raz primálo, pretože tá istá funkcia má platiť naraz pre SQL, HTML a názvy súborov.

Zmysluplná validácia funguje inak: pre každé pole sa pýta, čo je tam dovolené. Objednané množstvo je celé číslo od 1 po hornú hranicu. Pole zoradenia je jedna z troch pevných hodnôt. Dátum má určitý formát a leží pred iným dátumom alebo po ňom. Všetko ostatné sa odmietne.

OWASP pritom rozlišuje dve úrovne: syntaktickú kontrolu, či má hodnota správny tvar, a sémantickú kontrolu, či dáva v súvislosti zmysel. Obe patria na server; kontroly v prehliadači slúžia len na pohodlné ovládanie.

Ktoré filtre PHP prináša

Rozšírenie Filter je v PHP štandardne obsiahnuté. Najdôležitejšie validačné filtre podľa príručky PHP:

Čistiaci filter FILTER_SANITIZE_STRING je od PHP 8.1 zastaraný. Kto ho ešte používa, mal by validáciu prestaviť na vhodné filtre a pre výstup použiť htmlspecialchars().

filter_var v PHP: poriadna kontrola formulára

Pomocou filter_input_array() sa dá celý formulár skontrolovať jedným krokom voči definícii. Neznáme polia sa pritom neprevezmú:

<?php
declare(strict_types=1);

$regeln = [
    'menge'   => ['filter' => FILTER_VALIDATE_INT,
                  'options' => ['min_range' => 1, 'max_range' => 50]],
    'email'   => FILTER_VALIDATE_EMAIL,
    'agb'     => ['filter' => FILTER_VALIDATE_BOOL, 'flags' => FILTER_NULL_ON_FAILURE],
    'versand' => ['filter' => FILTER_VALIDATE_REGEXP,
                  'options' => ['regexp' => '/^(standard|express)$/']],
];

$daten  = filter_input_array(INPUT_POST, $regeln) ?? [];
$fehler = [];

foreach ($regeln as $feld => $_) {
    if (!array_key_exists($feld, $daten) || $daten[$feld] === false || $daten[$feld] === null) {
        $fehler[] = $feld;
    }
}

if ($fehler !== []) {
    http_response_code(422);
    // vypísať chybové hlásenie pre každé pole, vstupy nespracovať
}

Všimnite si striktné porovnania pomocou ===: platná hodnota 0 alebo prázdny reťazec sa nesmie zamieňať s neúspechom. Prečo sú tu voľné porovnania nebezpečné, vysvetľuje Type Juggling: voľné porovnania ako bezpečnostné riziko. Ako PHP vôbec sprístupňuje údaje požiadavky, opisuje Superglobals: $_GET, $_POST, $_FILES a spol..

Nástrahy pri e-maile, URL a voľných textoch

Niektoré filtre robia menej, než by naznačoval ich názov:

1. URL: FILTER_VALIDATE_URL akceptuje aj iné schémy než http a https. Schému potom skontrolujte pomocou parse_url() voči pevnému zoznamu. Ak sa URL sťahuje zo servera, platia dodatočné pravidlá, pozri Ako zabrániť Server-Side Request Forgery v PHP.
2. E-mailové adresy: filter kontroluje tvar, nie vlastníctvo. Kto si musí byť istý, pošle potvrdzovací odkaz.
3. Voľný text: mená, správy a adresy sa dajú len ťažko zmysluplne obmedziť na znaky. Kontrolujte dĺžku a kódovanie znakov, napríklad pomocou mb_check_encoding($wert, 'UTF-8'), a pri výstupe sa spoliehajte na kódovanie.
4. Regulárne výrazy: bez ^ a $ vzor kontroluje len to, či sa niekde v texte vyskytuje, nie či sedí celá hodnota.
5. Polia namiesto reťazcov: útočník môže namiesto textu poslať pole. Bez kontroly typu to vedie k upozorneniam alebo neočakávanému správaniu.

Ďalšia častá chyba sa týka čísel s významom, napríklad cien, množstiev alebo zliav. To, že hodnota je platné číslo, nehovorí nič o tom, či je v danej súvislosti dovolená. Záporné množstvo, zľava vyššia než hodnota tovaru alebo cena prevzatá z formulára namiesto z databázy sú klasické logické chyby. Ceny, oprávnenia a stavové hodnoty preto vždy patria na server a nikdy do skrytých polí formulára.

JSON, webhooky a importy: validácia mimo formulárov

Mnohé vstupy dnes už nie sú formuláre, ale požiadavky JSON z aplikácií, webhooky od platobných služieb alebo importné súbory od dodávateľov. Aj tu platí: najprv bezpečne načítať, potom skontrolovať. OWASP radí obmedziť veľkosť a hĺbku vnorenia ešte pred načítaním údajov. V PHP časť z toho preberá json_decode() s maximálnou hĺbkou a JSON_THROW_ON_ERROR:

<?php
$roh = file_get_contents('php://input', false, null, 0, 65536); // najviac 64 KB
try {
    $daten = json_decode($roh, true, 16, JSON_THROW_ON_ERROR);
} catch (JsonException) {
    http_response_code(400);
    exit;
}
if (!is_array($daten) || !is_string($daten['bestellnummer'] ?? null)) {
    http_response_code(422);
    exit;
}

Pri webhookoch stojí pred obsahovou kontrolou otázka, či správa skutočne pochádza z uvedenej služby. Ak služba ponúka podpis, skontrolujte ho a porovnajte pomocou hash_equals(). Pri importných súboroch skontrolujte každý riadok ako formulár a pri chybách čisto prerušte, namiesto preberania polovičných záznamov.

Chybové hlásenia by mali uvádzať dotknuté pole, odmietnutú hodnotu by však nemali vracať nefiltrovanú. Inak vznikne na chybovom hlásení samotnom nové miesto výstupu, ktoré sa musí opäť kódovať.

Čo validácia nedokáže

Validácia zmenšuje útočnú plochu, ale podľa OWASP nie je hlavnou obranou proti injection. Priezvisko s apostrofom je platné a napriek tomu sa musí bezpečne dostať do databázy. To sa podarí len pomocou Prepared Statements, ako ukazuje sprievodca Ako zabrániť SQL injection v PHP. A platný text komentára sa stane neškodným až kódovaním primeraným kontextu pri výstupe.

Správne poradie teda znie: pri prijatí validovať, pri spracovaní parametrizovať, pri výstupe kódovať. Pred to patria aj limity veľkosti: požiadavky, ktoré sú oveľa príliš veľké, by webserver a PHP nemali ani spracovať celé. Slúžia na to nastavenia ako post_max_size, ktoré by sa mali po PHP2Shell tak či tak skontrolovať.

Ako konkrétne pomáha PHP SOS?

• Zachytíme všetky vstupy vašej aplikácie: formuláre, rozhrania, uploady, importy a webhooky.
• Pre každé pole určíme, čo je dovolené, a plošné čistiace funkcie nahradíme jasnými kontrolami.
• Preveríme, či sú prístupy do databázy a výstupy zabezpečené nezávisle od validácie.
• Pravidlá zdokumentujeme tak, aby ich váš tím mohol pri nových funkciách dodržiavať ďalej.

Systematickú kontrolu opisuje služba Bezpečnostný audit a penetračný test.

Časté otázky

Zdroje

• Príručka PHP: konštanty filtrov
• OWASP Input Validation Cheat Sheet
• OWASP Top 10