Taint Analysis for Graph APIs Focusing on Broken Access Control

Dit paper presenteert een systematische aanpak voor statische en dynamische taint-analyse van Graph API's om gebroken toegangscontrole te detecteren, waarbij graftransformatieregels en kritieke paar-analyse worden gebruikt om onbevoegde datastroom tussen bronnen en zinken te identificeren en te valideren.

De kern

De Digitale Sleutels: Hoe je een Graph API op zijn veiligheid controleert

Stel je voor dat een Graph API (zoals die van GitHub of Facebook) een enorm, levendig spookhuis is. In dit huis zijn alle data (foto's, berichten, bestanden) niet in mappen opgeslagen, maar verbonden als een gigantisch web van knopen en lijnen. Een foto is een knoop, en de link naar de persoon die hem heeft geplaatst is een lijn.

Het probleem? In zo'n groot, complex web is het heel makkelijk om per ongeluk een deur open te laten staan waar niemand had moeten kunnen binnenkomen. Dit heet "Broken Access Control" (gebroken toegangscontrole).

De auteurs van dit artikel hebben een nieuwe manier bedacht om te controleren of die deuren echt op slot zitten. Ze noemen hun methode "Taint Analysis" (Vuilneming-analyse).

1. Het Concept: "Vuil" Maken (Tainting)

Stel je voor dat je in dat spookhuis een paar specifieke objecten hebt die heel gevoelig zijn: bijvoorbeeld de sleutels tot de kluis of geheime documenten.

In de taal van de onderzoekers noemen ze deze gevoelige objecten "gecontamineerd" of "gevuild" (tainted).

• De Vlek: Als een object "gevuild" is, betekent dit: "Dit is geheim of gevoelig. Alleen mensen met een speciale sleutel (rechten) mogen hierbij."
• Het Doel: De onderzoekers willen weten: Komen deze "vuile" objecten op de verkeerde plekken terecht?

2. De Drie Stappen van de Detectie

De methode bestaat uit drie fases, die we kunnen vergelijken met het inspecteren van een veiligheidsplan voor een museum.

Fase 1: De Opzet (Het Tekenplan)
Eerst maakt de veiligheidsinspecteur een tekening van het museum (de API).

• Hij markeert welke objecten "gevuild" zijn (bijvoorbeeld: Repository = een code-bibliotheek).
• Hij noteert welke regels er gelden: "Alleen de eigenaar mag de kluis openen, niet de schoonmaker."
• Hij maakt een lijst van alle mogelijke acties: "Iemand kan een nieuwe kluis maken (Source)" en "Iemand kan een kluis openen (Sink)".

Fase 2: De Statische Analyse (Het Simuleren zonder te bewegen)
Nu kijkt de inspecteur naar het tekenplan en vraagt hij zich af: "Als ik deze twee regels achter elkaar uitvoer, kan er iets misgaan?"

Ze gebruiken een slimme wiskundige techniek (genaamd Critical Pair Analysis) om te kijken of er een pad is tussen het maken van een gevoelig object en het gebruiken ervan.

• Directe link: Iemand maakt een kluis en probeert hem direct weer open te maken.
• Indirecte link: Iemand maakt een kluis, bouwt er een muur omheen, en probeert hem dan open te maken.

De computer zoekt automatisch naar alle mogelijke combinaties. Als de computer ziet dat een "schoonmaker" (geen rechten) een "kluis" kan openen die net is gemaakt door een "eigenaar", dan zegt de computer: "Let op! Hier is een potentieel gat in de beveiliging!"

Belangrijk: De computer is slim, maar niet perfect. Soms denkt hij dat er een gat is, terwijl er in werkelijkheid een muur tussen zit die het probleem oplost (een vals alarm). Daarom is er een derde stap nodig.

Fase 3: De Dynamische Analyse (Het Echte Testen)
Nu gaan de inspecteurs het museum echt binnenlopen om te testen.

• Ze nemen de "vals alarms" van de computer en proberen ze in het echt na te bootsen.
• Ze spelen de rol van de "schoonmaker" en proberen de "kluis" open te maken.
• Resultaat:
  • Als de deur echt open gaat: Bingo! We hebben een echte beveiligingslek gevonden.
  • Als de deur dicht blijft: Geruststellend. De computer had een vals alarm. De beveiliging werkt zoals het hoort.

3. Het Voorbeeld uit de Wereld: GitHub

De auteurs hebben hun methode getest op GitHub (waar programmeurs hun code opslaan).

• Het scenario: Stel, een gebruiker maakt een nieuwe code-bibliotheek (Repository). Alleen de eigenaar mag deze later bewerken.
• De test: De computer zoekt naar combinaties waarbij iemand anders (bijvoorbeeld een medewerker) die bibliotheek toch kan bewerken.
• De ontdekking: Ze hebben een echte fout gevonden die al in de GitHub-community bekend was (een bug waar gebruikers over klaagden). Hun methode kon dit probleem systematisch vinden en bewijzen dat het bestond.

Waarom is dit belangrijk?

Vroeger moesten beveiligingsexperts handmatig door duizenden regels code graven om te zien of er gaten waren. Dat is als het zoeken naar een naald in een hooiberg.

Met deze nieuwe methode:

1. Automatisering: De computer doet het zware werk van het vinden van mogelijke gaten.
2. Systematisch: Je mist geen combinaties.
3. Betrouwbaar: Je weet precies welke gaten echt gevaarlijk zijn en welke niet.

Samenvatting in één zin

De auteurs hebben een slimme, tweestaps-methode ontwikkeld (eerst computer-simulatie, dan echte test) om in complexe digitale netwerken (Graph APIs) automatisch te vinden of gevoelige data per ongeluk in de verkeerde handen terechtkomt, zodat hackers niet bij de kluis kunnen komen.

Technische samenvatting

Probleemstelling

Graph API's (zoals GraphQL) modelleren data van webapplicaties als een graaf, waarbij objecten knopen zijn en relaties randen. Hoewel deze API's populair zijn geworden (bijv. bij GitHub, Facebook), ontbreekt er een gestructureerde aanpak om ze veilig te testen tegen veelvoorkomende webveiligheidsrisico's, met name Broken Access Control (BAC).
BAC treedt op wanneer gebruikers toegang krijgen tot data of functies die buiten hun bevoegdheden vallen, of juist geen toegang krijgen waar ze wel recht op hebben. Bestaande beveiligingsmethodes zijn vaak niet specifiek ontworpen voor de grafische structuur van Graph API's, wat leidt tot kwetsbaarheden die moeilijk te detecteren zijn. Er is een behoefte aan een methode die zowel de dataflow als de toegangsrechten (rollen) systematisch kan analyseren.

Methodologie

De auteurs presenteren een systematische aanpak voor taint analysis (vervuilingsanalyse) die specifiek is ontworpen voor Graph API's. De methode combineert formele modellering met dynamische validatie en bestaat uit drie fasen:

1. Setup (Modellering en Tainten):

   • De Graph API wordt formeel gemodelleerd als een graaftransformatiesysteem (Graph Transformation System) met regels die typen zijn over een type-graaf (TG).
   • Een beveiligingsanalist identificeert gevoelige data (bijv. repositories, issues) en markeert de corresponderende knopen in de type-graaf als "verontreinigd" (tainted).
   • Op basis van een rolgebaseerd toegangsbeleid (RBAC) worden API-calls geïdentificeerd als:
     • Source-regels: Regels die verontreinigde data creëren (bijv. createRepo).
     • Sink-regels: Regels die verontreinigde data lezen of manipuleren (bijv. updateRepo, deleteIssue).

2. Statische Analyse:

   • Het doel is om potentieel risicovolle dataflows tussen source- en sink-regels te detecteren zonder de applicatie daadwerkelijk uit te voeren.
   • De auteurs gebruiken Critical Pair Analysis (CPA), een techniek uit de graaftransformatie-theorie, om afhankelijkheden tussen regels te berekenen.
   • Een "verontreinigde informatiestroom" wordt gedefinieerd als een afhankelijkheid waarbij een verontreinigde knoop wordt gecreëerd door een source-regel en later wordt gebruikt door een sink-regel.
   • Directe vs. Indirecte kwetsbaarheden: De analyse is volledig (sound) voor directe kwetsbaarheden (waar de sink direct op de source volgt). Voor indirecte kwetsbaarheden (waar tussenliggende regels voorkomen) bewijzen de auteurs dat de analyse ook sound is onder specifieke voorwaarden: als de tussenliggende regels sequentieel onafhankelijk zijn van de source/sink en het toegangsbeleid stabiel onder verschuiving is (de volgorde van calls beïnvloedt de toegangsrechten niet).

3. Dynamische Analyse:

   • Omdat de statische analyse niet compleet is (ze kan false positives genereren), wordt deze aangevuld met dynamische tests.
   • Op basis van de gevonden afhankelijkheden worden taint-tests gegenereerd. Deze tests bestaan uit API-uitvoeringen met specifieke rollen (tokens).
   • Positieve tests: Verwachten succes (geen fout) wanneer een gebruiker met voldoende rechten de actie uitvoert.
   • Negatieve tests: Verwachten een fout (BAC-uitzondering) wanneer een gebruiker met onvoldoende rechten probeert de actie uit te voeren.
   • De tests voldoen aan Flow Coverage (alle afhankelijkheden worden getest) en Role Coverage (verschillende rollencombinaties worden getest).

Belangrijkste Bijdragen

• Eerste systematische aanpak: Dit is het eerste werk dat taint analysis toepast op Graph API's met een specifieke focus op Broken Access Control.
• Formele basis: De methode maakt gebruik van graaftransformatie (Double Pushout - DPO) en Critical Pair Analysis om dataflows formeel en sound te modelleren.
• Soundheid voor indirecte flows: De auteurs bewijzen theoretisch onder welke voorwaarden de statische analyse ook indirecte kwetsbaarheden kan detecteren (via verschuiving van regels).
• Integratie van statisch en dynamisch: Een hybride aanpak waarbij statische analyse de testcases genereert en dynamische analyse de implementatie verifieert.
• Toepassing op GitHub: De methode is succesvol toegepast op een deel van de GitHub GraphQL API, inclusief het reproduceren van een bestaand veiligheidsprobleem (issue 106598) uit het GitHub-forum.

Resultaten

• Validatie op een voorbeeld: De methode werd getoetst aan een vereenvoudigde GitHub-achtige API. De statische analyse identificeerde correct de afhankelijkheden tussen creatie en manipulatie van repositories, projecten en issues.
• GitHub Case Study:
  • De analyse werd toegepast op een reëel probleem (issue 106598) waarbij de toegang tot de compare-field in de GraphQL-schema afhankelijk was van het type authenticatietoken (OAuth vs. fine-grained tokens).
  • De dynamische tests reproduceerden het probleem succesvol: een test met een OAuth-token zonder de juiste scope faalde (verwacht gedrag), terwijl een test met een fine-grained token zonder scope wel slaagde (onverwacht gedrag/veiligheidslek).
• Detectie van twee BAC-typen: De aanpak kon systematisch twee soorten fouten detecteren:
  1. Gebruikers die wel toegang zouden moeten hebben, maar die wordt geweigerd (te strikt beleid).
  2. Gebruikers (of aanvallers) die toegang krijgen tot data die ze niet zouden mogen hebben (te laks beleid).

Significantie

Deze paper biedt een cruciale stap voorwaarts in de beveiliging van moderne Graph API's.

• Formele Rigor: Door gebruik te maken van graaftransformatie en bewezen theorieën (CPA), biedt de methode een hogere mate van zekerheid dan veel bestaande, vaak heuristische tools.
• Praktische Toepasbaarheid: De integratie met bestaande tools (zoals Henshin voor statische analyse en Pytest voor dynamische tests) maakt de aanpak toepasbaar in de praktijk.
• Proactieve Beveiliging: De methode stelt beveiligingsanalisten in staat om kwetsbaarheden te vinden in de ontwerp- en implementatiefase, voordat deze in productie gaan.
• Toekomstperspectief: Het werk legt de basis voor verdere automatisering, zoals het automatisch vertalen van GraphQL-schema's naar graaftransformatieregels en het uitbreiden van de theorie om nog complexere indirecte afhankelijkheden te dekken.

Kortom, het artikel presenteert een robuust, formeel onderbouwd raamwerk dat de kloof overbrugt tussen de complexe datastructuren van Graph API's en de noodzaak voor strikte toegangscontrole.