Lühidalt: Turvalisuse koodiülevaatus PHP jaoks on lähtekoodi sihipärane lugemine ühe küsimusega: kus saavad võõrad sisendid teha midagi, mida nad ei tohi? End on tõestanud kaks vormi, iga muudatuse ülevaatus ja kogu projekti baasülevaatus, mida toetab staatiline analüüs PHPStani või Psalmiga. PHP interpretaatori auke, nagu PHP2Shell, ülevaatus ei leia, küll aga paljud vead, mis tekivad oma koodis.
Miks vaadata oma koodi just praegu?
PHP2Shell on 2026. aasta oktoobri viimasel nädalal hõivanud eelkõige administraatoreid. Paikamine, taaskäivitamine, tõendamine: töö oli serveris. Arendusmeeskondadele jääb pärast seda ebamugav küsimus. Kui ründaja saab mõne teise augu kaudu koodi käivitada, mida ta meie rakenduses leiab? Ja kui paljud neist aukudest oleme ise kirjutanud?
OWASP Top 10 näitab aastaid, et enamik veebirakenduste nõrkusi ei ole eksootilised. Puuduv juurdepääsukontroll, injection ja ebaturvaline konfiguratsioon on kõrgel kohal. Need on vead, mille harjunud pilk lähtekoodis leiab, kaua enne kui ründaja neid proovib.
Lisaks praktiline põhjus. Paljud ettevõtted lasevad oma servereid praegu niikuinii kontrollida, paikata ja kõvendada. Kes vaatab oma rakenduse samal ajal üle, sulgeb lõhe töö ja arenduse vahel. Kõvendatud server haavatava rakendusega jääb ründatavaks ja korralikult kirjutatud rakendus paikamata PHP-l samuti.
Baasülevaatus või muudatuste ülevaatus?
OWASP Cheat Sheet turvalise koodi ülevaatuse kohta eristab kahte liiki, mis praktikas täiendavad teineteist:
| Liik | Millal | Maht | Eesmärk |
|---|---|---|---|
| Baasülevaatus (Baseline) | uus projekt, suur release, pärast intsidenti | kogu projekt, riski järgi kaalutud | nõrkuste seisu kaardistada |
| Muudatuste ülevaatus (Diff) | iga pull request | ainult muudetud kood | uusi vigu ära hoida |
Baasülevaatus pärast intsidenti on eriti väärtuslik. Kes on just serveri puhastanud, peaks teadma, kas rakendus pakub veel sissepääse. Muudatuste ülevaatus hoiab seisu pärast puhtana, sest iga muudatust loetakse enne ühendamist ka turvaaspektist.
Koodiülevaatus PHP-s: kus turvavead kuhjuvad
PHP-projektides tasub vaadata sihipäraselt teatud funktsioone ja mustreid. Need ei ole keelatud, kuid iga leid väärib küsimust, kas võõrad andmed võivad sinna jõuda.
| Muster koodis | Võimalik risk | Süvendus |
|---|---|---|
| SQL stringide liitmisega muutujatega | SQL-injection | SQL-injection'i vältimine PHP-s |
unserialize() väljastpoolt pärit andmetel |
objekti-injection | Ebaturvaline deserialiseerimine PHP-s |
include või require muutuva teega |
võõraste failide kaasamine | Local ja Remote File Inclusion'i vältimine |
exec(), system(), shell_exec(), proc_open() |
käskude täitmine | Command Injection |
Väljund ilma htmlspecialchars() |
Cross-Site-Scripting | kontekstikohane escape'imine |
== tokenite või räside puhul |
tüübiteisendus läheb kontrollidest mööda | hash_equals(), rangeid võrdlusi |
eval(), extract() sisenditel |
koodi- või muutuja-injection | enamasti asendamatult kustutada |
Kiire esmane ülevaade õnnestub lihtsa otsinguga. See ei asenda ülevaatust, kuid näitab, kust alustada:
# Riskantsete funktsioonide leiud oma koodis (vendor välistatud)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Vähemalt sama oluline on see, mida koodis ei ole. Kas iga kontroller kontrollib, kas sisselogitud kasutaja tohib just seda kirjet näha või muuta? Kas üleslaadimised on piiratud tüübi ja salvestuskohaga? Selliseid auke ei leia ükski funktsiooninimede otsing, ainult kulgemise lugemine.
Tööriistad, mis ülevaatust kannavad
Staatiline analüüs kontrollib koodi seda käivitamata. PHPStan ja Psalm leiavad tüübivigu, kättesaamatut koodi ja valesid eeldusi tagastusväärtuste kohta. Psalm pakub lisaks taint-analüüsi, mis jälgib, kas päringutest pärit andmed voolavad kontrollimata kriitilistesse kohtadesse. Mõlemat saab astmeliselt karmistada, nii et ka vanemad projektid saavad alustada. Ülevaate annab Staatiline analüüs: PHPStan ja Psalm.
# Staatiline analüüs projektis, taset samm-sammult tõsta
vendor/bin/phpstan analyse src --level=5
# Taint-analüüs Psalmiga
vendor/bin/psalm --taint-analysis
Tööriistad annavad vihjeid, mitte otsuseid. Iga tabamus vajab hindamist ja tühi aruanne ei tähenda, et rakendus on turvaline.
Leidmisest sama oluline on fikseerimine. Iga leid tuleks registreerida leiukoha, lühikirjelduse, riskihinnangu, soovitatud parandamise ja olekuga, kõige parem otse meeskonna ülesannete süsteemis. Nii saab jälgida, mis on parandatud, mis teadlikult aktsepteeritud ja mis veel avatud. Pärast parandamist tasub teine pilk: kas põhjus on kõrvaldatud või ainult üks sümptom? Kas sama muster ilmub koodis teistes kohtades? Viga, mis on korra tehtud, ei asu kogemuse põhjal harva ainult ühes kohas.
Kontrollnimekiri oma meeskonnale
Muudatuste ülevaatuste jaoks on end tõestanud lühike, kindel nimekiri. See kuulub pull requestide malli:
- Kust tulevad kõik andmed, mida see muudatus töötleb, ja kas neid kontrollitakse serveris?
- Kas andmebaasipäringud ehitatakse eranditult kohatäitjatega?
- Kas iga väljund on oma konteksti jaoks escape'itud, see tähendab HTML, atribuut, JavaScript või URL?
- Kas kood kontrollib õigust just selle objekti jaoks, mitte ainult sisselogimist?
- Kas paroolid, tokenid või isikuandmed satuvad logidesse või veateadetesse?
- Kas saladused asuvad koodis või versioonitud failides?
- Kas on lisatud uusi sõltuvusi ja kas neid hooldatakse?
Laske turvakriitilised osad, nagu sisselogimine, õiguste haldus, maksete protsessid ja üleslaadimised, alati lugeda teisel isikul, kes koodis ei osalenud. Võõras pilk leiab eeldusi, mida autor peab enesestmõistetavaks.
Kuidas PHP SOS konkreetselt aitab?
- Me teeme spetsialiseeritud partneritega teie PHP-rakenduse baasülevaatuse, kaalutuna kõrgeima riskiga osade järgi.
- Me seadistame PHPStani või Psalmi vastavalt teie projekti seisule ja kirjutame kontrollnimekirja teie pull requestide jaoks.
- Me ühendame ülevaatuse pilguga serverile ja konfiguratsioonile, sest paljud augud tekivad alles koostoimes.
- Kus soovitakse kontrolli väljastpoolt, täiendame ülevaatust turvaaudiiti ja läbitungimistestiga.
Kokkuvõte: Koodiülevaatus on odavaim koht turvavigade kõrvaldamiseks, nimelt enne, kui need edastatakse. Kes kontrollib iga muudatust lühikese nimekirjaga ja vaatab projekti aeg-ajalt täielikult läbi, vähendab ründepinda püsivalt.
Korduma kippuvad küsimused
Mis vahe on koodiülevaatusel ja läbitungimistestil?
Koodiülevaatus loeb lähtekoodi ja leiab vead enne, kui need edastatakse. Läbitungimistest ründab töötavat rakendust väljastpoolt. Mõlemad täiendavad teineteist: ülevaatus leiab põhjused, test näitab, mida tegelikult ära kasutada saab.
Kas koodiülevaatus leiab selliseid auke nagu PHP2Shell?
Ei. PHP2Shell asub PHP interpretaatoris, mitte rakenduse koodis. Selle vastu aitab ainult PHP uuendus koos taaskäivitamisega. Ülevaatus leiab vead oma koodis, näiteks injection'i, puuduvad õiguste kontrollid või ebaturvalise deserialiseerimise.
Kas PHPStan või Psalm piisavad turvaülevaatuseks?
Need on hea alus ja leiavad palju vigu automaatselt. Loogikavigu, puuduvaid õiguste kontrolle ja valesid eeldusi protsesside kohta tunneb aga ära ainult inimene, kes teab, mida rakendus peab tegema.
Kui kaua turvakoodiülevaatus kestab?
See sõltub mahust. Iga muudatuse ülevaatus pull requestis võtab vähe aega. Kasvanud projekti täielik ülevaatus on eraldi ettevõtmine, mis piiratakse riski järgi kõige olulisemate osadega.