Kort sagt: En penetrationstest af jeres PHP-applikation viser, hvilke svagheder en angriber faktisk kunne udnytte, før nogen gør det. Sammen med specialiserede partnere gennemgår vi applikation og server inden for et skriftligt aftalt omfang og leverer en rapport med prioriterede foranstaltninger. Efter udbedringen kontrollerer vi i en gentest, om sårbarhederne er lukket.
Hvorfor en penetrationstest af PHP-applikationer er fornuftig
PHP2Shell har vist, at selv grundlaget for en applikation, PHP selv, kan indeholde en kritisk sårbarhed. De fleste indbrud i PHP-applikationer sker dog via kendte svagheder i egen kode eller i konfigurationen: SQL-injection, cross-site scripting, usikre filuploads, svage sessioner, forældede afhængigheder eller åbne administrationsområder. OWASP Top 10 sammenfatter disse kategorier.
Et uafhængigt blik udefra finder, hvad der overses i hverdagen. For direktion og tilsyn leverer det et holdbart grundlag til at vurdere risici og sætte budgettet målrettet ind. For udviklere er det en konkret arbejdsliste.
Audit eller penetrationstest: hvad passer til jer?
| Form | Hvad der gennemgås | Egnet, hvis |
|---|---|---|
| Konfigurationsaudit | Server, PHP, webserver, adgange, backups | I vil kende infrastrukturens status |
| Kodegennemgang | Applikationens kildekode med indsigt | Der findes egenudviklinger eller større tilpasninger |
| Penetrationstest black box | Applikationen udefra uden forhåndsviden | I vil se en ekstern angribers perspektiv |
| Penetrationstest grey/white box | Applikationen med testkonti eller kode | I vil finde så meget som muligt på begrænset tid |
Ofte er en kombination fornuftig, f.eks. et konfigurationsaudit af serveren sammen med en grey box-test af applikationen. En ren black box-test virker realistisk, men bruger meget tid på at udforske. Med testkonti og indsigt i opbygningen finder testere i samme tid som regel flere svagheder.
Ud over applikationen er det værd at se på omgivelserne: Hvilken PHP-version kører, er administrationsflader offentligt tilgængelige, ligger backups i webmappen, er afhængigheder opdaterede? Sådanne punkter kontrollerer vi med i auditet, fordi de i praksis ofte vejer tungere end en enkelt fejl i koden.
Hvornår er det rigtige tidspunkt for en test?
En penetrationstest giver mest, når den finder sted på et fornuftigt punkt i applikationens livscyklus. Typiske anledninger er:
- før lancering af en ny applikation, en webshop eller et kundeportal
- efter større ændringer, f.eks. nye betalingsveje, grænseflader eller loginprocedurer
- efter en hændelse, når oprydning og hærdning er afsluttet, og I ønsker en uafhængig kontrol
- med regelmæssige mellemrum, hvis kunder, partnere eller jeres risikostyring kræver det
Lidet fornuftig er en test, så længe kendte sårbarheder er åbne. Den, der stadig driver upatchede PHP-versioner, bør først skabe grundstatus. Ellers betaler man for en test, der bekræfter det kendte.
Hvordan hjælper PHP SOS konkret?
- Fastlægge omfang: Vi afklarer med jer, hvilke applikationer, servere og funktioner der gennemgås, hvilken testtype der passer, og hvad der udtrykkeligt er udelukket. Resultatet er en skriftlig bestilling med tidsvindue og kontaktpersoner.
- Forberede: Testkonti, adgange til testmiljøet og en aktuel backup stilles til rådighed. Jeres hostingudbyder informeres om nødvendigt, så testen ikke spærres som et rigtigt angreb.
- Gennemgå: Vores specialiserede partnere tester efter anerkendte metoder, bl.a. langs OWASP-kategorierne. Kritiske fund melder vi straks, ikke først i afslutningsrapporten.
- Rapportere: I får en rapport med ledelsesresumé og teknisk del.
- Gentest: Efter udbedringen kontrollerer vi de fundne svagheder påny og bekræfter, hvad der er lukket.
Mange fund kan undgås allerede på forhånd. Vejledningerne om SQL-injection i PHP, sikre filuploads og sessioner i PHP hjælper udviklere med forberedelsen.
Hvad I får, og hvad vi har brug for
Rapporten indeholder hver fundet svaghed med beskrivelse, berørt sted, risikovurdering og konkret anbefaling til udbedring. Et resumé til direktionen sætter resultaterne i perspektiv uden fagjargon. Efter gentesten får I en bekræftelse af, hvilke punkter der er udbedret. Angrebsværktøjer eller eksekverbare exploits er ikke en del af rapporten.
Vi har brug for fra jer:
- en skriftlig tilladelse fra den berettigede person for hvert system, der skal testes, også hvis det ligger hos en hostingudbyder
- testkonti med de roller, der skal gennemgås
- et testmiljø eller tilladelse til at teste i live-miljøet inden for et tidsvindue
- en teknisk kontaktperson under testen
- ved kodegennemgang: adgang til repositoryet
Hvad vi ikke lover
En penetrationstest finder ikke ethvert hul. Den er et øjebliksbillede inden for det aftalte omfang; nye funktioner eller nye sårbarheder i afhængigheder kan i morgen give et andet billede. Vi nævner ingen certifikater eller segl, som vi ikke har, og udsteder ingen attester, der erstatter juridiske pligter. Om en test opfylder jeres pligter, f.eks. efter NIS2, afklarer I med jeres fagfolk inden for jura og compliance.
Udbedringen af fundene overtager vi på ønske selv eller sammen med jeres bureau. Til server og PHP-konfiguration er serverhærdning en oplagt mulighed.
Ofte stillede spørgsmål
Hvad er forskellen på sikkerhedsaudit og penetrationstest?
Et audit gennemgår konfiguration, processer og kode ud fra retningslinjer og erfaringsværdier, ofte med indsigt i systemerne. En penetrationstest forsøger målrettet og med jeres tilladelse at udnytte svagheder for at vise deres faktiske virkning. De to supplerer hinanden.
Er en penetrationstest farlig for min PHP-applikation?
En test kan belaste systemer eller ændre data. Derfor fastlægges omfang, tidsvindue og grænser skriftligt på forhånd, og vi anbefaler, hvor det er muligt, at bruge et testmiljø. En aktuel backup hører altid med.
Finder en penetrationstest alle sikkerhedshuller?
Nej. En test viser de svagheder, der blev fundet inden for det aftalte omfang og tidsrum. Den er et øjebliksbillede og sænker risikoen, men beviser ikke, at der ikke findes flere sårbarheder.
Hjælper en penetrationstest ved NIS2?
Regelmæssige kontroller af sikkerhedsforanstaltningerne er en almindelig byggesten til at opfylde pligter til risikostyring. Hvilke krav der konkret gælder for jeres virksomhed, afklarer I med fagfolk inden for jura og compliance.