Kort sagt: Ett penetrationstest av er PHP-applikation visar vilka svagheter en angripare faktiskt kunde utnyttja innan någon gör det. Tillsammans med specialiserade partner granskar vi applikation och server inom en skriftligt avtalad omfattning och levererar en rapport med prioriterade åtgärder. Efter åtgärdandet kontrollerar vi i ett omtest att luckorna är stängda.
Varför ett penetrationstest för PHP-applikationer är meningsfullt
PHP2Shell har visat att även grunden för en applikation, PHP självt, kan innehålla en kritisk sårbarhet. De flesta intrång i PHP-applikationer går dock via kända svagheter i den egna koden eller i konfigurationen: SQL-injektion, cross-site scripting, osäkra filuppladdningar, svaga sessioner, föråldrade beroenden eller öppna adminområden. OWASP Top 10 sammanfattar dessa kategorier.
En oberoende blick utifrån hittar det som förbises i vardagen. För ledning och tillsyn ger den ett hållbart underlag för att bedöma risker och sätta in budgeten riktat. För utvecklare är den en konkret arbetslista.
Audit eller penetrationstest: vad passar er?
| Form | Vad som granskas | Lämpligt när |
|---|---|---|
| Konfigurationsaudit | Server, PHP, webbserver, åtkomster, säkerhetskopior | Ni vill känna till infrastrukturens status |
| Kodgranskning | Applikationens källkod med insyn | Egenutvecklingar eller större anpassningar finns |
| Penetrationstest black-box | Applikationen utifrån utan förkunskap | Ni vill se en extern angripares perspektiv |
| Penetrationstest grey-/white-box | Applikationen med testkonton eller kod | Ni vill hitta så mycket som möjligt på begränsad tid |
Ofta är en kombination meningsfull, till exempel en konfigurationsaudit av servern tillsammans med ett grey-box-test av applikationen. Ett rent black-box-test verkar realistiskt men förbrukar mycket tid på att utforska. Med testkonton och insyn i uppbyggnaden hittar granskare i regel fler svagheter på samma tid.
Utöver applikationen lönar det sig att titta på miljön: Vilken PHP-version körs, är adminytor offentligt nåbara, ligger säkerhetskopior i webbkatalogen, är beroenden aktuella? Sådana punkter kontrollerar vi i auditen, eftersom de i praktiken ofta väger tyngre än ett enskilt fel i koden.
När är rätt tidpunkt för ett test?
Ett penetrationstest ger mest när det sker vid en meningsfull punkt i applikationens livscykel. Typiska tillfällen är:
- före lanseringen av en ny applikation, butik eller kundportal
- efter större ändringar, till exempel nya betalningssätt, gränssnitt eller inloggningsförfaranden
- efter en incident, när rensning och härdning är avslutade och ni vill ha en oberoende kontroll
- med regelbundna mellanrum, om kunder, partner eller er riskhantering kräver det
Ett test är föga meningsfullt så länge kända sårbarheter är öppna. Den som fortfarande driver opatchade PHP-versioner bör först skapa grundläget. Annars betalar man för ett test som bekräftar det kända.
Hur hjälper PHP SOS konkret?
- Fastställa omfattning: Vi klarlägger med er vilka applikationer, servrar och funktioner som granskas, vilken testtyp som passar och vad som uttryckligen är uteslutet. Resultatet är ett skriftligt uppdrag med tidsfönster och kontaktpersoner.
- Förbereda: Testkonton, åtkomst till testmiljön och en aktuell säkerhetskopia ställs till förfogande. Ert webbhotell informeras vid behov så att testet inte spärras som ett verkligt angrepp.
- Granska: Våra specialiserade partner testar enligt erkända metoder, bland annat utifrån OWASP-kategorierna. Kritiska fynd rapporterar vi genast, inte först i slutrapporten.
- Rapportera: Ni får en rapport med sammanfattning för ledningen och en teknisk del.
- Omtest: Efter åtgärdandet kontrollerar vi de funna svagheterna på nytt och bekräftar vad som är stängt.
Många fynd går att undvika redan i förväg. Guiderna om SQL-injektion i PHP, säkra filuppladdningar och sessioner i PHP hjälper utvecklare i förberedelsen.
Vad ni får och vad vi behöver
Rapporten innehåller varje funnen svaghet med beskrivning, berörd plats, riskbedömning och en konkret rekommendation för åtgärd. En sammanfattning för ledningen placerar resultaten i sitt sammanhang utan facksvenska. Efter omtestet får ni en bekräftelse på vilka punkter som är åtgärdade. Angreppsverktyg eller körbara exploits ingår inte i rapporten.
Vi behöver från er:
- ett skriftligt tillstånd från den behöriga personen för varje system som ska testas, även om det ligger hos ett webbhotell
- Testkonton med de roller som ska granskas
- en testmiljö eller godkännande att testa i den skarpa miljön inom ett tidsfönster
- en teknisk kontaktperson under testet
- vid kodgranskning: åtkomst till repositoryt
Vad vi inte lovar
Ett penetrationstest hittar inte varje sårbarhet. Det är en ögonblicksbild inom den avtalade omfattningen; nya funktioner eller nya sårbarheter i beroenden kan i morgon ge en annan bild. Vi anger inga certifikat eller märken som vi inte har och utfärdar inga intyg som ersätter rättsliga skyldigheter. Om ett test uppfyller era skyldigheter till exempel enligt NIS2 klarar ni ut med era experter på juridik och regelefterlevnad.
Åtgärdandet av fynden tar vi på begäran över själva eller tillsammans med er byrå. För server och PHP-konfiguration är serverhärdning ett lämpligt val.
Vanliga frågor
Vad är skillnaden mellan säkerhetsaudit och penetrationstest?
En audit granskar konfiguration, processer och kod utifrån riktlinjer och erfarenhetsvärden, ofta med insyn i systemen. Ett penetrationstest försöker målinriktat och med ert tillstånd utnyttja svagheter för att visa deras faktiska verkan. De kompletterar varandra.
Är ett penetrationstest av min PHP-applikation farligt?
Ett test kan belasta system eller ändra data. Därför fastställs omfattning, tidsfönster och gränser skriftligt i förväg, och vi rekommenderar att använda en testmiljö där det är möjligt. En aktuell säkerhetskopia ingår alltid.
Hittar ett penetrationstest alla säkerhetsluckor?
Nej. Ett test visar de svagheter som hittades inom den avtalade omfattningen och tidsperioden. Det är en ögonblicksbild och sänker risken, men bevisar inte att inga fler sårbarheter finns.
Hjälper ett penetrationstest vid NIS2?
Regelbundna kontroller av säkerhetsåtgärderna är en vanlig byggsten för att uppfylla skyldigheter kring riskhantering. Vilka krav som konkret gäller för ert företag klarar ni ut med experter på juridik och regelefterlevnad.