En webserver, der fortæller sit navn og sit versionsnummer, eller en applikation, der viser en teknisk fejlmeddelelse, giver ikke i sig selv adgang til noget. Alligevel står den slags oplysninger i næsten hver rapport. Pointen er, at fundet ikke nødvendigvis handler om oplysningen selv. Det handler om, hvad oplysningen afslører om driften: at standardindstillinger ikke er ændret, at fejl håndteres forskelligt fra system til system, eller at en version er ældre, end den burde være.
Svaret på, hvorfor fundet tæller, er derfor todelt. Oplysningen gør arbejdet lettere for den, der leder efter svagheder, og den er et signal om, hvordan løsningen er sat op.
Hvad fundtypen omfatter
Rapporten kan beskrive oplysninger om systemet flere steder.
- Svarheadere · servernavn, version og teknologi, som sendes med hvert svar fra webserveren eller applikationen.
- Fejlsider · standardfejlsider fra webserveren, der viser produkt og version.
- Tekniske fejlmeddelelser · fejl fra applikationen, der viser stier på serveren, navne på komponenter, dele af databaseforespørgsler eller en sporing af, hvor i koden fejlen opstod.
- Standardsider og filer · velkomstsider, eksempelfiler og dokumentation, der fulgte med installationen og stadig ligger der.
- Loginsider · beskeder, der skelner mellem ukendt bruger og forkert adgangskode, så det kan ses, hvilke brugernavne der findes.
OWASP beskriver i sin vejledning om fejlhåndtering, at detaljerede fejl er nyttige for en angriber, der kortlægger teknologi og versioner. Anbefalingen er en generel fejlbesked til brugeren og de tekniske detaljer i en log på serveren.
Hvorfor oplysningen i sig selv er lav
At kende versionen giver ikke adgang. Den, der vil angribe, har andre måder at finde ud af, hvilken teknologi en løsning bruger, og OWASP gør selv opmærksom på, at det ikke er et fuldt værn at skjule headerne. Derfor kan fundet blive vurderet som lavt eller som oplysning.
Det betyder også, at I ikke skal bruge meget tid på at skjule versioner på bekostning af andre rettelser. En opdateret server med synligt versionsnummer er bedre stillet end en forældet server, hvor nummeret er fjernet. → Forældede komponenter og biblioteker
Hvorfor fundet alligevel har en pointe
Små fund fortæller noget om helheden. Det er derfor, de hører med i rapporten.
- Versionen er gammel · står der en version, som har kendte svagheder, er fundet ikke længere lille. Så er det et opdateringsfund, og den synlige version er bare budbringeren. → Opdateringsstatus på klienter og servere
- Standardopsætning · standardsider og fejlsider viser, at installationen ikke er gået igennem en hærdning efter opsætningen. Det kan gælde andre indstillinger også.
- Følsomme oplysninger i fejl · en fejl, der viser dele af en databaseforespørgsel, interne stier eller adresser, kan pege på en fejl i koden, der er mere alvorlig end selve meddelelsen. CWE har en særskilt kategori for fejlmeddelelser, der indeholder følsomme oplysninger.
- Uensartet håndtering · viser nogle systemer detaljer og andre ikke, mangler der en fælles regel.
Læs derfor fundet sammen med resten af rapporten. Står det alene, er det en oprydningsopgave. Står det ved siden af et fund om opdateringer eller adgang, er det en del af en større historie.
Det kan IT forberede før testen
Mange af fundene kan I selv finde og rette, før testeren går i gang. Det er ikke for at få en pænere rapport. Det er for at testens tid bliver brugt på det, I ikke selv kan se.
- Gennemgå de kendte løsninger · hvilke webservere og applikationer viser i dag version eller teknologi, og er det de versioner, I forventer?
- Kig på fejlsiderne · hvad ser en bruger, når en side ikke findes, eller når applikationen fejler?
- Afklar logningen · ved I, hvor de tekniske detaljer havner, når fejlen ikke længere vises til brugeren?
- Notér det, I ikke kan ændre · nogle standardsystemer viser oplysninger, som kun leverandøren kan fjerne. Fortæl testeren det, så fundet kan beskrives med den baggrund.
En liste over kendte forhold sparer tid og gør rapporten mere præcis. Rapporten kan så skelne mellem det, I allerede vidste, og det, der var nyt. → Kendte svagheder før testen
Hvem retter hvad
Oplysningerne kommer fra forskellige lag, og rettelsen skal ske i det lag, der sender dem.
- Webserver og proxy · servernavn, versionsheadere og standardfejlsider kan ændres i driftens opsætning. → Webserverens opsætning
- Applikationen · tekniske fejlmeddelelser og beskeder ved login skal rettes i koden eller i systemets indstillinger, måske hos leverandøren.
- Installationen · eksempelfiler og velkomstsider fjernes som en del af driftens oprydning.
Fjernes versionsheaderne i proxyen, kan applikationen stadig vise samme oplysning i sine fejl. Kontrollér begge lag.
Sådan bliver rettelsen varig
Fundtypen kommer let igen, fordi opdateringer kan nulstille indstillinger, og nye løsninger sættes op med standardværdier.
- Lav en fælles regel for fejl · brugeren ser en generel besked, detaljerne logges på serveren, og loggen er kun tilgængelig for driften.
- Gør oprydning til en del af installationen · fjern eksempelfiler og standardsider, når en løsning sættes op, ikke først når en test finder dem.
- Skriv ensartede beskeder ved login · samme besked uanset om brugernavnet findes.
- Kontrollér efter opdateringer · se efter, om headere og fejlsider er vendt tilbage til standard.
Mange af rettelserne kan klares hurtigt og samles med andre små fund fra samme løsning. → Hurtige rettelser efter testen
Det skal I lade være med
- At skjule versionen i stedet for at opdatere. En gammel version er stadig gammel, selv om den ikke vises.
- At fjerne detaljerne helt. Fejlene skal stadig kunne findes i loggen, når driften har brug for dem.
- At afvise fundet som støj. En detaljeret fejl kan pege på en dybere fejl i koden.
- At rette proxyen og glemme applikationen. Oplysningen kan komme fra flere lag.
- At glemme nye løsninger. Standardopsætningen kommer med, hver gang noget nyt sættes op.
Hvad kan og ikke kan konkluderes
Fundet viser, at løsningen gav oplysninger om sig selv eller sine fejl på de sider, der blev testet. Det viser ikke i sig selv, at der findes en udnyttelig svaghed. Omvendt er en løsning uden synlige versioner ikke dermed opdateret eller hærdet. Det vigtigste spørgsmål er, hvad oplysningen fortæller om den proces, der har sat løsningen op. Information om jeres IT, som kan findes andre steder end i selve løsningen, er et beslægtet emne. → Offentlige oplysninger om jeres IT
Tjekliste til versioner og fejl
- ☐ Er servernavn og version fjernet eller gjort neutralt i svarheadere?
- ☐ Er standardfejlsider erstattet med egne sider?
- ☐ Viser applikationen generelle fejl til brugeren og logger detaljerne?
- ☐ Er eksempelfiler og velkomstsider fjernet?
- ☐ Giver loginsiden samme besked uanset brugernavn?
- ☐ Kontrolleres det efter opdateringer, at indstillingerne stadig gælder?
- ☐ Er versionen faktisk opdateret, og ikke bare skjult?
Kilder
- OWASP Error Handling Cheat Sheet: detaljerede fejl som hjælp til kortlægning af teknologi og versioner; generel fejlbesked til brugeren og detaljer logget på serveren.
- OWASP HTTP Headers Cheat Sheet: headere med servernavn og teknologi bør fjernes eller gøres neutrale, med forbeholdet, at det ikke er et fuldt værn.
- CWE-209: Generation of Error Message Containing Sensitive Information: kategorien for fejlmeddelelser, der afslører følsomme oplysninger om miljø, brugere eller data. CWE vedligeholdes af MITRE med støtte fra CISA.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Forældede komponenter og biblioteker · Hurtige rettelser efter testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
