Na kratko: Varnostni pregled kode za PHP je ciljno branje izvornega besedila z enim vprašanjem: kje lahko tuji vnosi naredijo nekaj, česar ne bi smeli? Obnesli sta se dve obliki, pregled vsake spremembe in osnovni pregled celotnega projekta, podprta s statično analizo s PHPStan ali Psalm. Ranljivosti v interpreterju PHP, kot je PHP2Shell, pregled ne najde, najde pa številne napake, ki nastanejo v lastni kodi.
Zakaj ravno zdaj pogledati lastno kodo?
PHP2Shell je v zadnjem oktobrskem tednu 2026 zaposloval predvsem skrbnike. Popraviti, znova zagnati, dokazati: delo je ležalo na strežniku. Za razvojne ekipe ostane potem neprijetno vprašanje. Če lahko napadalec prek druge ranljivosti izvede kodo, kaj najde v naši aplikaciji? In koliko teh ranljivosti smo napisali sami?
OWASP Top 10 že leta kaže, da večina šibkosti v spletnih aplikacijah ni eksotičnih. Manjkajoč nadzor dostopa, injection in nevarna konfiguracija so visoko na seznamu. To so napake, ki jih izurjen pogled v izvorni kodi najde, dolgo preden jih napadalec preizkusi.
K temu pride praktičen razlog. Mnoga podjetja svoje strežnike zdaj tako ali tako dajejo pregledovati, popravljati in utrjevati. Kdor v istem koraku pogleda lastno aplikacijo, zapre vrzel med delovanjem in razvojem. Utrjen strežnik z ranljivo aplikacijo ostane napadljiv, prav tako čisto napisana aplikacija na nepopravljenem PHP.
Osnovni pregled ali pregled sprememb?
OWASP Cheat Sheet o Secure Code Review razlikuje dve vrsti, ki se v praksi dopolnjujeta:
| Vrsta | Kdaj | Obseg | Cilj |
|---|---|---|---|
| Osnovni pregled (baseline) | nov projekt, velika izdaja, po incidentu | celoten projekt, obtežen po tveganju | zajeti obstoječe ranljivosti |
| Pregled sprememb (diff) | vsak pull request | samo spremenjena koda | preprečiti nove napake |
Osnovni pregled po incidentu je posebej dragocen. Kdor je pravkar očistil strežnik, naj ve, ali aplikacija nudi še kakšna vstopna vrata. Pregled sprememb nato ohranja stanje čisto, ker se vsaka sprememba pred združitvijo prebere tudi z varnostnega vidika.
Pregled kode v PHP: kje se kopičijo varnostne napake
V projektih PHP se splača ciljno pogledati določene funkcije in vzorce. Niso prepovedani, a vsaka najdba si zasluži vprašanje, ali lahko vanjo pridejo tuji podatki.
| Vzorec v kodi | Možno tveganje | Poglobitev |
|---|---|---|
| SQL s staknjenjem nizov in spremenljivk | SQL injection | Preprečevanje SQL injection v PHP |
unserialize() na podatkih od zunaj |
vbrizgavanje objektov | Nevarna deserializacija v PHP |
include ali require s spremenljivo potjo |
vključevanje tujih datotek | Preprečevanje Local in Remote File Inclusion |
exec(), system(), shell_exec(), proc_open() |
izvajanje ukazov | command injection |
izpis brez htmlspecialchars() |
cross-site scripting | escapiranje, ustrezno kontekstu |
== pri žetonih ali zgoščenih vrednostih |
pretvorba tipov obide preverjanja | hash_equals(), stroge primerjave |
eval(), extract() na vnosih |
vbrizgavanje kode ali spremenljivk | večinoma brez nadomestila črtati |
Hiter prvi pregled uspe s preprostim iskanjem. Pregleda ne nadomesti, pokaže pa, kje začeti:
# Najdbe tveganih funkcij v lastni kodi (vendor izključen)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Vsaj enako pomembno je, česa v kodi manjka. Ali vsak krmilnik preveri, ali sme prijavljeni uporabnik ta zapis videti ali spremeniti? Ali so nalaganja omejena po tipu in mestu shranjevanja? Takih vrzeli ne najde nobeno iskanje po imenih funkcij, samo branje poteka.
Orodja, ki nosijo pregled
Statična analiza preverja kodo, ne da bi jo izvedla. PHPStan in Psalm najdeta napake tipov, nedosegljivo kodo in napačne predpostavke o vrnjenih vrednostih. Psalm dodatno ponuja analizo taint, ki spremlja, ali podatki iz zahtev nepreverjeno tečejo do kritičnih mest. Obe je mogoče postopoma zaostriti, tako da lahko vstopijo tudi starejši projekti. Pregled daje Statična analiza: PHPStan in Psalm.
# Statična analiza v projektu, raven postopoma višajte
vendor/bin/phpstan analyse src --level=5
# Analiza taint s Psalm
vendor/bin/psalm --taint-analysis
Orodja dajejo namige, ne sodb. Vsak zadetek potrebuje oceno, prazno poročilo pa ne pomeni, da je aplikacija varna.
Enako pomembno kot iskanje je zapisovanje. Vsako ugotovitev je treba zabeležiti z mestom najdbe, kratkim opisom, oceno tveganja, priporočenim odpravljanjem in statusom, najbolje neposredno v sistemu zahtevkov ekipe. Tako je mogoče slediti, kaj je odpravljeno, kaj zavestno sprejeto in kaj je še odprto. Po odpravi se splača drugi pogled: je vzrok odpravljen ali samo en simptom? Ali se isti vzorec pojavlja na drugih mestih v kodi? Napaka, ki je bila enkrat narejena, po izkušnjah redko tiči samo na enem mestu.
Kontrolni seznam za lastno ekipo
Za preglede sprememb se je obnesel kratek, stalen seznam. Sodi v predlogo za pull requeste:
- Od kod prihajajo vsi podatki, ki jih ta sprememba obdeluje, in ali se preverjajo na strežniku?
- Ali se poizvedbe v bazo podatkov gradijo izključno z nadomestnimi znaki?
- Ali je vsak izpis escapiran za svoj kontekst, torej HTML, atribut, JavaScript ali URL?
- Ali koda preveri pooblastilo za natanko ta objekt, ne le prijave?
- Ali gesla, žetoni ali osebni podatki pridejo v dnevnike ali sporočila o napakah?
- Ali so skrivnosti v kodi ali v datotekah pod nadzorom različic?
- Ali so bile sprejete nove odvisnosti in ali se vzdržujejo?
Varnostno kritične dele, kot so prijava, upravljanje pravic, plačilni postopki in nalaganja, naj vedno prebere druga oseba, ki pri kodi ni sodelovala. Tuji pogled najde predpostavke, ki jih avtor šteje za samoumevne.
Kako konkretno pomaga PHP SOS?
- S specializiranimi partnerji izvedemo osnovni pregled vaše aplikacije PHP, obtežen po delih z najvišjim tveganjem.
- PHPStan ali Psalm nastavimo glede na stanje vašega projekta in napišemo kontrolni seznam za vaše pull requeste.
- Pregled povežemo s pogledom na strežnik in konfiguracijo, saj številne ranljivosti nastanejo šele v sodelovanju.
- Kjer je zaželen pregled od zunaj, pregled dopolnimo z varnostnim pregledom in penetracijskim testom.
Sklep: Pregled kode je najcenejše mesto za odpravljanje varnostnih napak, namreč preden so dostavljene. Kdor vsako spremembo preveri s kratkim seznamom in občasno popolnoma pregleda projekt, trajno zmanjša napadalno površino.
Pogosta vprašanja
Kakšna je razlika med pregledom kode in penetracijskim testom?
Pregled kode prebere izvorno besedilo in najde napake, preden so dostavljene. Penetracijski test napade tekočo aplikacijo od zunaj. Dopolnjujeta se: pregled najde vzroke, test pokaže, kaj je dejansko mogoče izkoristiti.
Ali pregled kode najde ranljivosti, kot je PHP2Shell?
Ne. PHP2Shell je v interpreterju PHP, ne v kodi aplikacije. Proti temu pomaga samo posodobitev PHP s ponovnim zagonom. Pregled najde napake v lastni kodi, na primer injection, manjkajoča preverjanja pooblastil ali nevarno deserializacijo.
Ali PHPStan ali Psalm zadoščata za varnostni pregled?
Sta dobra podlaga in samodejno najdeta mnoge napake. Logične napake, manjkajoča preverjanja pooblastil in napačne predpostavke o poteku pa prepozna samo človek, ki ve, kaj naj aplikacija počne.
Kako dolgo traja varnostni pregled kode?
To je odvisno od obsega. Pregled vsake spremembe v pull requestu vzame malo časa. Popoln pregled zraslega projekta je samostojen projekt, ki se glede na tveganje omeji na najpomembnejše dele.