Īsi: Kad pārlūkprogramma pieprasa PHP lapu, tīmekļa serveris pieņem pieprasījumu un caur saskarni (SAPI) nodod to PHP. PHP pārveido skriptu baitkodā, izpilda to Zend Engine un rezultātu, parasti HTML, atdod tīmekļa serverim. Pēc tam pieprasījuma stāvoklis tiek sakopts, lai nākamais sāktos tīrs.
Kas notiek, kad kāds atver jūsu vietni?
Apmeklētājam tas ir viens klikšķis. Serverī dažās milisekundēs norisinās daudzi soļi. Kas šo norisi pārzina, labāk saprot, kāpēc atjauninājumi, pārstartēšana un konfigurācija ir tik svarīgi un kāpēc ievainojamība pašā PHP ir smagāka par ievainojamību spraudnī.
PHP rokasgrāmata min trīs sastāvdaļas, kas vajadzīgas PHP vietnei: PHP interpretatoru (kā CGI vai servera moduli), tīmekļa serveri un pārlūkprogrammu. Interpretators ir programma, kas nolasa un izpilda PHP kodu. Tas, kā tas savienots ar tīmekļa serveri, nosaka darbības režīmu.
Kā darbojas PHP? Pieprasījuma septiņi soļi
- Pieprasījums: Pārlūkprogramma uz serveri nosūta HTTP pieprasījumu, piemēram,
GET /kontakt.php. - Tīmekļa serveris: Apache, Nginx vai LiteSpeed pieņem pieprasījumu. Statiskus failus, piemēram, attēlus, tie piegādā paši.
.phpfailiem tie izsauc PHP. - Nodošana caur SAPI: Servera saskarne (SAPI) nodod PHP pieprasījuma datus, piemēram, galvenes, parametrus un veidlapu datus. PHP-FPM gadījumā tas notiek, izmantojot FastCGI protokolu, mod_php gadījumā tieši Apache procesā. Detaļas skatiet sadaļā SAPI izskaidrota.
- Pieprasījuma sagatavošana: PHP pieprasījuma datus ievieto mainīgajos, piemēram,
$_GET,$_POST,$_COOKIEun$_FILES, un rezervē pieprasījumam atmiņu. - Pārveidošana: Skripts tiek sadalīts elementos (tokenos), no tiem rodas abstraktais sintakses koks (AST) un no tā opcodes, sava veida PHP mašīnvaloda. Ja OPcache ir aktīvs, šis solis tiek izlaists, ja skripts jau atrodas kešatmiņā.
- Izpilde: Zend Engine virtuālā mašīna izpilda opcodes, vaicā datubāzēm, nolasa failus un veido izvadi.
- Atbilde un sakopšana: Izvade caur SAPI atgriežas tīmekļa serverī un no turienes pārlūkprogrammā. Pēc tam PHP atbrīvo pieprasījuma atmiņu un atiestata stāvokli.
AST pastāv kopš PHP 7. Saskaņā ar attiecīgo RFC iepriekš parsētājs opcodes izveidoja tieši nolasīšanas laikā; sadalījums trīs fāzēs padarīja kompilatoru vieglāk uzturamu.
Piemērs: ko skripts redz no pieprasījuma
Šis nekaitīgais skripts parāda, kādu informāciju PHP saņem no pieprasījuma un kādā režīmā tas darbojas:
<?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";
Serverī ar PHP-FPM PHP_SAPI atgriež vērtību fpm-fcgi, Apache ar mod_php gadījumā apache2handler. Šādus pārbaudes failus publiskajā direktorijā glabājiet tikai īsu brīdi un nekad pastāvīgi, jo versiju norādes palīdz orientēties arī uzbrucējiem.
Kur ienāk baitkoda kešatmiņa un JIT
Pārveidošana 5. solī prasa laiku. OPcache saskaņā ar rokasgrāmatu glabā iepriekš kompilētu baitkodu koplietojamā atmiņā un tādējādi ietaupa PHP skriptu ielādi un sadalīšanu katrā pieprasījumā. Kopš PHP 8.0 papildus JIT kompilators no opcodes var izveidot īstu mašīnkodu. Saskaņā ar JIT RFC tas ir gandrīz patstāvīga OPcache daļa.
| Fāze | Rezultāts | Vai tiek kešots? |
|---|---|---|
| Leksiskā analīze | tokenu plūsma | nē |
| Parsēšana | abstraktais sintakses koks (AST) | nē |
| Kompilēšana | opcodes (op-masīvi katram failam un funkcijai) | jā, OPcache |
| JIT (pēc izvēles) | mašīnkods | jā, OPcache atmiņā |
| Izpilde | lapas izvade | nē |
Kešatmiņa attiecas tikai uz pārveidoto kodu. Atsevišķa pieprasījuma dati, piemēram, veidlapu ievade vai sesijas vērtības, caur OPcache netiek koplietoti.
Kāpēc PHP2Shell iejaucas tieši šajā norisē
Abas PHP2Shell ievainojamības skar nevis lietojumprogrammu, bet pašu norisi. CVE-2026-109618 gadījumā Out-of-Memory stāvoklis var pārtraukt PHP brīdī, kad pieprasījuma dati ir sagatavoti tikai daļēji, tātad 4. solī. Vēlākajā sakopšanā nederīgi dati tad var tikt uzskatīti par derīgiem.
CVE-2026-109619 gadījumā pieprasījuma iekšējais stāvoklis pēc atmiņas atbrīvošanas var saglabāties. Vēlāks pieprasījums tajā pašā darbprocesā (worker) to var izmantot, pirms tas ir atiestatīts. Tas skar 7. soli, sakopšanu. Fonu skatiet lapā CVE-2026-109619 un rakstā par pieprasījuma dzīves ciklu.
No tā izriet: aizsardzības pasākumi lietojumprogrammas kodā, piemēram, drošības spraudņi, iedarbojas tikai 6. solī. Mod_php gadījumā saskaņā ar PHP komandu exploit tika demonstrēts, vēl pirms tiek izpildīts lietojumprogrammas kods. Efektīvs ir tikai PHP atjauninājums uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 un visu PHP procesu pārstartēšana, jo ilgdzīvojoši darbprocesi citādi turpina izpildīt veco kodu.
Kā PHP SOS palīdz konkrēti?
- Padarīt norisi redzamu: Mēs noskaidrojam, kurš darbības režīms, kura konfigurācija un kura kešatmiņa jūsu serverī patiešām ir aktīva.
- Atjaunināt pareizi: Mēs ieviešam PHP atjauninājumu un pēc startēšanas laikiem pārbaudām, ka vairs nedarbojas neviens vecs process.
- Nostiprināt slāņus: Servera nostiprināšanas ietvaros mēs ierobežojam pieprasījumu lielumus, atmiņu un tiesības tur, kur tās iedarbojas: pirms lietojumprogrammas koda.
- Pārbaudīt pēdas: Serveriem, kas bija sasniedzami bez aizsardzības, mēs meklējam ielaušanās pazīmes.
Biežāk uzdotie jautājumi
Vai PHP kods tiek pārveidots no jauna katrā izsaukumā?
Bez kešatmiņas jā: PHP sadala skriptu, izveido sintakses koku un no tā ģenerē opcodes. Ja OPcache ir aktīvs, opcodes atrodas koplietojamā atmiņā un tiek izmantoti atkārtoti, kamēr fails nav mainījies.
Kas pēc pieprasījuma paliek atmiņā?
Principā pieprasījuma stāvoklis beigās tiek sakopts, lai nākamais pieprasījums sāktos tīrs. Ilgdzīvojoši ir tikai tādi elementi kā OPcache vai pastāvīgie savienojumi. Tieši pie šīs sakopšanas iejaucas CVE-2026-109619.
Kāpēc PHP pēc atjauninājuma jāpārstartē?
PHP-FPM un mod_php gadījumā procesi darbojas nepārtraukti, un tajos ir ielādēts vecais programmas kods. Jauni faili diskā to nemaina. Tikai pārstartēšana ielādē labojumu saturošo kodu.
Vai tīmekļa serveris bez PHP ir drošāks?
Tam ir mazāka uzbrukuma virsma, jo uz pieprasījumiem nereaģē nekāda programmu loģika. Tīri statiskam saturam tā ir reāla iespēja. Taču veikaliem, veidlapām un pieteikšanās nepieciešama servera puses valoda, un tad svarīga ir tās uzturēšana.