Sessioonide turvamine PHP-s: PHP sessioonide turvalisus praktikas

Lühidalt: PHP sessioonide turvalisuse jaoks loevad neli asja: turvalised küpsiseseaded, uus sessiooni ID pärast iga sisselogimist, lahutatud ja kaitstud salvestuskohad ning lühikesed kehtivusajad. PHP2Shelli tõttu peaks lisaks serveri poolel olema seatud session.upload_progress.enabled=0, kuni selle funktsiooni jaoks põhjust ei ole.

Miks sessioonid on tasuv sihtmärk

Sessioon jätab meelde, et kasutaja on sisse logitud. Tehniliselt saab brauser selleks küpsises juhusliku sessiooni ID ja server salvestab sellega seotud andmed. Kes seda ID-d teab, on rakenduse jaoks sama kasutaja, ilma paroolita ja ilma teise faktorita.

Haldajate jaoks tähendab see: nõrk sessioonihaldus võib sisselogimiskaitse kõrvale jätta, isegi kui paroolid ja kaheastmeline autentimine on puhtalt teostatud. Eriti kriitiline on see halduspiirkondades, klientide kontodel ja isikuandmetega portaalides.

Tüüpilised riskid on sessiooni ID kinnihaaramine (Session-Hijacking), teadaoleva ID peale surumine enne sisselogimist (Session-Fixation) ning liiga kaua kehtivad sessioonid jagatud arvutitel.

Turvalised põhiseaded php.ini-s

Olulisemad väärtused saab seada tsentraalselt failis php.ini või veebisaidi kaupa FPM-i poolis. Poolis kasutage php_admin_value või php_admin_flag, et rakendus ei saaks väärtusi üle kirjutada.

; Sessiooni põhikaraastus
session.use_strict_mode   = 1
session.use_only_cookies  = 1
session.use_trans_sid     = 0
session.cookie_httponly   = 1
session.cookie_secure     = 1
session.cookie_samesite   = "Lax"
session.cookie_lifetime   = 0
session.gc_maxlifetime    = 1800
session.name              = "APPSESSID"

; php.net-i PHP2Shelli märkus, seejärel taaskäivitada kõik töötajad
session.upload_progress.enabled = 0

use_strict_mode tagab, et PHP ei võta üle brauseri etteantud tundmatuid ID-sid. cookie_httponly takistab JavaScriptil ID-d lugeda, mis piirab Cross-Site-Scriptingu tagajärgi. cookie_secure saadab küpsise ainult HTTPS-i kaudu. SameSite=Lax raskendab saidiülesed päringud kehtiva sessiooniga; puhtalt halduspiirkondade jaoks võib sobida Strict.

Kehtivusaeg 1800 sekundit on näidisväärtus. Määrake see kaitsevajaduse järgi: lühem halduse ja klientide andmete puhul, pikem ainult seal, kus see sisuliselt vajalik on.

Pange tähele, et gc_maxlifetime määrab ainult, millal vanu sessiooniandmeid tohib kustutada. Mõnes distributsioonis ei korista sessioonifaile PHP ise, vaid korrapärane süsteemitöö. Kontrollige siis, millist väärtust see töö kasutab, et teie seadistus tegelikult rakenduks. Ärge toetuge väljalogimisel mitteaktiivsuse korral ainult koristusfunktsioonile, vaid kontrollige viimase tegevuse aega rakenduses endas, nagu näitab järgmine näide.

Sessiooni ID uuendamine pärast sisselogimist

Koodis on tähtsaim reegel luua sessiooni ID iga õiguste muutumise korral uuesti, see tähendab sisselogimisel, haldusrežiimi vahetamisel ja väljalogimisel. Järgmine näide näitab puhast põhimustrit käsuga password_verify():

<?php
declare(strict_types=1);

session_start();

function anmelden(PDO $db, string $email, string $passwort): bool
{
    $stmt = $db->prepare('SELECT id, passwort_hash FROM benutzer WHERE email = :email');
    $stmt->execute(['email' => $email]);
    $nutzer = $stmt->fetch(PDO::FETCH_ASSOC);

    if (!$nutzer || !password_verify($passwort, $nutzer['passwort_hash'])) {
        return false; // sama teade vale aadressi ja vale parooli korral
    }

    session_regenerate_id(true);           // uus ID, vana tühistada
    $_SESSION['benutzer_id']   = (int) $nutzer['id'];
    $_SESSION['letzte_aktion'] = time();
    return true;
}

function pruefeLeerlauf(int $sekunden = 900): void
{
    if (isset($_SESSION['letzte_aktion']) && time() - $_SESSION['letzte_aktion'] > $sekunden) {
        abmelden();
        return;
    }
    $_SESSION['letzte_aktion'] = time();
}

function abmelden(): void
{
    $_SESSION = [];
    $p = session_get_cookie_params();
    setcookie(session_name(), '', [
        'expires'  => time() - 3600,
        'path'     => $p['path'],
        'domain'   => $p['domain'],
        'secure'   => $p['secure'],
        'httponly' => $p['httponly'],
        'samesite' => $p['samesite'],
    ]);
    session_destroy();
}

Lisaks kaitske vorme, mis midagi muudavad, CSRF-tokeniga. See luuakse käsuga bin2hex(random_bytes(32)), paigutatakse sessiooni ja võrreldakse esitamisel käsuga hash_equals().

Salvestuskohad ja kliendipõhine lahutus

Vaikimisi salvestab PHP sessioonid failidena ühises kataloogis. Mitme veebisaidiga serveris võib see tähendada, et kompromiteeritud veebisait saab lugeda teise sessioone. Seetõttu kuulub igale veebisaidile oma pool oma kasutaja ja oma sessiooniteega.

; vastava veebisaidi FPM-i poolis
php_admin_value[session.save_path] = /var/lib/php/sessions/kunde-a

Kataloog peaks kuuluma pooli kasutajale ja õigused peaksid olema 0700. Kuidas veebisaite lisaks üksteisest eraldada, kirjeldab juhend open_basedir ja isolatsioon veebisaidi kaupa. Kui sessioone salvestatakse Redisesse või andmebaasi, kehtivad samad põhimõtted: oma ligipääs iga rakenduse jaoks, avatud võrgujuurdepääsu ei ole.

PHP sessioonide turvalisus ja PHP2Shell

PHP2Shelli turvaaugud CVE-2026-109618 ja CVE-2026-109619 asuvad PHP-s endas. Üleminekumeetmena nimetab php.net seada session.upload_progress.enabled=0 php.ini-s, FPM-i poolis või serveri seadistuses ning seejärel taaskäivitada kõik töötajad. Sõnaselgelt mitte käsuga ini_set() ega failis .user.ini.

23.10.2026 järgnes teade CVE-2026-115560 kohta. Võimalik koodi käivitamine on seal ainult ebatavalise kombinatsiooni korral: sessiooni serialiseerimine, ümberlülitus käsuga ini_set() enne session_start() ja aktiivne üleslaadimise edenemine. Leevendus on sama seade kuni järgmise regulaarse veaparandusväljalaskeni.

Kontrollige pärast muutmist, milline väärtus tegelikult kehtib. Käsurida näitab sageli teistsugust seadistust kui veebiserver; usaldusväärne on kaitstud, hiljem uuesti kustutatud kontrollleht või pooli seadistus ise.

Tüüpilised vead sessioonidega PHP rakendustes

Paljud nõrkused ei teki puuduvatest seadetest, vaid viisist, kuidas rakendused sessioone kasutavad. Neid mustreid tasub oma koodis ja teenusepakkujatelt sihipäraselt järele küsida:

• Liiga palju sessioonis: Paroolid, täielikud maksandmed või suured andmehulgad ei kuulu sessiooni. Salvestage ainult see, mis on seostamiseks vajalik, näiteks kasutaja ID ja rollid.
• Õigused ainult sessioonist: Kes on administraator, tuleks kriitiliste toimingute puhul andmebaasi vastu kontrollida. Muidu jäävad äravõetud õigused sessiooni lõpuni kehtima.
• Sessiooni ID aadressis: ID-d URL-ides satuvad logidesse, brauseri ajalukku ja Referer-andmetesse. use_only_cookies ja use_trans_sid = 0 takistavad seda.
• Sessiooni lõppu ei ole: Kui puudub tegevusetuse ajalõpp, jääb administraator jagatud arvutis piiramatult sisse logituks.
• HTTPS valesti tuvastatud proksi taga: Kui krüpteerimine lõpeb koormusjaoturis, peab rakendus seda teadma. Muidu seab ta küpsised võib-olla ilma liputa Secure.

Pärast turvaintsidenti kuulub juurde ka kõigi olemasolevate sessioonide tühistamine. Kõige lihtsamini juhtub see sessioonikataloogi sisu kustutamisel või sessiooni nime muutmisel. Kõik kasutajad peavad siis uuesti sisse logima ja varastatud sessioonid muutuvad väärtusetuks.

Kuidas PHP SOS konkreetselt aitab?

• Kontrollime sessiooniseadeid, küpsiselipukesi ja salvestuskohti serveri kõigil veebisaitidel ning dokumenteerime tegelikult kehtivad väärtused.
• Rakendame PHP2Shelli üleminekumeetmed pooli kaupa, taaskäivitame töötajad kontrollitult ja tõendame tulemust.
• Lahutame veebisaidid oma poolide ja sessiooniteedega serveri karastamise raames.
• Oma arenduste puhul kontrollime sisselogimist, väljalogimist ja sessiooni vahetust koodis ning soovitame konkreetseid muudatusi.

Korduma kippuvad küsimused

Allikad

• OWASP Cheat Sheet Series (Session Management)
• php.net: PHP2Shelli turvateated
• PHP 8 ChangeLog