Skip to content

Øvelse 30 – Grundlæggende taint-analyse med Snyk

https://its-software-sikkerhed-90b345.gitlab.io/exercises/30_Static_code_analysis_With_snyk/

1. Reproduktion trin for trin

  1. Klon projektet fra dette repository.

    git clone https://github.com/brunobritodev/ASP.NET-Core-SQL-Injection-Example.git

  2. I den klonede projekts mappe, skift til mappen SqlInjection.

    cd ASP.NET-Core-SQL-Injection-Example

cd SqlInjection

  3. Udfør taint-analysen ved at følge instruktionerne fra afsnittet Testing a repository from its root folder i denne dokumentation.

    snyk code test

  4. Notér, hvilket linjenummer SQL-injection sårbarheden bliver fundet på.

     ✗ [High] SQL Injection
 Path: Controllers/HomeController.cs, line 32
 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.

  5. Verificér i koden, at linjenummeret for sårbarheden er der, hvor den forurenede data sendes til sink.

    22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
    [HttpGet("SearchStudentUnsecure")]
public async Task<IActionResult> SearchStudentUnsecure(string name)
{
    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);
}
    • Det er præcis den linje at der sendes data til databasen.

2. Reflekterende spørgsmål

  1. Hvordan hjælper taint-analyse med at identificere sikkerhedsrisici i software?

    • Ved at finde de steder hvor rå data slipper igennem til sink (f.eks. en sql query) uden at det bliver valideret.

  2. Hvilke begrænsninger har automatiserede statiske analyseværktøjer som Snyk i forhold til kompleks kode og kontekst(domæne viden)?

    • Den har ikke viden om domænet og med kompleks kode kan der være mange mulige veje for data. Derfor kan den også sagtens give falske positiver hvis den ikke kan se at data valideres.

  3. Hvordan kan viden om kildedata (source) og destinationssted (sink) i koden forbedre sikkerhedsarbejdet?

    • Det kan det ved at man lettere kan tjekke om man nu også husker at validere og sanitere det data som kommer ind fra en source inden det når til sink.

  4. Hvordan bør fundne sårbarheder håndteres i udviklings- og driftsprocessen for at øge sikkerheden?

    • Systemet bør ikke udgives hvis der findes sårbarheder ved automatiske tests eller manuelle test. Medmindre man selvfølgelig vurderer at risikoen er så lille og at man godt kan vente med at fikse det i næste udgivelse.
    • Ellers skal sårbarheden eller sårbarhederne fjernes inden release.

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.