Øvelse 31 – Taint-analyse med falsk positiv

https://its-software-sikkerhed-90b345.gitlab.io/exercises/31_Static_code_analysis_With_snyk_false_positive

---

1. Reproduktion trin for trin

1. I klassen HomeController, opret en privat metode til validering af en tekststreng. Teksten må kun indeholde alfabetiske karakterer.

   private bool NameInputIsvalid(string? nameInput)
   {
       Regex regex = new Regex(@"^[A-Za-zÆØÅæøå]+$");
   
       if (!regex.IsMatch(nameInput)) return false;
   
       return true;
   }
   

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.

   [HttpGet("SearchStudentUnsecure")]
   public async Task<IActionResult> SearchStudentUnsecure(string name)
   {
       if (!NameInputIsvalid(name))
       {
           throw new ArgumentException("Name is not valid");
       }
   
       var conn = _context.Database.GetDbConnection();
       var query = "SELECT FirstName, LastName FROM Student WHERE FirstName Like '%" + name + "%'";
       IEnumerable<Student> students;
   
       try
       {
           await conn.OpenAsync();
           students = await conn.QueryAsync<Student>(query);
       }
   
       finally
       {
           conn.Close();
       }
       return Ok(students);
   }
   

3. Eksekver taint-analysen med Snyk.

   snyk code test
   

4. Notér, om SQL Injection stadig detekteres som en sårbarhed.

    ✗ [High] SQL Injection
    Path: Controllers/HomeController.cs, line 38
    Info: Unsanitized input from an HTTP parameter flows into QueryAsync, where it is used in an SQL query. This may result in an SQL Injection vulnerability.
   

   • Den melder det samme selvom input nu valideres.

---

2. Reflekterende spørgsmål

1. Hvordan påvirker falske positiver tilliden til automatiserede analyseværktøjer?

   • Det gør at man måske mister tilliden til at det er korrekt og dermed også ender med at ignorere eller overse de rigitge fundne sårbarheder.

2. Hvorfor er manuel kodegennemgang nødvendig, selv når man bruger statisk kodeanalyse?

   • Det er det netop for at tjekke for falske positiver og finde de korrekte sårbarheder.

3. Hvordan kan forretningslogiske fejl undslippe statisk kodeanalyse?

   • Den statiske analyse kender ikke til forretningslogikken og den kan dermed heller ikke analysere om kodelogikken er rigtig eller forkert.

4. Hvilke metoder kan kombineres med statisk analyse for at sikre et mere robust sikkerhedsarbejde?

   • Kan kombineres med Dynamisk Kode analyse (hvor programmet køres og den tester for om de funde sårbarheder rent faktisk kan udnyttes), Manuel kode gennemgang, sikkerhedstests (fx pentest).

5. Hvordan kan man balancere mellem at reducere falske positiver og sikre, at reelle sårbarheder ikke overses?

   • Ved at have flere forskellige metoder som til sammen kan danne et billede. Man må altså ikke bare kassere resultater, men istedet sammenholde de forskellige resultater og gerne tjekke dem manuelt.

---

3.

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årbarhedsanalyse som en del af sikkerhedstest.
	OWASP ASVS 5.0.0, kapitlet "Assessment and Certification"	Afsnittene "Verification Mechanisms" og "The Role of Automated Security Testing Tools" omtaler anvendelsen – hensigtsmæssig og uhensigtsmæssig – af automatiserede værktøjer.
	Secure by Design	Fremhæver værdien af analyseværktøjer, og viser svagheder ift. manglende invarians ved objekters instantiering.