Ukratko: Sigurnosni code review za PHP je ciljano čitanje izvornog koda s jednim pitanjem: gdje strani unosi mogu učiniti nešto što ne smiju? Dokazana su dva oblika, review svake promjene i temeljni review cijelog projekta, uz podršku statičke analize pomoću PHPStana ili Psalma. Ranjivosti u PHP interpreteru poput PHP2Shella review ne pronalazi, ali pronalazi mnoge pogreške koje nastaju u vlastitom kodu.
Zašto upravo sada pogledati vlastiti kod?
PHP2Shell je u posljednjem tjednu listopada 2026. zaokupljao ponajprije administratore. Zakrpati, ponovno pokrenuti, dokazati: posao je ležao na poslužitelju. Za razvojne timove nakon toga ostaje neugodno pitanje. Ako napadač preko neke druge ranjivosti može izvršiti kod, što zatječe u našoj aplikaciji? I koliko smo tih ranjivosti sami napisali?
OWASP Top 10 godinama pokazuje da većina ranjivosti u web-aplikacijama nije egzotična. Nedostajuća kontrola pristupa, injection i nesigurna konfiguracija visoko su na ljestvici. To su pogreške koje uvježbani pogled u izvornom kodu pronalazi mnogo prije nego ih napadač isproba.
Tome se pridodaje praktičan razlog. Mnoge tvrtke upravo sada ionako daju provjeriti, zakrpati i ojačati svoje poslužitelje. Tko u istom koraku pogleda i vlastitu aplikaciju, zatvara jaz između rada i razvoja. Ojačan poslužitelj s ranjivom aplikacijom ostaje napadljiv, a jednako tako i uredno napisana aplikacija na nezakrpanom PHP-u.
Temeljni review ili review promjena?
OWASP Cheat Sheet o Secure Code Reviewu razlikuje dvije vrste koje se u praksi nadopunjuju:
| Vrsta | Kada | Opseg | Cilj |
|---|---|---|---|
| Temeljni review (baseline) | novi projekt, veliko izdanje, nakon incidenta | cijeli projekt, ponderiran prema riziku | zabilježiti postojeće ranjivosti |
| Review promjena (diff) | svaki pull request | samo promijenjeni kod | spriječiti nove pogreške |
Temeljni review nakon incidenta osobito je vrijedan. Tko je upravo očistio poslužitelj, trebao bi znati nudi li aplikacija dodatna ulazna vrata. Review promjena nakon toga održava stanje urednim, jer se svaka promjena prije spajanja čita i sa sigurnosnog gledišta.
Code review u PHP-u: gdje se sigurnosne pogreške gomilaju
U PHP projektima isplati se ciljan pogled na određene funkcije i uzorke. Nisu zabranjeni, ali svako nalazište zaslužuje pitanje mogu li u njega dospjeti strani podaci.
| Uzorak u kodu | Mogući rizik | Produbljivanje |
|---|---|---|
| SQL spajanjem stringova s varijablama | SQL injection | Spriječiti SQL injection u PHP-u |
unserialize() na podacima izvana |
injection objekata | Nesigurna deserijalizacija u PHP-u |
include ili require s promjenjivom putanjom |
uključivanje stranih datoteka | Spriječiti Local i Remote File Inclusion |
exec(), system(), shell_exec(), proc_open() |
izvršavanje naredbi | Command Injection |
Izlaz bez htmlspecialchars() |
Cross-Site Scripting | escaping prilagođen kontekstu |
== kod tokena ili hashova |
pretvorba tipova zaobilazi provjere | hash_equals(), stroge usporedbe |
eval(), extract() na unosima |
injection koda ili varijabli | najčešće ukloniti bez zamjene |
Brz prvi pregled uspijeva jednostavnom pretragom. Ona ne zamjenjuje review, ali pokazuje gdje započeti:
# Nalazišta rizičnih funkcija u vlastitom kodu (vendor isključen)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Barem jednako važno je ono što u kodu nedostaje. Provjerava li svaki kontroler smije li prijavljeni korisnik vidjeti ili mijenjati upravo taj zapis? Ograničavaju li se uploadi prema tipu i mjestu odlaganja? Takve ranjivosti ne pronalazi nijedna pretraga naziva funkcija, nego samo čitanje tijeka.
Alati koji nose review
Statička analiza provjerava kod bez izvršavanja. PHPStan i Psalm pronalaze pogreške tipova, nedostupan kod i pogrešne pretpostavke o povratnim vrijednostima. Psalm dodatno nudi taint analizu, koja prati teku li podaci iz zahtjeva neprovjereno na kritična mjesta. Oba se mogu postupno pooštravati, pa mogu početi i stariji projekti. Pregled daje Statička analiza: PHPStan i Psalm.
# Statička analiza u projektu, razinu postupno povećavati
vendor/bin/phpstan analyse src --level=5
# Taint analiza pomoću Psalma
vendor/bin/psalm --taint-analysis
Alati daju naznake, a ne presude. Svaki pogodak traži ocjenu, a prazno izvješće ne znači da je aplikacija sigurna.
Jednako važno kao pronalaženje je i bilježenje. Svaki nalaz trebao bi se zabilježiti s nalazištem, kratkim opisom, procjenom rizika, preporučenim otklanjanjem i statusom, najbolje izravno u sustavu tiketa tima. Tako se može pratiti što je otklonjeno, što je svjesno prihvaćeno i što je još otvoreno. Nakon otklanjanja isplati se drugi pogled: je li uzrok uklonjen ili samo jedan simptom? Pojavljuje li se isti uzorak na drugim mjestima u kodu? Pogreška koja je jednom napravljena prema iskustvu rijetko stoji samo na jednom mjestu.
Kontrolni popis za vlastiti tim
Za review promjena dokazao se kratak, fiksni popis. Pripada u predložak za pull requestove:
- Odakle dolaze svi podaci koje ova promjena obrađuje i provjeravaju li se na strani poslužitelja?
- Grade li se upiti prema bazi podataka isključivo s rezerviranim mjestima (placeholderima)?
- Je li svaki izlaz escapean za svoj kontekst, dakle HTML, atribut, JavaScript ili URL?
- Provjerava li kod ovlast za upravo taj objekt, a ne samo prijavu?
- Dospijevaju li lozinke, tokeni ili osobni podaci u zapisnike ili poruke o pogreškama?
- Stoje li tajne u kodu ili u verzioniranim datotekama?
- Jesu li uvedene nove ovisnosti i održavaju li se?
Sigurnosno kritične dijelove poput prijave, upravljanja pravima, tijekova plaćanja i uploada uvijek neka pročita druga osoba koja nije sudjelovala u kodu. Tuđi pogled pronalazi pretpostavke koje autor smatra samorazumljivima.
Kako PHP SOS konkretno pomaže?
- sa specijaliziranim partnerima provodimo temeljni review Vaše PHP aplikacije, ponderiran prema dijelovima s najvećim rizikom.
- Postavljamo PHPStan ili Psalm prema stanju Vašeg projekta i pišemo kontrolni popis za Vaše pull requestove.
- Review povezujemo s pogledom na poslužitelj i konfiguraciju, jer mnoge ranjivosti nastaju tek u međudjelovanju.
- Gdje se želi provjera izvana, review nadopunjujemo sigurnosnim auditom i penetracijskim testom.
Zaključak: Code review je najpovoljnije mjesto za otklanjanje sigurnosnih pogrešaka, naime prije nego se isporuče. Tko svaku promjenu provjerava kratkim popisom i povremeno u cijelosti pregleda projekt, trajno smanjuje napadnu površinu.
Česta pitanja
Koja je razlika između code reviewa i penetracijskog testa?
Code review čita izvorni tekst i pronalazi pogreške prije nego se isporuče. Penetracijski test napada aplikaciju u radu izvana. Oboje se nadopunjuje: review pronalazi uzroke, test pokazuje što se doista može iskoristiti.
Pronalazi li code review ranjivosti poput PHP2Shella?
Ne. PHP2Shell se nalazi u PHP interpreteru, a ne u aplikacijskom kodu. Protiv toga pomaže samo PHP update s ponovnim pokretanjem. Review pronalazi pogreške u vlastitom kodu, primjerice injection, nedostajuće provjere ovlasti ili nesigurnu deserijalizaciju.
Jesu li PHPStan ili Psalm dovoljni za sigurnosni review?
Dobra su osnova i automatski pronalaze mnoge pogreške. Logičke pogreške, nedostajuće provjere ovlasti i pogrešne pretpostavke o tijekovima ipak prepoznaje samo čovjek koji zna što aplikacija treba raditi.
Koliko dugo traje sigurnosni code review?
Ovisi o opsegu. Review svake promjene u pull requestu troši malo vremena. Potpuni review razvijenog projekta zaseban je pothvat koji se prema riziku ograničava na najvažnije dijelove.