Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

API Security Testing Grundlagen

In diesem 125-Minuten-Modul nehmt ihr euch eine Rolle vor, die die Tool-Taxonomie aus DevSecOps Workflow bislang nur als einen Stichpunkt in Phase 4 kennt (“Endpunkte auf Authentifizierung, Rate Limiting, Injection prüfen”) und macht daraus drei echte Angriffe gegen eine mitgelieferte, absichtlich verwundbare Flask-Beispiel-API. Im ersten Hands-on-Block meldet ihr euch als eine Nutzerin an und ruft per curl trotzdem die Bestellung eines anderen Nutzers ab: BOLA (Broken Object Level Authorization), die laut OWASP API Security Top 10 häufigste API-Schwachstelle. Im zweiten Block jagt ihr mit einer einfachen Bash-Schleife den Login-Endpunkt und seht, dass beliebig viele Versuche ohne Lockout durchlaufen. Im dritten Block schickt ihr eine SQL-Injection über einen Suchparameter und bekommt Zugangsdaten aus einer Tabelle zurück, auf die der Endpunkt nie zugreifen sollte. Im vierten Block lasst ihr Schemathesis automatisiert gegen die mitgelieferte openapi.yaml laufen und seht direkt am Ergebnis, was ein generischer Scanner findet (die SQL-Injection als Server-Crash) und was er mangels Kontext nicht findet (BOLA und das fehlende Rate Limiting, beides Autorisierungs-/Logikfragen). Jeder Block endet mit einem Scan oder Testlauf gegen die mitgelieferte Musterlösung, in der alle drei Lücken behoben sind. Komplett lokal mit Flask, Flask-Limiter und Schemathesis: kein Cloud-Account, keine Kostenwirkung.

Teil der Cybersecurity-Weiterbildung: Querschnitt aus DevSecOps, Docker, Kubernetes und Secrets-Management.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

125 Minuten, live (remote oder vor Ort), Input & vier vollständige Hands-on-Blöcke auf einer mitgelieferten, absichtlich verwundbaren Flask-Beispiel-API

Teilnehmende

DevOps- und Security-Engineers sowie Entwickler:innen mit eigenen API-Services, die API-Endpunkte gezielt auf Autorisierung, Rate Limiting und Injection prüfen wollen

Voraussetzungen

Kein eigener Cloud-Account nötig: alles läuft lokal. Python 3 und curl lokal verfügbar, Grundkenntnisse in HTTP/REST hilfreich.

Warum dieses Training für deine Organisation wirkt

Drei Angriffe, eine echte API

Wo der DevSecOps-Workflow API Security Testing nur als Stichpunkt in Phase 4 nennt, greift ihr hier eine echte, lauffähige Flask-API tatsächlich an: BOLA per curl, Rate-Limiting-Bypass per Bash-Loop, SQL-Injection über einen Query-Parameter.

Was automatisierte Scans finden und was nicht

Derselbe Schemathesis-Scan gegen die mitgelieferte openapi.yaml deckt die SQL-Injection als Server-Crash zuverlässig auf, übersieht BOLA und das fehlende Rate Limiting aber vollständig, beides reine Autorisierungs-/Logikfragen, die ein generischer Schema-Scan nicht kennt. Dieser Kontrast ist live reproduzierbar, nicht nur behauptet.

Von der Lücke zur geprüften Musterlösung

Jeder Hands-on-Block endet mit demselben Angriff gegen die mitgelieferte Musterlösung: der Owner-Check gegen BOLA, Flask-Limiter gegen den Rate-Limiting-Bypass, eine parametrisierte Query gegen die SQL-Injection, dreimal live der Unterschied zwischen verwundbar und behoben.

Was Teilnehmende mitnehmen

  • BOLA (Broken Object Level Authorization) als häufigste API-Schwachstelle (OWASP API Security Top 10) verstehen: ein gültiger Token allein genügt nicht, der Besitz der angefragten Ressource muss geprüft werden.
  • Eine fremde Bestellung per curl mit dem eigenen, gültigen Token abrufen und live sehen, dass die API sie trotzdem ausliefert, danach denselben Aufruf gegen die Musterlösung mit Owner-Check (403) wiederholen.
  • Einen Rate-Limiting-Bypass gegen einen Login-Endpunkt per Bash-Schleife demonstrieren und erkennen, woran fehlendes Rate Limiting zu erkennen ist (keine Verzögerung, kein Lockout, kein 429), danach denselben Lauf gegen eine Flask-Limiter-Konfiguration mit Fehlschlag ab der festgelegten Schwelle wiederholen.
  • SQL-Injection über einen API-Query-Parameter ausnutzen (nicht nur über ein klassisches Login-Formular) und Daten aus einer Tabelle abrufen, auf die der Endpunkt nie zugreifen sollte, danach dieselbe Anfrage gegen eine parametrisierte Query ohne Wirkung wiederholen.
  • Eine mitgelieferte openapi.yaml mit Schemathesis automatisiert scannen (property-based API-Testing) und einordnen, welche Fundklasse ein solcher Scan zuverlässig findet (Server-Crashes wie die SQL-Injection) und welche er mangels Autorisierungskontext nicht findet (BOLA, Rate Limiting).
  • Alle drei Fundklassen als Teil eines API-Security-Testing-Schritts in der CI/CD-Pipeline einordnen, als Vertiefung zu der Phase-4-Erwähnung in DevSecOps Workflow.

Für wen dieses Modul ideal ist

  • • DevOps- und Security-Engineers, die API Security Testing aus dem DevSecOps-Workflow-Stichpunkt jetzt hands-on umsetzen wollen
  • • Entwickler:innen mit eigenen API-Services, die Autorisierung, Rate Limiting und Eingabevalidierung an ihren eigenen Endpunkten gezielt prüfen wollen
  • • Teams, die einen automatisierten API-Scan (z. B. Schemathesis) in eine CI/CD-Pipeline einbauen wollen und vorher verstehen möchten, welche Lückenklassen er abdeckt und welche nicht

Rahmendaten

  • • Dauer: 125 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, vier vollständige Hands-on-Blöcke auf einer mitgelieferten, absichtlich verwundbaren Flask-Beispiel-API
  • • Voraussetzungen: Kein eigener Cloud-Account nötig, Python 3 und curl lokal verfügbar, Grundkenntnisse in HTTP/REST hilfreich

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu DevSecOps Workflow (dort API Security Testing nur ein Stichpunkt in Phase 4, keine eigene Vertiefung) und zu SAST & Secret Detection (dort Quellcode- und Secret-Scanning vor dem Deployment, hier Angriffe gegen eine bereits laufende API). Vorstellung der mitgelieferten, absichtlich verwundbaren Flask-Beispiel-API.

  2. Hands-on 1: BOLA (Broken Object Level Authorization) (25 min): Konzept (häufigste API-Schwachstelle laut OWASP API Security Top 10, ein gültiger Token ersetzt keinen Owner-Check), danach per curl mit dem eigenen Token eine fremde Bestellung abrufen, die Lücke live bestätigen, anschließend denselben Aufruf gegen die Musterlösung mit Owner-Check (403) wiederholen.

  3. Hands-on 2: Rate-Limiting-Bypass (20 min): Konzept (fehlendes Rate Limiting als Brute-Force-Einladung), danach mit einer Bash-Schleife beliebig viele Login-Versuche gegen den Endpunkt fahren und das Fehlen von Lockout/429 live sehen, anschließend denselben Lauf gegen eine Flask-Limiter-Konfiguration mit Abbruch ab der festgelegten Schwelle wiederholen.

  4. Hands-on 3: Injection über API-Parameter (25 min): Konzept (Injection ist nicht an ein HTML-Formular gebunden, sondern an jeden ungeprüften Eingabepfad, hier ein Query-Parameter), danach eine SQL-Injection gegen den Such-Endpunkt fahren und Zugangsdaten aus einer eigentlich unerreichbaren Tabelle abrufen, anschließend denselben Payload gegen die parametrisierte Query der Musterlösung ohne Wirkung wiederholen.

  5. Hands-on 4: Automatisierter Scan gegen openapi.yaml (25 min): die mitgelieferte openapi.yaml mit Schemathesis automatisiert scannen, zuerst gegen die verwundbare API (die SQL-Injection fällt als Server-Crash auf, BOLA und Rate-Limiting-Bypass bleiben unentdeckt), danach gegen die Musterlösung (saubere Durchläufe). Einordnung, welche Fundklassen ein generischer Scan abdeckt und welche gezieltes manuelles Testen weiterhin braucht.

  6. Recap & Fazit (20 min): Zusammenfassung aller drei Lückenklassen und ihrer jeweiligen Behebung, Einordnung von API Security Testing als eigenständiger Schritt neben SAST/Secret Detection und Container Image Scanning, offene Fragen, Kontaktmöglichkeit.

Abgrenzung: Dieses Modul behandelt bewusst keine erneute Tool-Taxonomie oder Phasen-Einordnung des gesamten DevSecOps-Workflows (dafür DevSecOps Workflow), kein Sourcecode- oder Secret-Scanning vor dem Deployment (dafür SAST & Secret Detection), kein Container Image Scanning auf Binary/Artifact-Ebene (dafür Container Image Scanning & Vulnerability Management mit Trivy) und keine vollständige OWASP-API-Security-Top-10-Vertiefung (nur die drei Klassen BOLA, Rate Limiting, Injection werden hands-on behandelt, nicht alle zehn).

Hands-on Inhalte (Auszug)

BOLA (Broken Object Level Authorization)

  • Fremde Bestellung per curl mit eigenem, gültigem Token abrufen
  • Owner-Check-Fix in der Musterlösung: 403 statt Datenleck
  • Häufigste API-Schwachstelle laut OWASP API Security Top 10

Rate-Limiting-Bypass

  • Bash-Loop gegen Login-Endpunkt ohne Lockout
  • Flask-Limiter als Fix: Abbruch ab festgelegter Schwelle
  • Brute-Force-Risiko ohne Rate Limiting live gezeigt

Injection über API-Parameter

  • SQL-Injection über einen Such-Query-Parameter, nicht über ein Formular
  • Zugangsdaten aus einer eigentlich unerreichbaren Tabelle abrufen
  • Parametrisierte Query als Fix: derselbe Payload bleibt wirkungslos

Automatisierter Scan mit Schemathesis

  • Scan gegen die mitgelieferte openapi.yaml, kein Cloud-Dienst nötig
  • Findet die SQL-Injection zuverlässig als Server-Crash
  • Findet BOLA und den Rate-Limiting-Bypass nicht: reine Logikfragen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur erfolgreichen BOLA-Ausnutzung, Ergebnis des Schemathesis-Laufs gegen die Musterlösung) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Beispiel-API und die Angriffsszenarien auf eure tatsächliche API-Landschaft an.

Academy Briefing anfragen