Lyhyesti: Tietoturvakoodikatselmointi PHP:lle on lähdekoodin kohdennettua lukemista yhdellä kysymyksellä: missä vieraat syötteet voivat tehdä jotain, mitä niiden ei pitäisi? Hyväksi on osoittautunut kaksi muotoa, jokaisen muutoksen katselmointi ja koko projektin perustason katselmointi, tukenaan staattinen analyysi PHPStanilla tai Psalmilla. PHP-tulkin aukkoja kuten PHP2Shelliä katselmointi ei löydä, mutta löytää ne monet virheet, jotka syntyvät omassa koodissa.
Miksi katsoa omaa koodia juuri nyt?
PHP2Shell on työllistänyt lokakuun 2026 viimeisellä viikolla ennen kaikkea ylläpitäjiä. Korjaa, käynnistä uudelleen, todista: työ oli palvelimella. Kehitystiimeille jää sen jälkeen epämukava kysymys. Jos hyökkääjä voi suorittaa koodia toisen aukon kautta, mitä hän löytää sovelluksestamme? Ja kuinka monta näistä aukoista olemme kirjoittaneet itse?
OWASP Top 10 osoittaa vuosien ajan, etteivät useimmat verkkosovellusten heikkoudet ole eksoottisia. Puuttuva pääsynvalvonta, injektio ja turvaton konfiguraatio ovat korkealla. Nämä ovat virheitä, jotka harjaantunut katse löytää lähdekoodista kauan ennen kuin hyökkääjä kokeilee niitä.
Lisäksi on käytännöllinen syy. Monet yritykset tarkistuttavat, korjaavat ja koventavat palvelimiaan parhaillaan joka tapauksessa. Joka katsoo oman sovelluksensa samalla kertaa, sulkee aukon käytön ja kehityksen välillä. Koventettu palvelin haavoittuvalla sovelluksella pysyy hyökättävänä, samoin siististi kirjoitettu sovellus korjaamattomalla PHP:llä.
Perustason katselmointi vai muutoskatselmointi?
OWASPin Cheat Sheet Secure Code Review'sta erottaa kaksi tyyppiä, jotka täydentävät käytännössä toisiaan:
| Tyyppi | Milloin | Laajuus | Tavoite |
|---|---|---|---|
| Perustason katselmointi (Baseline) | uusi projekti, suuri julkaisu, tapahtuman jälkeen | koko projekti, painotettu riskin mukaan | kartoittaa heikkouksien kanta |
| Muutoskatselmointi (Diff) | jokainen pull request | vain muuttunut koodi | estää uudet virheet |
Perustason katselmointi tapahtuman jälkeen on erityisen arvokas. Joka on juuri puhdistanut palvelimen, tulisi tietää, tarjoaako sovellus muita sisäänkäyntejä. Muutoskatselmointi pitää tilan sen jälkeen siistinä, koska jokainen muutos luetaan ennen yhdistämistä myös tietoturvanäkökulmasta.
Koodikatselmointi PHP:ssä: missä tietoturvavirheitä kasautuu
PHP-projekteissa kannattaa katsoa kohdennetusti tiettyjä funktioita ja malleja. Ne eivät ole kiellettyjä, mutta jokainen löytö ansaitsee kysymyksen, voiko vieraita tietoja päästä niihin.
| Malli koodissa | Mahdollinen riski | Syventävä |
|---|---|---|
| SQL merkkijonoyhdistelmällä muuttujien kanssa | SQL-injektio | SQL-injektion estäminen PHP:ssä |
unserialize() ulkoisille tiedoille |
olioinjektio | Turvaton deserialisointi PHP:ssä |
include tai require muuttuvalla polulla |
vieraiden tiedostojen sisällyttäminen | Local ja Remote File Inclusionin estäminen |
exec(), system(), shell_exec(), proc_open() |
komentojen suoritus | Command Injection |
Tuloste ilman htmlspecialchars() |
Cross-Site-Scripting | asiayhteyden mukainen escapaus |
== tokeneilla tai tiivisteillä |
tyyppimuunnos kiertää tarkistuksia | hash_equals(), tiukat vertailut |
eval(), extract() syötteille |
koodin tai muuttujien injektio | useimmiten poistettava korvaamatta |
Nopean ensiyleiskatsauksen saa yksinkertaisella haulla. Se ei korvaa katselmointia, mutta näyttää, mistä kannattaa aloittaa:
# Riskialttiiden funktioiden löydökset omassa koodissa (vendor poissuljettu)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Vähintään yhtä tärkeää on se, mikä koodista puuttuu. Tarkistaako jokainen kontrolleri, saako kirjautunut käyttäjä nähdä tai muuttaa juuri tämän tietueen? Rajataanko uploadit tyypin ja tallennuspaikan mukaan? Tällaisia aukkoja ei löydä mikään funktionimien haku, vain kulun lukeminen.
Työkalut, jotka kantavat katselmointia
Staattinen analyysi tarkistaa koodin suorittamatta sitä. PHPStan ja Psalm löytävät tyyppivirheitä, saavuttamatonta koodia ja vääriä oletuksia paluuarvoista. Psalm tarjoaa lisäksi taint-analyysin, joka seuraa, virtaavatko pyyntöjen tiedot tarkistamatta kriittisiin kohtiin. Molempia voi tiukentaa vaiheittain, jotta myös vanhemmat projektit pääsevät alkuun. Yleiskuvan antaa Staattinen analyysi: PHPStan ja Psalm.
# Staattinen analyysi projektissa, nostakaa tasoa vähitellen
vendor/bin/phpstan analyse src --level=5
# Taint-analyysi Psalmilla
vendor/bin/psalm --taint-analysis
Työkalut tuottavat vihjeitä, eivät tuomioita. Jokainen osuma tarvitsee arvion, eikä tyhjä raportti tarkoita, että sovellus olisi turvallinen.
Löytämisen veroista on kirjaaminen. Jokainen havainto tulisi tallentaa löytöpaikan, lyhyen kuvauksen, riskiarvion, suositellun korjauksen ja tilan kanssa, mieluiten suoraan tiimin tikettijärjestelmään. Näin voidaan seurata, mikä on korjattu, mikä hyväksytty tietoisesti ja mikä on vielä auki. Korjauksen jälkeen kannattaa katsoa vielä toisen kerran: onko syy poistettu vai vain yksi oire? Esiintyykö sama malli koodin muissa kohdissa? Kerran tehty virhe ei kokemuksen mukaan piile harvoin vain yhdessä paikassa.
Tarkistuslista omalle tiimille
Muutoskatselmointeihin on osoittautunut hyväksi lyhyt, kiinteä lista. Se kuuluu pull requestien mallipohjaan:
- Mistä kaikki tämän muutoksen käsittelemät tiedot tulevat, ja tarkistetaanko ne palvelinpuolella?
- Rakennetaanko tietokantakyselyt yksinomaan paikkamerkeillä?
- Onko jokainen tuloste escapattu omaan asiayhteyteensä eli HTML, attribuutti, JavaScript tai URL?
- Tarkistaako koodi käyttöoikeuden juuri tälle oliolle, ei vain kirjautumista?
- Päätyvätkö salasanat, tokenit tai henkilötiedot lokeihin tai virheilmoituksiin?
- Onko salaisuuksia koodissa tai versionhallinnassa olevissa tiedostoissa?
- Onko otettu käyttöön uusia riippuvuuksia, ja ovatko ne ylläpidettyjä?
Antakaa tietoturvakriittiset osat kuten kirjautuminen, oikeuksienhallinta, maksuprosessit ja uploadit aina toisen henkilön luettavaksi, joka ei ole osallistunut koodiin. Vieras katse löytää oletuksia, joita tekijä pitää itsestään selvinä.
Miten PHP SOS auttaa konkreettisesti?
- Teemme erikoistuneiden kumppaneiden kanssa PHP-sovelluksenne perustason katselmoinnin, painotettuna suurimman riskin osiin.
- Otamme PHPStanin tai Psalmin käyttöön projektinne tilaan sopivasti ja laadimme tarkistuslistan pull requesteillenne.
- Yhdistämme katselmoinnin palvelimen ja konfiguraation tarkasteluun, sillä monet aukot syntyvät vasta yhteisvaikutuksesta.
- Missä tarkistusta halutaan ulkopuolelta, täydennämme katselmointia tietoturva-auditoinnilla ja tunkeutumistestillä.
Yhteenveto: Koodikatselmointi on edullisin paikka korjata tietoturvavirheet, nimittäin ennen niiden toimittamista. Joka tarkistaa jokaisen muutoksen lyhyellä listalla ja käy projektin silloin tällöin kokonaan läpi, pienentää hyökkäyspintaa pysyvästi.
Usein kysytyt kysymykset
Mitä eroa on koodikatselmoinnilla ja tunkeutumistestillä?
Koodikatselmointi lukee lähdekoodia ja löytää virheet ennen niiden toimittamista. Tunkeutumistesti hyökkää käynnissä olevaan sovellukseen ulkopuolelta. Ne täydentävät toisiaan: katselmointi löytää syyt, testi näyttää, mikä on todella hyödynnettävissä.
Löytääkö koodikatselmointi PHP2Shellin kaltaisia aukkoja?
Ei. PHP2Shell on PHP-tulkissa, ei sovelluskoodissa. Sitä vastaan auttaa vain PHP-päivitys ja uudelleenkäynnistys. Katselmointi löytää omassa koodissa olevia virheitä, kuten injektiota, puuttuvia käyttöoikeustarkistuksia tai turvatonta deserialisointia.
Riittävätkö PHPStan tai Psalm tietoturvakatselmointiin?
Ne ovat hyvä perusta ja löytävät automaattisesti monia virheitä. Logiikkavirheet, puuttuvat käyttöoikeustarkistukset ja väärät oletukset kulusta tunnistaa kuitenkin vain ihminen, joka tietää, mitä sovelluksen pitäisi tehdä.
Kuinka kauan tietoturvakoodikatselmointi kestää?
Se riippuu laajuudesta. Jokaisen muutoksen katselmointi pull requestissa vie vähän aikaa. Vuosien mittaan kasvaneen projektin täydellinen katselmointi on oma hankkeensa, joka rajataan riskin mukaan tärkeimpiin osiin.