Skip to content

Øvelse 18 - Inputvalidering til konsolapplikation

Source code

using System;
using System.Text.RegularExpressions;

namespace ValidateTheName
{
    internal class Program
    {
        static void Main(string[] args)
        {
            while (true)
            {
                Console.WriteLine("Please input you name:");
                string nameInput = Console.ReadLine();

                if (nameInputIsvalid(nameInput))
                {
                    Console.WriteLine($"The name {nameInput} is a valid name");
                }
                else
                {
                    Console.WriteLine($"The name {nameInput} is an Invalid name");
                }

            }
        }

        static bool nameInputIsvalid(string? nameInput)
        {
            //insert validation code here.
            if (nameInput == null || nameInput.Length > 20 || nameInput.Length < 3) return false;

            Regex regex = new Regex(@"^[A-Za-zÆØÅæøå]+$");

            if (!regex.IsMatch(nameInput)) return false;

            return true;
        }



    }
}

Reflekterende spørgsmål

  1. Hvorfor er det vigtigt at kontrollere længden på input, inden man anvender Regex til validering?

Hvis man ikke tjekker længden inden kan man risikere at lange input når til regex validering. Dette kan koste mange ressource og måske endda ligge systemet ned ved mange requests (dos / ddos).

  1. Hvordan kan dårligt designede Regex-udtryk føre til sikkerhedsproblemer som DoS-angreb?

Dårlig regex kan også føre til Dos-angreb da nogle udtryk kan udnyttes så regex tjekket tager lang tid og bruger man ressourcer.

  1. Hvilke typer af angreb kan opstå, hvis inputvalidering ikke implementeres korrekt, særligt i API-kontekster?

Hvis man f.eks. tillader javascript kode som input, så kan det føre til Cross-Site Scripting (XSS), hvor koden vil køre hos alle brugere hvis inputtet vises i applikationen uden sanitization.

  1. Hvordan hænger inputvalidering sammen med konceptet om tillidsgrænser i softwarearkitektur?

En applikations tillidsgrænse er det som den selv kontrollerer. Altså skal man have inputvalidering så snart input kommer ind ude fra den anden side af tillidsgrænsen da applikationen dermed ikke selv har kontrol over hvad der kan komme ind, ihvertfald ikke før valideringen.

  1. Hvordan kan man kombinere inputvalidering med andre sikkerhedsforanstaltninger for at opnå en mere robust applikation?

Defence in depth, altså flere sikkerhedsforanstalninger sammen kan gøre at andre foranstalninger forhåbentligt fanger problemet hvis et tidligere lag ikke gør. Det kunne f.eks. være at man encoder / escaper output fra en api. På den måde vil f.eks. javascript forhåbentligt ikke blive indlæst i browseren selv hvis det var lykkedes nogen at få det igennem input valideringen.

  1. Hvilke overvejelser bør man gøre sig omkring brugeroplevelsen, når man implementerer streng inputvalidering?

Det kræver at man er god til at forklare hvad der er gyldigt og ikke gyldigt ved input for ikke at skabe forvirring hos brugeren. Samtidigt kan string validering gøre brugeroplevelsen dårligere.

Kobling til standarder

Element i øvelsen Relateret standard / princip Kommentar
Inputvalidering ISO/IEC 27002:2022, afsnit 8.26 (applikationssikkerhed) Anbefaler validering og integritetstjek af input til en applikation.
OWASP ASVS 5.0.0, kontrol 2.2 (Input Validation) Krav om validering af data.
Secure by Design (Johnsson et al.) Understreger vigtigheden af at beskytte tillidsgrænser og sikre korrekt inputvalidering.