Kort sagt: En säkerhetsinriktad kodgranskning för PHP är en målinriktad läsning av källtext med en fråga: Var kan främmande inmatning göra något som den inte får? Två former har visat sig fungera, en granskning av varje ändring och en grundgranskning av hela projektet, med stöd av statisk analys med PHPStan eller Psalm. Sårbarheter i PHP-tolken som PHP2Shell hittar en granskning inte, men väl de många fel som uppstår i den egna koden.
Varför titta på den egna koden just nu?
PHP2Shell sysselsatte under den sista veckan i oktober 2026 framför allt administratörer. Patcha, starta om, belägga: Arbetet låg på servern. För utvecklingsteam finns därefter en obekväm fråga kvar. Om en angripare kan köra kod via en annan sårbarhet, vad hittar han i vår applikation? Och hur många av de sårbarheterna har vi själva skrivit?
OWASP Top 10 visar sedan år att de flesta svagheter i webbapplikationer inte är exotiska. Saknad åtkomstkontroll, injektion och osäker konfiguration ligger högt upp. Det är fel som ett tränat öga hittar i källtexten långt innan en angripare provar dem.
Dessutom finns en praktisk orsak. Många företag låter just nu ändå kontrollera, patcha och härda sina servrar. Den som tittar på den egna applikationen i samma veva stänger luckan mellan drift och utveckling. En härdad server med sårbar applikation förblir angripbar, och likaså en väl skriven applikation på opatchad PHP.
Grundgranskning eller ändringsgranskning?
OWASP:s cheat sheet om Secure Code Review skiljer mellan två slag som kompletterar varandra i praktiken:
| Slag | När | Omfång | Mål |
|---|---|---|---|
| Grundgranskning (baslinje) | nytt projekt, stor release, efter en incident | hela projektet, viktat efter risk | registrera beståndet av svagheter |
| Ändringsgranskning (diff) | varje pull request | bara ändrad kod | förhindra nya fel |
En grundgranskning efter en incident är särskilt värdefull. Den som just har rensat en server bör veta om applikationen erbjuder ytterligare ingångar. Ändringsgranskningen håller sedan tillståndet rent, eftersom varje ändring före sammanslagningen också läses ur säkerhetssynpunkt.
Kodgranskning i PHP: var säkerhetsfel samlas
I PHP-projekt är det värt att titta särskilt på vissa funktioner och mönster. De är inte förbjudna, men varje fynd förtjänar frågan om främmande data kan nå dit.
| Mönster i koden | Möjlig risk | Fördjupning |
|---|---|---|
| SQL via strängsammanfogning med variabler | SQL-injektion | Förhindra SQL-injektion i PHP |
unserialize() på data utifrån |
Objektinjektion | Osäker deserialisering i PHP |
include eller require med variabel sökväg |
Inkludering av främmande filer | Förhindra local och remote file inclusion |
exec(), system(), shell_exec(), proc_open() |
Körning av kommandon | Command injection |
Utmatning utan htmlspecialchars() |
Cross-site scripting | kontextanpassad escaping |
== vid tokens eller hashar |
Typomvandling kringgår kontroller | hash_equals(), strikta jämförelser |
eval(), extract() på inmatning |
Kod- eller variabelinjektion | oftast stryka utan ersättning |
En snabb första överblick går att få med en enkel sökning. Den ersätter ingen granskning men visar var man bör börja:
# Fynd av riskabla funktioner i den egna koden (vendor undantaget)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Minst lika viktigt är det som saknas i koden. Kontrollerar varje controller om den inloggade användaren får se eller ändra just den här posten? Begränsas uppladdningar till typ och lagringsplats? Sådana luckor hittar ingen sökning efter funktionsnamn, bara läsningen av förloppet.
Verktyg som bär granskningen
Statisk analys kontrollerar kod utan att köra den. PHPStan och Psalm hittar typfel, onåbar kod och felaktiga antaganden om returvärden. Psalm erbjuder dessutom en taint-analys som följer om data från förfrågningar flödar ogranskade till kritiska ställen. Båda går att skärpa stegvis så att även äldre projekt kan komma igång. En överblick ger Statisk analys: PHPStan och Psalm.
# Statisk analys i projektet, höj nivån stegvis
vendor/bin/phpstan analyse src --level=5
# Taint-analys med Psalm
vendor/bin/psalm --taint-analysis
Verktyg ger indikationer, inga domar. Varje träff behöver en bedömning, och en tom rapport betyder inte att applikationen är säker.
Lika viktigt som att hitta är att dokumentera. Varje fynd bör registreras med fyndplats, kort beskrivning, riskbedömning, rekommenderad åtgärd och status, helst direkt i teamets ärendesystem. På så sätt går det att följa vad som åtgärdats, vad som medvetet accepterats och vad som fortfarande är öppet. Efter åtgärden är en andra titt värd besväret: Är orsaken undanröjd eller bara det ena symtomet? Dyker samma mönster upp på andra ställen i koden? Ett fel som en gång gjorts sitter erfarenhetsmässigt sällan bara på ett ställe.
En checklista för det egna teamet
För ändringsgranskningar har en kort, fast lista visat sig fungera. Den hör hemma i mallen för pull requests:
- Varifrån kommer all data som den här ändringen bearbetar, och kontrolleras den på serversidan?
- Byggs databasfrågor uteslutande med platshållare?
- Är varje utmatning escapad för sitt sammanhang, alltså HTML, attribut, JavaScript eller URL?
- Kontrollerar koden behörigheten för just det här objektet, inte bara inloggningen?
- Hamnar lösenord, tokens eller personuppgifter i loggar eller felmeddelanden?
- Står hemligheter i koden eller i versionshanterade filer?
- Har nya beroenden tillkommit, och är de underhållna?
Låt säkerhetskritiska delar som inloggning, rättighetshantering, betalningsflöden och uppladdningar alltid läsas av en andra person som inte deltagit i koden. Den främmande blicken hittar antaganden som upphovsmannen tar för självklara.
Hur hjälper PHP SOS konkret?
- Vi genomför tillsammans med specialiserade partner en grundgranskning av er PHP-applikation, viktad efter delarna med högst risk.
- Vi inrättar PHPStan eller Psalm i takt med ert projekts nivå och skriver checklistan för era pull requests.
- Vi knyter granskningen till en titt på server och konfiguration, eftersom många sårbarheter uppstår först i samspelet.
- Där en kontroll utifrån önskas kompletterar vi granskningen med säkerhetsaudit och penetrationstest.
Slutsats: En kodgranskning är det billigaste stället att åtgärda säkerhetsfel, nämligen innan de levereras. Den som kontrollerar varje ändring med en kort lista och då och då går igenom projektet fullständigt minskar angreppsytan varaktigt.
Vanliga frågor
Vad är skillnaden mellan kodgranskning och penetrationstest?
En kodgranskning läser källtexten och hittar fel innan de levereras. Ett penetrationstest angriper den körande applikationen utifrån. De kompletterar varandra: Granskningen hittar orsaker, testet visar vad som faktiskt går att utnyttja.
Hittar en kodgranskning sårbarheter som PHP2Shell?
Nej. PHP2Shell sitter i PHP-tolken, inte i applikationskoden. Mot det hjälper bara en PHP-uppdatering med omstart. En granskning hittar fel i den egna koden, till exempel injektion, saknade behörighetskontroller eller osäker deserialisering.
Räcker PHPStan eller Psalm för en säkerhetsgranskning?
De är en bra grund och hittar många fel automatiskt. Logikfel, saknade behörighetskontroller och felaktiga antaganden om förlopp upptäcker dock bara en människa som vet vad applikationen ska göra.
Hur lång tid tar en säkerhetsinriktad kodgranskning?
Det beror på omfånget. En granskning av varje ändring i pull requesten kostar lite tid. En fullständig granskning av ett projekt som vuxit över tid är ett eget projekt som man efter risk begränsar till de viktigaste delarna.