Skip to content

🛡️ Øvelse 31 – Taint-analyse med falsk positiv

ℹ️ Information

Taint-analysen følger data fra kilder (source) til følsomme operationer (sink) for at identificere potentielle sikkerhedsrisici. Dog kan den ikke altid forstå konteksten og vurderer derfor ofte data som usikker, selvom der er foretaget tilstrækkelig inputvalidering. Dette kaldes en falsk positiv.

Falske positiver kan føre til øget tidsforbrug og "alarmtræthed", hvor man overser rigtige sårbarheder på grund af for mange irrelevante advarsler. Derfor er det vigtigt at forstå begrænsningerne ved statisk analyse.

Statisk kodeanalyse bør aldrig stå alene i sikkerhedsarbejdet. Det er altid nødvendigt, at et menneske gennemgår koden, fordi statisk analyse kun kan finde tekniske fejl i koden – ikke forretningslogiske fejl. For eksempel kan et system, der tillader bestilling af -1 bøger, have en alvorlig forretningslogisk fejl, som statisk analyse ikke kan fange.

Derfor skal statisk analyse kombineres med manuel kodegennemgang, sikkerhedstest og andre metoder for at opnå en helhedsorienteret sikkerhedsvurdering.

Et eksempel på falsk positiv opstår, når man samler en valideret variabel med tekst, som her:

var query = "SELECT FirstName, LastName FROM Student WHERE FirstName LIKE '%" + name + "%'";

Variablen name kan være valideret, men fordi den indgår i en sammensat tekststreng, vil taint-analysen stadig betragte query som tainted, og dermed rapportere en mulig sårbarhed, selvom input er valideret.

I Øvelsen, skal du forsat bruge ASP.NET-Core-SQL-Injection-Example projektet.

📝 Instruktioner

  1. I klassen HomeController, opret en privat metode til validering af en tekststreng. Teksten må kun indeholde alfabetiske karakterer.
  2. I metoden SearchStudentUnsecure skal du nu bruge valideringsmetoden til at validere tekststrengen name. Valideringsmetoden skal være den første metode, der bliver kaldt.
  3. Eksekver taint-analysen med Snyk.
  4. Notér, om SQL Injection stadig detekteres som en sårbarhed.

🤔 Refleksionsspørgsmål

  1. Hvordan påvirker falske positiver tilliden til automatiserede analyseværktøjer?
  2. Hvorfor er manuel kodegennemgang nødvendig, selv når man bruger statisk kodeanalyse?
  3. Hvordan kan forretningslogiske fejl undslippe statisk kodeanalyse?
  4. Hvilke metoder kan kombineres med statisk analyse for at sikre et mere robust sikkerhedsarbejde?
  5. Hvordan kan man balancere mellem at reducere falske positiver og sikre, at reelle sårbarheder ikke overses?

🔗 Kobling til relevante standarder og principper

Element i øvelsen Relateret standard / princip Kommentar
Taint-analyse og statisk kodeanalyse ISO/IEC 27002:2022, afsnit 8.29 (Security testing) Anbefaler brug af sikkerhedstest og sårbarheds analyse som en del af sikkerhedstest.
OWASP ASVS 5.0.0, Kapitellet "Assessment and Certification" Afsnittene "Verification Mechanisms" og "The Role of Automated Security Testing Tools" omtaler anvendelsen hensigt og uhensigtmæssig brug af automatiseret værktøjer
Secure by Design Fremhæver værdien af analyseværktøjer, og viser svagheder ift. manglende invarians ved objekters instantiering

💡 Statisk analyse er et værdifuldt redskab, men skal altid anvendes som en del af en bredere sikkerhedsstrategi for at undgå fejlfortolkninger og sikre robusthed.

Last update: 2026-10-21 13:27:38