Skip to content

Øvelse 9 – OSINT med GitHub

Forfatter: Mathias Greisen

Dato: 2026-09-11

Fag/modul: IT-Sikkerhed i Webapplikationer

Status: Færdig

1. Beskrivelse af øvelsen

Open Source Intelligence (OSINT) handler om at identificere offentlig tilgængelig information, som utilsigtet kan misbruges af angribere. I softwareprojekter kan det ofte ske, at følsomme oplysninger – som fx adgangskoder eller API-nøgler – ved en fejl uploades til offentlige repositories. Det kan have alvorlige sikkerhedsmæssige konsekvenser.

Kontekst

Denne opgave handler om at finde hvilken sensitiv information der er blevet uforvarende delt via GitHub.

Kildekoden til en applikation i en offentlig repository på GitHub udstiller uhensigtsmæssigt et stykke information for meget.

🔗 Link til repo

Opgave:

  1. Find og forklar hvilken information, der udstilles uhensigtsmæssigt.
  2. Hvorfor er det et problem?
  3. Hvordan burde informationen være håndteret i stedet?

2. Reproduktion trin for trin

Trin

  1. Åben github repository

  2. Bug søge funktionen øverst på siden, til at søge i repo. Prøv med keywords som f.eks. "api":

    repo:mesn1985/DotNetApplicationWithToMuchInformation api

  3. Find api nøgle i koden:

appsettings.json
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Shop": {
    "ApiToken": "abc123def456ghi789",
    "ConnectionString": "Server=(localdb)\\Shop;Integrated Security=true;"
  }
}

3. Problemer og løsninger

Jeg løb ikke ind i problemer under denne øvelse.

4. Resultater og besvarelser

  1. Find og forklar hvilken information, der udstilles uhensigtsmæssigt.

    • En api nøgle kan findes i koden. Dette er unhensigtmæssigt da det potentielt kan give en aktør priviligeret adgang til en api efter den er sat i brug.

  2. Hvorfor er det et problem?

    • Priviligeret adgang kan lede til at aktøren uforventet får adgang til systemet.

    • Når der er tale om en api nøgle efterladt i koden, er det også ofte en nøgle med fuld adgang til systemet, da den sandsynligvis blev brugt under udviklingsprocessen.

    • Dette kan altså potentielt give aktøren adgang til sensitive informationer eller til sårbare dele af systemet som så måske kan kompromitteres.

  3. Hvordan burde informationen være håndteret i stedet?

    • Api nøglen burde have være gemt i en lokal nøglebok eller i miljøvariabler. På den måde ville man også let kunne skifte denne nøgle, f.eks. i en CI/CD pipeline, når api'en skal sættes i produktion.

5. Anvendte ressourcer

  • Kapitel 6 i "Hacking API's af Corey J. Ball"

6. Opsummering af erfaringer

[Opsummer hvad du har lært af øvelsen. Hvad tager du med dig videre? Hvad ville du gøre anderledes en anden gang? Hvordan kan denne viden bruges i fremtidige opgaver eller i en professionel sammenhæng?]

Øvelsen har givet læring omkring hvordan glemte eller sensitive informationer kan være glemt og dermed findes i source kode for applikationer.

Dette er en stor sikkerhedsrisiko som man altid bør tjekke får når man gemme/offentliggører sin source kode. Skulle tilfældet dog være ude, skal man sikre sig at at api-nøglen bliver fjernet fra koden og skiftet.

Ved passiv rekognoscering kan denne sårbarhed findes og senere bruges til at opnå eller eskalere adgangen til et system.

Vigtigste pointer

  • Tjek altid source kode for sensitive informationer.
  • Gem aldrig selv sensitive informationer i source koden.