A PHP beépített biztonsági függvényei

Röviden: A PHP a leggyakoribb biztonsági feladatokhoz kész, ellenőrzött függvényeket hoz: password_hash() a jelszavakhoz, random_bytes() és random_int() a tokenekhez, htmlspecialchars() a cross-site scripting ellen, előkészített lekérdezések PDO-val az SQL-injekció ellen, hash_equals() a biztonságos összehasonlításokhoz, és a Sodium bővítmény a kriptográfiához. Aki ezeket az építőelemeket következetesen használja, az alkalmazásrések többségét elkerüli. A PHP-értelmező hibái ellen, mint a PHP2Shellnél, nem segítenek; ott csak a frissítés segít.

Miért vannak beépített PHP biztonsági függvények?

A biztonsági kód saját megírása hibára hajlamos. Egy saját jelszó-hash, egy házilag épített tokengenerátor vagy egy kézzel összeeszkábált szűrő a HTML-kimenetekhez gyakran helyesnek látszik, mégsem az. A beépített függvények dokumentáltak, tesztelték őket, és a PHP-frissítésekkel gondozzák őket.

A döntéshozók számára ez azt jelenti: ne azt kérdezze az ügynökségétől vagy a fejlesztőcsapatától, hogy a biztonsági függvényeket maguk építették-e, hanem azt, hogy a nyelv szabványos függvényeit használják-e. A táblázat áttekintést ad.

Jelszavak és tokenek

A password_hash() sózott hasht hoz létre, a password_verify() ellenőrzi. A PASSWORD_DEFAULT esetén a PHP jelenleg bcryptet használ; a PHP 8.4 óta az alapértelmezett költségtényező a kézikönyv szerint 12, nem 10. Mivel az alapértelmezett algoritmus változhat, a kézikönyv 255 karakteres adatbázis-oszlopot ajánl. A bcrypt a jelszavakat 72 bájt után levágja, amit nagyon hosszú jelmondatoknál figyelembe kell venni.

<?php
// Regisztráció
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Bejelentkezés, a régi hashek automatikus frissítésével együtt
if (password_verify($eingabe, $hash)) {
    if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
        $hash = password_hash($eingabe, PASSWORD_DEFAULT); // újra mentendő
    }
}

// Token a jelszó-visszaállító linkhez
$token = bin2hex(random_bytes(32));

Titkok, például egy aláírás összehasonlításához a hash_equals() használandó. A === szerinti normál összehasonlítás a kézikönyv szerint a futásidőn keresztül elárulhatja, hogy két érték melyik helytől kezdve tér el. Részletesebben: Jelszavak biztonságos tárolása PHP-ban és biztonságos véletlenszámok és tokenek.

A kimenetek maszkolása és az adatbázis biztonságos lekérdezése

A cross-site scripting akkor keletkezik, ha a felhasználói bemenetek szűretlenül kerülnek a HTML-be. A htmlspecialchars() a speciális karaktereket HTML-entitásokká alakítja. A PHP 8.1 óta az alapértelmezett jelzők ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401; korábban az egyszeres idézőjeleket nem alakították át. Aki régebbi verziókat is támogatni kényszerül, kifejezetten adja meg a jelzőket.

Az SQL-injekciót az előkészített lekérdezések akadályozzák meg. Az értékeket az SQL-szövegtől elkülönítve továbbítják, és nem tudják módosítani a lekérdezést:

<?php
$stmt = $pdo->prepare('SELECT id, name FROM kunden WHERE email = :email');
$stmt->execute(['email' => $email]);
$kunde = $stmt->fetch();

echo htmlspecialchars($kunde['name'] ?? '', ENT_QUOTES, 'UTF-8');

A részletek a Cross-site scripting megelőzése PHP-ban oldalon és az SQL-injekcióról szóló oldalon találhatók.

A bemenetek ellenőrzése egy második, különálló lépés. A filter_var() megállapítja, hogy egy érték érvényes formátumú-e, például e-mail-cím vagy megengedett tartományba eső egész szám. Ez azonban nem helyettesíti a kimenet maszkolását és az előkészített lekérdezést, mert formailag érvényes értékek is tartalmazhatnak speciális karaktereket.

A titkok távoltartása a hibaüzenetektől

Alulértékelt adatszivárgás a stacktrace. Ha egy függvényben hiba lép fel, a PHP naplózza a hívási láncot az argumentumokkal együtt. Ha ott jelszó vagy API-kulcs áll, az a naplóba kerül. A PHP 8.2 óta a #[\SensitiveParameter] attribútum megjelöli az ilyen paramétereket; az értékük a trace-ben ezután csak SensitiveParameterValue objektumként jelenik meg.

<?php
function anmelden(string $benutzer, #[\SensitiveParameter] string $passwort): bool
{
    // ... ellenőrzés ...
    throw new RuntimeException('Datenbank nicht erreichbar');
}

A kézikönyv egyik megjegyzése szerint az attribútum csak a konkrét megvalósításnál hat, egy interfész metódusánál nem. Tegye ezért oda, ahol a kód ténylegesen fut.

Munkamenetek: biztonságos beállítások és új alapértékek

A munkamenetek gyakori támadási célpontok. Három beállítás központi: a session.use_strict_mode=1 elutasítja azokat a munkamenet-azonosítókat, amelyeket a szerver nem maga hozott létre; a session.cookie_httponly=1 megakadályozza a munkamenet-sütihez való JavaScriptes hozzáférést; a session.cookie_samesite=Lax megnehezíti a küldést idegen oldalakról. Az elfogadott RFC szerint pontosan ez a három érték lesz a PHP 8.6-tól az alapértelmezés. Addig állítsa be őket maga, és utána is kifejezetten, hogy a konfiguráció ne az alapértéktől függjön.

session.use_strict_mode = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
session.cookie_secure = 1

Többet erről a Munkamenetek biztosítása PHP-ban oldalon.

Amit a beépített függvények nem nyújtanak

A PHP-projekt biztonsági irányelvében egyértelmű: a PHP nem sandbox. Az open_basedir vagy a disable_functions megkerülése, az unserialize()-nak átadott rosszindulatú bemenetek és az olyan függvényeknek, mint a mysqli_query(), átadott ellenőrizetlen argumentumok nem számítanak a PHP biztonsági réseinek. Az üzemeltetők számára ez azt jelenti: ezek a beállítások hasznos keményítések, de nem biztonsági határok, és az unserialize()-nak idegen adatokhoz semmi köze.

A második pont a PHP2Shellt érinti. A CVE-2026-109618 és a CVE-2026-109619 a php.net szerint kódvégrehajtást tesz lehetővé azelőtt vagy közben, hogy az Ön alkalmazása fut; a mod_php-nál még azelőtt bemutattak egy exploitot, hogy egyáltalán alkalmazáskód futna. A kódjában lévő egyetlen függvény sem képes ezt elfogni. A biztonságos programozás és az aktuális PHP-verzió két különálló kötelesség, és mindkettőt teljesíteni kell.

Hogyan segít konkrétan a PHP SOS?

A PHP-alkalmazások biztonsági auditjában célzottan ellenőrizzük:

• Jelszó- és tokenkezelés: Használják a password_hash()-t és a random_bytes()-ot, vagy vannak házilag épített megoldások?
• Kimenetek és lekérdezések: Hol kerülnek a bemenetek szűretlenül HTML-be, SQL-be vagy shell-parancsokba?
• Munkamenet-konfiguráció: Be vannak állítva a Strict Mode, a HttpOnly, a SameSite és a Secure, és nem írhatók felül?
• Futtatókörnyezet: Támogatott PHP-verzió fut a 2026. október 21-i javításokkal?

Gyakori kérdések

Források

• PHP-kézikönyv: password_hash()
• PHP-kézikönyv: random_bytes()
• PHP-kézikönyv: hash_equals()
• PHP RFC: Secure Session Configuration Defaults
• OWASP Cheat Sheet Series