🛡️ Øvelse 23 – Opretholdelse af objekters integritet med invarians i webapplikationer
ℹ️ Information
Formålet med denne øvelse er at vise, hvordan objekter, der håndhæver deres invarians gennem en konstruktør, kan anvendes i en webapplikation til at sikre sikkerhed i flere lag.
Ofte vil forskellige mennesker arbejde på forskellige dele af softwaren, hvilket kan betyde, at man måske tror, at noget (f.eks. inputvalidering) bliver håndteret et andet sted, uden at det faktisk gør det. Dette kan gøre softwaren sårbar. Derfor bør man tænke "defense in depth" og sige, at al data, softwaren modtager, altid bliver valideret så hurtigt som muligt, som du gjorde i controllerklassen i de forrige øvelser. Men ligeså snart, noget data bliver givet videre fra controllerklassen til en anden klasse i softwaren, så bliver det givet videre som et objekt, der opretholder invarians og derfor har integritet. Så opstår der aldrig tvivl om, hvorvidt man kan stole på den data, man modtager internt i softwaren.
Typisk vil data, som bliver afsendt af en anden applikation, have overskredet en tillidsgrænse og bliver derfor modtaget som et såkaldt Data Transfer Object (DTO) (som i øvelse 20). DTO har ofte ikke nogen regler tilknyttet, udover hvilken type data, den må indeholde. Derfor bør en DTO aldrig forlade controllerklassen. I denne øvelse vises der et (meget primitivt) eksempel på dette.
Du skal i denne øvelse orientere dig om, hvordan man anvender overgange fra et modtaget DTO-objekt til et objekt, der håndhæver invarians.
Projektet, du skal anvende, er InvarianceDTOandModel fra repo'et https://github.com/mesn1985/InputValidationsBasicExercises, som du klonede i en tidligere øvelse.
⚠️ Vigtigt: Invarians erstatter ikke inputvalidering
Selvom både invarians og inputvalidering handler om at sikre gyldigheden af data, har de forskellige roller og fungerer bedst i kombination:
-
Inputvalidering sikrer, at data, som kommer ind i systemet (f.eks. fra brugeren eller en ekstern API), overholder formelle regler (længde, format mv.) og stopper uhensigtsmæssige eller farlige input så tidligt som muligt. Det beskytter systemets grænser og forhindrer mange typer angreb som injection og buffer overflow.
-
Invarians sikrer, at objekter, som allerede er inde i systemet, altid er i en gyldig og konsistent tilstand, hvilket er essentielt for at opretholde systemets integritet og sikre, at fejl ikke spreder sig eller fører til uforudsete problemer.
At bruge begge tilgange sammen er en god praksis for defense in depth — flere lag af forsvar, der tilsammen skaber en mere robust og sikker applikation.
Dog skal man også overveje den performance- og kompleksitetsoverhead, som f.eks. gentagen validering kan medføre, især med tunge operationer som regex. Det kan derfor i visse tilfælde være nødvendigt at afveje, hvor meget validering der skal ske i hvert lag for at balancere sikkerhed og effektivitet.
📝 Instruktioner
- Inspicer metoden
ValidateNamei filenNameController.cs. Hvorfor oprettes der et nyt objekt med værdierne fra det modtagne DTO-objektperson? - Åbn filen
Person.cs, som kan findes i mappen Models. - Implementer håndhævelsen af invarians for de to argumenter i
Person-konstruktøren. (Reglerne er de samme som fra tidligere øvelser.) - Afprøv applikationen, og valider med forskellige inputs.
Bemærk, at den eneste regel, inputvalideringen håndhæver, er, at data skal være sat [Notnull]. - Hvad sker der, når du forsøger med f.eks. et navn på 21 karakterer?
🤔 Refleksionsspørgsmål
- Hvordan supplerer inputvalidering og håndhævelse af invarians hinanden i et forsvar-i-dybden (defense in depth) perspektiv?
- Hvilke risici kan opstå, hvis man kun anvender invarians eller kun inputvalidering?
- Hvordan kan gentagen validering (fx både i controller og i domænemodel) påvirke performance og kompleksitet?
- Under hvilke omstændigheder kunne det være hensigtsmæssigt at reducere valideringsniveauer for at optimere ydeevnen?
- Hvordan kan man sikre, at valideringsregler forbliver konsistente mellem inputvalidering og invarians?
Kobling til relevante standarder og principper
| Element i øvelsen | Relateret standard / princip | Kommentar |
|---|---|---|
| Invarianshåndhævelse | ISO/IEC 27002:2022, afsnit 8.26 (applikationssikkerhed) | Anbefaler validering og integritetstjek af input til en applikation. |
| OWASP ASVS 5.0.0, Kontrol 16.5 (Error Handling) | Krav om korrekt håndtering af fejl(undtagelser) | |
| Secure by Design (Johnsson et al.) | Fremhæver princippet om at skabe robuste domænemodeller og sikre objekters tilstand gennem konstruktion. |
🔗 Brugen af både inputvalidering og invarians understøtter en robust og sikker udviklingsproces, der sikrer systemets integritet og modstandsdygtighed over for angreb.