Skip to content

Øvelse 34 – Håndtering af exceptions i ASP.NET Core Applikationer

Svar til instruktioner

  1. Notér dig, hvilken fejl der opstår. Giver den fejl mening? Og er den fejl valgt fremfor f.eks. statuskode 500?

    • Ved brug af "app.UseExceptionHandler($"/{StatusCodeController.NAME}?code=500");"
    • 404 - Not Found
    • Den giver ikke mening da 404 betyder Not Found, og i dette tilfælde er det jo en fejl som opstår da noget skal indsættes i SQL databasen. 500 - internal server error er teknisk set mere korrekt, men kunne muligvis også være bedre.

  2. Notér dig, hvilken fejl der opstår. Hvilken HTTP statuskode bliver der returneret?

    • Uden brug af global exception handler
    • HTTP ERROR 500 - Siden kan ikke findes
    • Her er fejlkoden ikke matchende med at en side ikke kunne findes.

  3. Notér dig, hvilken fejl der opstår.

    • Ved brug af "app.UseDeveloperExceptionPage();"
    • Side fra forrige øvelse vises med stacktrace

Reflekterende spørgsmål

  1. Hvorfor er det vigtigt at skjule detaljerede fejlmeddelelser som stack traces i produktionsmiljøer?

    • For ikke a lække sensitive oplysninger om det bagvedliggende system.

  2. Hvilke risici kan opstå, hvis stack traces bliver eksponeret for slutbrugere eller angribere?

    • At de kan få adgang til hvilke metoder, teknoligier osv. som bruges. Og dette kan skabe læk af fortroligt data og mulig oplysninger om sårbarheder.

  3. Hvordan kan global exception handling bidrage til en mere sikker applikation?

    • At man via defense in depth altid vil fange en exception hvis den ikke ellers fanges i systemet. Samtidigt kan man sikre at disse ikke viser sensitive oplysninger.

  4. Hvorfor er global exception handling ikke en erstatning for korrekt exception håndtering i koden?

    • Fordi det er en overordnet måde at gribe oversete fejl og giver ikke den håndtering man bør have for hver enkelte del af systemet. F.eks. vil man nok ikke få deb mest korrekte status kode for de fleste fejl.

  5. Hvordan kan du sikre, at fejlmeddelelser er brugervenlige, men samtidig ikke afslører følsomme oplysninger?

    • Ved at oprette custom exceptions med korrekte beskrivelser, disse kan så fanges hvorefter kun den valgte fejlbesked kan vises. Ellers kan man bruge fejlhåndtering uden exceptions som beskrevet i kapitel 9 i Secure By Design.

Kobling til relevante standarder og principper

Element i øvelsen Relateret standard / princip Kommentar
Håndtering af exceptions ISO/IEC 27002:2022, afsnit 8.28 (Secure coding) Anbefaler anvendelse af sikre kodningsprincipper, herunder korrekt håndtering af input, output og potentielle fejl, som en del af en sikker udviklingspraksis.
OWASP ASVS 5.0.0, kontrol 16.5 (Error Handling) Krav om korrekt håndtering af undtagelser for at undgå informationslækager og uventet adfærd. Fail secure nævnes direkte her.
Secure by Design (Johnsson et al.) Understreger vigtigheden af at undgå at exception flows kompromitterer systemets integritet.