Röviden: A PHP biztonsági code review a forráskód célzott olvasása egyetlen kérdéssel: hol tehetnek idegen bemenetek olyat, amit nem szabadna? Két forma vált be: minden módosítás review-ja és a teljes projekt alap-review-ja, a PHPStan vagy a Psalm statikus elemzésére támaszkodva. A PHP-értelmezőben lévő réseket, mint a PHP2Shell, a review nem találja meg, de azokat a sok hibát igen, amelyek a saját kódban keletkeznek.
Miért éppen most nézzük meg a saját kódot?
A PHP2Shell 2026 októberének utolsó hetében főleg az adminokat foglalkoztatta. Patchelni, újraindítani, igazolni: a munka a szerveren volt. A fejlesztőcsapatoknak utána egy kellemetlen kérdés marad. Ha egy támadó egy másik résen keresztül kódot tud végrehajtani, mit talál az alkalmazásunkban? És a rések közül hányat írtunk mi magunk?
Az OWASP Top 10 évek óta mutatja, hogy a webalkalmazások legtöbb sebezhetősége nem egzotikus. A hiányzó hozzáférés-vezérlés, az injection és a nem biztonságos konfiguráció az élmezőnyben áll. Ezek olyan hibák, amelyeket egy gyakorlott szem megtalál a forráskódban, jóval azelőtt, hogy egy támadó kipróbálná őket.
Ehhez jön egy gyakorlati ok. Sok vállalat éppen amúgy is ellenőrizteti, patcheli és keményíti a szervereit. Aki ugyanebben a menetben a saját alkalmazását is megnézi, bezárja az üzemeltetés és a fejlesztés közötti hézagot. Egy keményített szerver sebezhető alkalmazással támadható marad, és egy rendesen megírt alkalmazás nem patchelt PHP-n ugyanúgy.
Alap-review vagy módosítás-review?
A Secure Code Review-ról szóló OWASP Cheat Sheet két fajtát különböztet meg, amelyek a gyakorlatban kiegészítik egymást:
| Fajta | Mikor | Terjedelem | Cél |
|---|---|---|---|
| Alap-review (baseline) | új projekt, nagy kiadás, incidens után | az egész projekt, kockázat szerint súlyozva | a sebezhetőségek állományának felmérése |
| Módosítás-review (diff) | minden pull request | csak a módosított kód | új hibák megelőzése |
Az incidens utáni alap-review különösen értékes. Aki éppen megtisztított egy szervert, tudnia kell, kínál-e az alkalmazás további behatolási pontokat. A módosítás-review utána tisztán tartja az állapotot, mert minden módosítást az egyesítés előtt biztonsági szempontból is elolvasnak.
Code review PHP-ban: hol halmozódnak a biztonsági hibák
A PHP-projektekben megéri célzottan megnézni bizonyos függvényeket és mintákat. Nem tiltottak, de minden találat megérdemli a kérdést, hogy kerülhetnek-e bele idegen adatok.
| Minta a kódban | Lehetséges kockázat | Elmélyítés |
|---|---|---|
| SQL string-összefűzéssel, változókkal | SQL-injection | SQL-injection megelőzése PHP-ban |
unserialize() kívülről származó adatokon |
objektum-injection | Nem biztonságos deszerializáció PHP-ban |
include vagy require változó útvonallal |
idegen fájlok beágyazása | Local és Remote File Inclusion megelőzése |
exec(), system(), shell_exec(), proc_open() |
parancsvégrehajtás | command injection |
Kimenet htmlspecialchars() nélkül |
cross-site scripting | az összefüggésnek megfelelő escape-elés |
== tokeneknél vagy hasheknél |
a típusátalakítás megkerüli az ellenőrzéseket | hash_equals(), szigorú összehasonlítások |
eval(), extract() bemeneteken |
kód- vagy változó-injection | többnyire helyettesítés nélkül törölni |
Egy gyors első áttekintés egy egyszerű kereséssel sikerül. Nem helyettesíti a review-t, de megmutatja, hol érdemes kezdeni:
# Kockázatos függvények találatai a saját kódban (a vendor kizárva)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Legalább ennyire fontos, ami a kódból hiányzik. Minden controller ellenőrzi, hogy a bejelentkezett felhasználó pontosan ezt az adatrekordot láthatja vagy módosíthatja-e? A feltöltéseket típusra és tárolási helyre korlátozzák? Az ilyen réseket nem találja meg semmilyen függvénynevekre irányuló keresés, csak a folyamat olvasása.
Eszközök, amelyek a review-t hordozzák
A statikus elemzés a kódot a végrehajtása nélkül ellenőrzi. A PHPStan és a Psalm típushibákat, elérhetetlen kódot és a visszatérési értékekre vonatkozó téves feltevéseket talál. A Psalm emellett taint-elemzést kínál, amely nyomon követi, hogy a kérésekből származó adatok ellenőrizetlenül jutnak-e kritikus helyekre. Mindkettő lépcsőzetesen szigorítható, így a régebbi projektek is beszállhatnak. Áttekintést ad a Statikus elemzés: PHPStan és Psalm.
# Statikus elemzés a projektben, a szintet fokozatosan emelni
vendor/bin/phpstan analyse src --level=5
# Taint-elemzés a Psalm-mal
vendor/bin/psalm --taint-analysis
Az eszközök jelzéseket adnak, nem ítéleteket. Minden találatot értékelni kell, és egy üres jelentés nem jelenti, hogy az alkalmazás biztonságos.
A megtalálással egyformán fontos a rögzítés. Minden megállapítást fel kell venni a lelőhellyel, rövid leírással, a kockázat becslésével, ajánlott javítással és állapottal, legjobb közvetlenül a csapat jegykezelő rendszerében. Így nyomon követhető, mi lett javítva, mit fogadtak el tudatosan, és mi van még nyitva. A javítás után érdemes másodszor is ránézni: megszűnt az ok, vagy csak az egyik tünet? Felbukkan ugyanez a minta a kód más helyein? Egy egyszer elkövetett hiba tapasztalat szerint ritkán csak egy helyen van.
Ellenőrzőlista a saját csapatnak
A módosítás-review-khoz egy rövid, rögzített lista vált be. A pull requestek sablonjába tartozik:
- Honnan származik az összes adat, amelyet ez a módosítás feldolgoz, és ellenőrzik őket a szerver oldalán?
- Az adatbázis-lekérdezéseket kizárólag helyőrzőkkel építik fel?
- Minden kimenet escape-elve van a saját kontextusára, vagyis HTML-re, attribútumra, JavaScriptre vagy URL-re?
- A kód ellenőrzi a jogosultságot pontosan erre az objektumra, nem csak a bejelentkezést?
- Jelszavak, tokenek vagy személyes adatok kerülnek naplókba vagy hibaüzenetekbe?
- Állnak titkok a kódban vagy verziókezelt fájlokban?
- Vettek fel új függőségeket, és gondozottak-e?
A biztonsági szempontból kritikus részeket, mint a bejelentkezés, a jogosultságkezelés, a fizetési folyamatok és a feltöltések, olvassa el mindig egy második személy, aki nem vett részt a kódban. Az idegen szem olyan feltevéseket talál, amelyeket a szerző magától értetődőnek tart.
Hogyan segít konkrétan a PHP SOS?
- Specializált partnerekkel alap-review-t végzünk a PHP-alkalmazásán, a legmagasabb kockázatú részek szerint súlyozva.
- A PHPStan-t vagy a Psalm-ot a projektje állapotához illően állítjuk be, és megírjuk a pull requestjei ellenőrzőlistáját.
- A review-t összekapcsoljuk a szerver és a konfiguráció átnézésével, mert sok rés csak a kölcsönhatásban keletkezik.
- Ahol kívülről végzett ellenőrzést kívánnak, a review-t kiegészítjük biztonsági audittal és penetrációs teszttel.
Összegzés: A code review a legolcsóbb hely a biztonsági hibák javítására, mégpedig mielőtt kiszolgálnák őket. Aki minden módosítást egy rövid listával ellenőriz, és a projektet időnként teljesen átnézi, tartósan csökkenti a támadási felületet.
Gyakori kérdések
Mi a különbség a code review és a penetrációs teszt között?
A code review a forráskódot olvassa, és megtalálja a hibákat, mielőtt kiszolgálnák őket. A penetrációs teszt kívülről támadja a futó alkalmazást. Mindkettő kiegészíti egymást: a review az okokat találja meg, a teszt azt mutatja meg, mi használható ki ténylegesen.
Megtalálja a code review az olyan réseket, mint a PHP2Shell?
Nem. A PHP2Shell a PHP-értelmezőben van, nem az alkalmazáskódban. Ez ellen csak a PHP-frissítés segít újraindítással. A review a saját kód hibáit találja meg, például az injectiont, a hiányzó jogosultság-ellenőrzéseket vagy a nem biztonságos deszerializációt.
Elég a PHPStan vagy a Psalm egy biztonsági review-hoz?
Jó alapot adnak, és sok hibát automatikusan megtalálnak. A logikai hibákat, a hiányzó jogosultság-ellenőrzéseket és a folyamatokra vonatkozó téves feltevéseket viszont csak olyan ember ismeri fel, aki tudja, mit kell tennie az alkalmazásnak.
Mennyi ideig tart egy biztonsági code review?
Ez a terjedelemtől függ. A pull requestben lévő minden módosítás review-ja kevés időt vesz igénybe. Egy gyarapodott projekt teljes review-ja külön vállalkozás, amelyet kockázat szerint a legfontosabb részekre korlátoznak.