Röviden: A PHP-keretrendszer újrafelhasználható kódból álló alapváz, amely egy webalkalmazás tipikus feladatait már megoldja: a kéréseket a megfelelő kódhoz irányítja, feldolgozza az űrlapok adatait, megszólítja az adatbázisokat, előállítja a kimeneteket. Ismert PHP-keretrendszerek a Laravel, a Symfony, a Laminas, a CodeIgniter, a Yii, a CakePHP és a Slim. A keretrendszer biztonsági építőelemeket hoz magával, de nem véd a PHP-értelmezőben lévő rések ellen, mint a PHP2Shell.
Mi a PHP-keretrendszer?
Keretrendszer nélkül minden csapat újraírja az útválasztást, az űrlapellenőrzést, a munkameneteket és a hibakezelést. A keretrendszer ehhez rögzített építőelemeket és konvenciókat ad. Ez időt takarít meg, az új fejlesztők számára olvashatóvá teszi a kódot, és a biztonsági funkciókat egy helyen fogja össze ahelyett, hogy több száz fájlban szétszórná őket.
Az ügyvezetés számára elsősorban egy következmény fontos: egy keretrendszer megválasztásával évekre köti magát annak kiadási ciklusához. Ha a keretrendszer már nem támogat egy PHP-verziót, vagy maga sincs már gondozva, minden frissítés drágább lesz.
A legtöbb modern keretrendszert a Composeren keresztül telepítik, és tartja magát a PHP-FIG szabványaihoz, például a PSR-4-hez az autoloadinghoz vagy a PSR-7-hez a HTTP-üzenetekhez.
Az ismert PHP-keretrendszerek összehasonlítása
A következő áttekintés a projektek kezdőlapjain található önleírásokat használja. A népszerűség vagy a piaci részesedés szerinti értékelést szándékosan elhagyjuk, mert ehhez nincs megbízható közös forrás.
| Keretrendszer | Önleírás (értelem szerint) | Tipikus felhasználás |
|---|---|---|
| Laravel | „elemekkel együtt szállított” keretrendszer webalkalmazásokhoz | egyedi fejlesztések, portálok, SaaS |
| Symfony | nagy teljesítményű keretrendszer újrafelhasználható komponensekkel | nagy, hosszú életű alkalmazások; komponensek más projektekben |
| Laminas | a Zend Framework közösség által gondozott folytatása | vállalati alkalmazások, middleware |
| CodeIgniter | kis keretrendszer erős funkciókkal | kisebb alkalmazások, alacsony belépési küszöb |
| Yii | keretrendszer modern alkalmazások gyors fejlesztéséhez | webalkalmazások, egyes CMS-ek alapja |
| CakePHP | keretrendszer világos MVC-konvenciókkal | klasszikus adatbázis-alkalmazások |
| Slim | mikro-keretrendszer webalkalmazásokhoz és API-khoz | karcsú API-k, middleware-szolgáltatások |
A Symfony a kezdőlapján a Drupalt, a Laravelt, az API Platformot és a Composert nevezi meg olyan projektként, amelyek Symfony-komponenseket használnak. Egy keretrendszer tehát gyakran ott is ott van, ahol közvetlenül nem látszik. Hogy ez hogyan néz ki a CMS-eknél és a webshopoknál, azt a PHP-alapú CMS- és webshoprendszerek oldal mutatja.
Szinte minden keretrendszer közös építőelemei
A különböző filozófia ellenére a legtöbb keretrendszer közös felépítésű. Minden kérés egyetlen belépési ponton, a front controlleren halad át, többnyire a public/index.php fájlon. A webszerver ehhez minden olyan címet, amelyhez nincs valódi fájl, továbbad ennek a fájlnak.
# Példa: az Nginx az ismeretlen útvonalakat a front controllernek irányítja
root /var/www/app/public;
location / {
try_files $uri /index.php$is_args$args;
}
Az Apache esetén ezt a feladatot többnyire a nyilvános mappában lévő átírási szabály látja el, más webszervereknél hasonló szabály. Minden esetben az a fontos, hogy a webszerver a public mappára mutasson, és nem a projekt főkönyvtárára. A hibásan beállított dokumentumkönyvtár a leggyakoribb okok közé tartozik, amiért a konfigurációs fájlok hirtelen nyilvánosan lekérhetők.
Az előny a biztonság szempontjából: csak a public mappa van a webgyökérben. A konfiguráció, a forráskód és a vendor egy szinttel feljebb vannak, és URL-en keresztül nem érhetők el. Ezután az útválasztó rendeli hozzá a kérést egy vezérlőhöz (controller), a middleware ellenőrzi a bejelentkezést vagy a CSRF-tokent, a sablonmotor pedig automatikus maszkolással állítja elő a kimenetet.
Hogyan válasszon keretrendszert?
Új fejlesztéshez vagy egy meglévő projekt átvételéhez ezek a kérdések segítenek:
- Gondozás és kiadási ciklus: Meddig kapnak a verziók biztonsági frissítéseket, és vannak-e meghosszabbított támogatású verziók?
- PHP-támogatás: Olyan PHP-verzión fut-e a használt keretrendszer-verzió, amely maga is kap még biztonsági frissítéseket? Ez a projekt követelményei között szerepel.
- Csapat és szolgáltatók: Ismeri-e a csapat a keretrendszert, és talál-e vészhelyzetben hozzá szakembereket?
- Ökoszisztéma: Vannak-e gondozott csomagok az Ön követelményeihez, vagy sokat kellene magának építeni?
- Szabványok: Ha a keretrendszer tartja magát a PSR-felületekhez, az építőelemek később könnyebben cserélhetők.
A Laravel- és Symfony-projektekhez külön oldalaink vannak a védelemről: Laravel-alkalmazások védelme és Symfony-alkalmazások védelme.
Mit tud egy keretrendszer a biztonság terén, és mit nem
A keretrendszerek sok hibaforrást levesznek a fejlesztők válláról: előkészített adatbázis-lekérdezések az SQL-injekció ellen, automatikus maszkolás a cross-site scripting ellen, CSRF-védelem az űrlapokhoz, biztonságos jelszó-hashek. Ez azonban csak akkor működik, ha a csapat használja ezeket az építőelemeket, és nem kerüli meg őket.
A PHP2Shell ellen mindez nem segít. A CVE-2026-109618 és a CVE-2026-109619 a PHP-értelmezőben van. A PHP-csapat a kockázatot a mod_php esetén értékeli a legmagasabbra; ott még azelőtt bemutattak egy exploitot, hogy egyáltalán alkalmazáskód futna. A keretrendszer tehát el sem jut a szerephez. Csak a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra való frissítés és az összes PHP-folyamat újraindítása segít.
A keretrendszer-frissítés és a PHP-frissítés két külön feladat. Mindkettő a karbantartáshoz tartozik, de csak a PHP-frissítés zárja be a PHP2Shellt.
Régebbi projekteknél újabb kockázat jön hozzá: ha egy alkalmazás egy régi keretrendszer-verzióhoz kötődik, gyakran egy régi PHP-verzióhoz is. A PHP 8.1-hez és a régebbiekhez a PHP-projekttől már nincsenek hivatalos frissítések.
Hogyan segít konkrétan a PHP SOS?
- Megállapítjuk az alkalmazása keretrendszerét, verzióját és PHP-követelményeit, és megvizsgáljuk, hogy mindkettő kap-e még biztonsági frissítéseket.
- Ellenőrizzük a felépítést: csak a
publicvan-e a webgyökérben, védett-e a konfiguráció és avendor? - A keretrendszer- és PHP-frissítéseket külön tervezzük, teszteljük, és az összes worker újraindításával telepítjük.
- Egyedi fejlesztésekhez biztonsági auditot és penetrációs tesztet kínálunk, amely célzottan ellenőrzi a keretrendszer védelmi funkcióinak használatát.
Gyakori kérdések
Melyik a legjobb PHP-keretrendszer?
Ez a projekttől függ. Döntő az alkalmazás mérete és élettartama, a csapat szakértelme, a projekt általi gondozás és az aktuális PHP-verziók támogatása. Egy jól gondozott, a csapat által ismert keretrendszer többnyire jobb választás, mint a pillanatnyilag legnépszerűbb.
Véd egy keretrendszer a PHP2Shell ellen?
Nem. A PHP2Shell a PHP-értelmezőben van, és a PHP-csapat szerint mod_php esetén még azelőtt bemutattak egy exploitot, hogy egyáltalán alkalmazáskód futna. Semmilyen keretrendszer-frissítés nem helyettesíti a PHP-futtatókörnyezet frissítését és az összes worker újraindítását.
Mi az a mikro-keretrendszer?
A mikro-keretrendszer csak a magot nyújtja, tipikusan az útválasztást, a middleware-t és a kérés-válasz objektumokat. Az adatbázis-hozzáférést, a sablonokat vagy az űrlapokat az ember maga választja hozzá. A Slim például maga is mikro-keretrendszerként jellemzi magát a PHP-hoz.
Mit jelent, ha egy CMS Symfony-komponenseket használ?
A Symfony egyes építőelemeit használja, például a HTTP-feldolgozáshoz vagy a konzolhoz, a teljes keretrendszer átvétele nélkül. Az ezekre a komponensekre vonatkozó biztonsági közlemények ekkor a CMS-t is érintik, ami a frissítések tervezésénél számít.