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

> A PHP biztonsági függvényei: jelszavak, véletlen, maszkolás, kriptográfia, munkamenetek, és hol húzódnak a határaik az olyan réseknél, mint a PHP2Shell.

Forrás: https://phpsos.de/hu/php/eingebaute-sicherheitsfunktionen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

| Feladat | Függvény | Elérhető mióta | Fontos megjegyzés |
|---|---|---|---|
| Jelszavak tárolása | `password_hash()`, `password_verify()` | PHP 5.5 | az oszlop legfeljebb 255 karakter; a bcrypt 72 bájtra csonkol |
| Véletlen tokenek | `random_bytes()`, `random_int()` | PHP 7.0 | titkokhoz soha nem a `rand()` vagy az `mt_rand()` |
| Objektumorientált véletlen | `Random\Randomizer` | PHP 8.2 | azonos biztonság, rugalmasabb felület |
| HTML-kimenet maszkolása | `htmlspecialchars()` | mindig is | a 8.1 óta az alapértelmezett jelzők az egyszeres idézőjeleket is maszkolják |
| Időállandó összehasonlítás | `hash_equals()` | PHP 5.6 | a felhasználói bemenet a második argumentum |
| Modern kriptográfia | Sodium (`sodium_*`) | PHP 7.2 | saját titkosítás helyett |
| Titkok a stacktrace-ekben | `#[\SensitiveParameter]` | PHP 8.2 | az érték nem jelenik meg a trace-ben |
| Bemenetek ellenőrzése | `filter_var()` | PHP 5.2 | a formátumot ellenőrzi, nem helyettesíti a maszkolást |

## 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
<?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](https://phpsos.de/hu/blog/passwoerter-in-php-speichern/) és [biztonságos véletlenszámok és tokenek](https://phpsos.de/hu/blog/sichere-tokens-php/).

## 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
<?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](https://phpsos.de/hu/ratgeber/xss-php/) 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
<?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.

```ini
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](https://phpsos.de/hu/ratgeber/session-sicherheit-php/) 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](https://phpsos.de/hu/leistungen/sicherheitsaudit-penetrationstest/) 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

**Hogyan tároljuk helyesen a jelszavakat PHP-ban?**  
A password_hash() függvénnyel és a PASSWORD_DEFAULT értékkel, az ellenőrzés a password_verify()-val történik. Az adatbázis-oszlop a kézikönyv szerint legfeljebb 255 karaktert tudjon tárolni, mert az alapértelmezett algoritmus a jövőben változhat.

**Alkalmas a rand() tokenekhez?**  
Nem. Tokenekhez, kulcsokhoz és jelszó-visszaállító linkekhez a random_bytes() vagy a random_int() használandó. A kézikönyv szerint kriptográfiailag biztonságos véletlen értékeket adnak.

**Mióta része a Sodium a PHP-nak?**  
A modern kriptográfiához való Sodium bővítmény a PHP 7.2.0 óta a PHP része. A régebbi verziókhoz csak a PECL-en keresztül lehetett pótolni.

**Védenek ezek a függvények a PHP2Shell ellen?**  
Nem. Az Ön alkalmazásának hibái ellen védenek. A PHP2Shell magában az értelmezőben van, és csak PHP-frissítéssel zárható be, majd az összes PHP-folyamat újraindításával.

**Változnak a munkamenet-alapértékek a PHP 8.6-ban?**  
Igen, az elfogadott RFC szerint a session.use_strict_mode és a session.cookie_httponly alapértelmezés szerint bekapcsol, a session.cookie_samesite pedig Lax-re áll. A meglévő konfigurációkban ennek ellenére kifejezetten maga állítsa be őket.

## Források

- [PHP-kézikönyv: password_hash()](https://www.php.net/manual/en/function.password-hash.php)
- [PHP-kézikönyv: random_bytes()](https://www.php.net/manual/en/function.random-bytes.php)
- [PHP-kézikönyv: hash_equals()](https://www.php.net/manual/en/function.hash-equals.php)
- [PHP RFC: Secure Session Configuration Defaults](https://wiki.php.net/rfc/session_security_defaults)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)