Lühidalt: Kui brauser nõuab PHP lehte, võtab veebiserver päringu vastu ja annab selle liidese (SAPI) kaudu PHP-le edasi. PHP tõlgib skripti baitkoodiks, käivitab selle Zend Engine'is ja tagastab tulemuse, enamasti HTML-i, veebiserverile. Seejärel koristatakse päringu olek ära, et järgmine algaks puhtalt.
Mis juhtub, kui keegi teie veebisaiti avab?
Külastajale on see üks klõps. Serveris toimub millisekundite jooksul palju samme. Kes seda kulgu tunneb, mõistab paremini, miks uuendused, taaskäivitused ja seadistus on nii olulised ning miks turvaauk PHP-s endas kaalub rohkem kui turvaauk pistikprogrammis.
PHP käsiraamat nimetab kolm osa, mis PHP veebisaidi jaoks on vajalikud: PHP interpretaator (CGI-na või servermoodulina), veebiserver ja brauser. Interpretaator on programm, mis loeb ja käivitab PHP koodi. Kuidas see on veebiserveriga ühendatud, määrab töörežiimi.
Kuidas PHP töötab? Päringu seitse sammu
- Päring: Brauser saadab serverisse HTTP päringu, näiteks
GET /kontakt.php. - Veebiserver: Apache, Nginx või LiteSpeed võtavad päringu vastu. Staatilised failid, nagu pildid, edastavad nad ise.
.phpfailide jaoks kutsuvad nad PHP välja. - Üleandmine SAPI kaudu: Serveriliides (SAPI) annab päringuandmed, nagu päisereaad, parameetrid ja vormiandmed, PHP-le edasi. PHP-FPM-i puhul toimub see FastCGI protokolli kaudu, mod_php puhul otse Apache'i protsessis. Üksikasjad leiate lehelt SAPI selgitus.
- Päringu ettevalmistamine: PHP paneb päringuandmed muutujatesse nagu
$_GET,$_POST,$_COOKIEja$_FILESning reserveerib päringu jaoks mälu. - Tõlkimine: Skript jaotatakse ehituskivideks (tokeniteks), neist tekib abstraktne süntaksipuu (AST) ja sellest opcode'id, omamoodi PHP masinkeel. Kui OPcache on aktiivne, jäetakse see samm vahele, kui skript juba vahemälus asub.
- Käivitamine: Zend Engine virtuaalmasin töötab opcode'id läbi, pärib andmebaasidelt, loeb faile ja loob väljundi.
- Vastus ja koristamine: Väljund läheb SAPI kaudu tagasi veebiserverile ja sealt brauserile. Seejärel vabastab PHP päringu mälu ja lähtestab oleku.
AST on olemas alates PHP 7-st. Sellega seotud RFC järgi lõi parser enne opcode'id otse sisselugemise ajal; kolmeks faasiks jagamine tegi kompilaatori hooldamise lihtsamaks.
Näide: mida skript päringust näeb
Järgmine kahjutu skript näitab, millist teavet PHP päringust saab ja millises töörežiimis see töötab:
<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'Betriebsart (SAPI): ' . PHP_SAPI . "\n";
echo 'PHP-Version: ' . PHP_VERSION . "\n";
echo 'Methode: ' . ($_SERVER['REQUEST_METHOD'] ?? '-') . "\n";
echo 'Speicher in dieser Anfrage: ' . memory_get_usage() . " Bytes\n";
PHP-FPM-iga serveris annab PHP_SAPI väärtuse fpm-fcgi, Apache'i all mod_php-ga apache2handler. Paigutage sellised kontrollifailid avalikku kataloogi ainult korraks ja mitte kunagi püsivalt, sest versiooniandmed aitavad ka ründajaid orienteeruda.
Kus baitkoodi vahemälu ja JIT mängu tulevad
Tõlkimine sammus 5 võtab aega. OPcache salvestab käsiraamatu järgi eelkompileeritud baitkoodi jagatud mällu ja säästab PHP-d skriptide laadimisest ja jaotamisest igal päringul. Alates PHP 8.0-st saab lisaks JIT-kompilaator luua opcode'idest päris masinkoodi. JIT-RFC järgi on see peaaegu iseseisev osa OPcache'ist.
| Faas | Tulemus | Kas vahemällu pannakse? |
|---|---|---|
| Lexing | tokenivoog | ei |
| Parsing | abstraktne süntaksipuu (AST) | ei |
| Kompileerimine | opcode'id (op-arrayd faili ja funktsiooni kohta) | jah, OPcache'is |
| JIT (valikuline) | masinkood | jah, OPcache'i mälus |
| Käivitamine | lehe väljund | ei |
Vahemälu puudutab ainult tõlgitud koodi. Üksiku päringu andmeid, näiteks vormisisestusi või sessiooniväärtusi, OPcache'i kaudu ei jagata.
Miks PHP2Shell ründab just seda kulgu
Mõlemad PHP2Shelli turvaaugud ei puuduta mitte üht rakendust, vaid kulgu ennast. CVE-2026-109618 puhul võib Out-of-Memory olukord PHP töö katkestada ajal, mil päringuandmed on alles osaliselt ette valmistatud, see tähendab sammus 4. Järgnevas koristamises võidakse siis kehtetuid andmeid käsitleda kehtivatena.
CVE-2026-109619 puhul võib päringu sisemine olek pärast mälu vabastamist alles jääda. Hilisem päring samas workeris võib seda kasutada enne, kui see lähtestatakse. See puudutab sammu 7, koristamist. Taustad leiate lehelt CVE-2026-109619 ja artiklist päringu elutsükkel.
Sellest järeldub: kaitsemeetmed rakenduse koodis, näiteks turvapistikprogrammid, hakkavad mõjuma alles sammus 6. mod_php puhul näidati PHP meeskonna andmetel ekspluateerimist isegi enne, kui rakenduse kood üldse käivitub. Tõhus on ainult PHP uuendus versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35 ja kõigi PHP protsesside taaskäivitus, sest pikaealised workerid täidavad muidu vana koodi edasi.
Kuidas PHP SOS konkreetselt aitab?
- Kulgu nähtavaks tegemine: Selgitame välja, milline töörežiim, seadistus ja vahemälu teie serveris tegelikult aktiivsed on.
- Õige uuendamine: Paigaldame PHP uuenduse ja kontrollime käivitusaegade põhjal, et ükski vana protsess enam ei tööta.
- Kihtide kaitsmine: Serveri karastamise raames piirame päringute suurusi, mälu ja õigusi seal, kus need mõjuvad: rakenduse koodi ees.
- Jälgede kontroll: Kaitsmata kättesaadavate serverite puhul otsime sissemurdmise märke.
Korduma kippuvad küsimused
Kas PHP koodi tõlgitakse igal väljakutsel uuesti?
Ilma vahemäluta jah: PHP jaotab skripti osadeks, ehitab süntaksipuu ja loob sellest opcode'id. Aktiivse OPcache'iga asuvad opcode'id jagatud mälus ja neid kasutatakse uuesti seni, kuni faili ei ole muudetud.
Mis jääb pärast päringut mällu?
Põhimõtteliselt koristatakse päringu olek lõpus ära, et järgmine päring algaks puhtalt. Pikaealised on ainult sellised asjad nagu OPcache või püsiühendused. Just selle koristamise külge haakub CVE-2026-109619.
Miks tuleb PHP pärast uuendust uuesti käivitada?
PHP-FPM-i ja mod_php puhul töötavad protsessid püsivalt ja on vana programmikoodi laadinud. Uued failid kettal sellest midagi ei muuda. Alles taaskäivitus laadib parandatud koodi.
Kas veebiserver ilma PHP-ta on turvalisem?
Sellel on väiksem ründepind, sest päringutele ei reageeri ükski programmiloogika. Puhtalt staatilise sisu jaoks on see tõeline võimalus. Poodide, vormide ja sisselogimiste jaoks on aga vaja serveripoolset keelt ja siis loeb selle hooldus.