# Biztonsági code review PHP-projektekhez

> Biztonsági code review PHP-hoz: baseline vagy diff, kockázatos függvények, eszközök, mint a PHPStan és a Psalm, és ellenőrzőlista a saját csapatnak.

Forrás: https://phpsos.de/hu/blog/sicherheits-code-review-php/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/ratgeber/sql-injection-php/) |
| `unserialize()` kívülről származó adatokon | objektum-injection | [Nem biztonságos deszerializáció PHP-ban](https://phpsos.de/hu/ratgeber/deserialisierung-php/) |
| `include` vagy `require` változó útvonallal | idegen fájlok beágyazása | [Local és Remote File Inclusion megelőzése](https://phpsos.de/hu/ratgeber/lfi-rfi/) |
| `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:

```bash
# 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](https://phpsos.de/hu/php/statische-analyse/).

```bash
# 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:

1. Honnan származik az összes adat, amelyet ez a módosítás feldolgoz, és ellenőrzik őket a szerver oldalán?
2. Az adatbázis-lekérdezéseket kizárólag helyőrzőkkel építik fel?
3. Minden kimenet escape-elve van a saját kontextusára, vagyis HTML-re, attribútumra, JavaScriptre vagy URL-re?
4. A kód ellenőrzi a jogosultságot pontosan erre az objektumra, nem csak a bejelentkezést?
5. Jelszavak, tokenek vagy személyes adatok kerülnek naplókba vagy hibaüzenetekbe?
6. Állnak titkok a kódban vagy verziókezelt fájlokban?
7. Vettek fel új függőségeket, és gondozottak-e?

> **Tipp:**
> 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](https://phpsos.de/hu/leistungen/sicherheitsaudit-penetrationstest/).

**Ö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.

## Források

- [OWASP: Secure Code Review Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [PHPStan](https://phpstan.org/)