Wie ein API-Pentest funktioniert

Methodik statt Zufallstreffer

Ein API-Pentest folgt einer definierten Methodik, nicht einem Bauchgefühl. Etablierte Referenzen wie der OWASP Web Security Testing Guide (WSTG) und NIST SP 800-115 strukturieren das Vorgehen in Phasen. NIST SP 800-115 beschreibt den Zweck als Planung und Durchführung technischer Sicherheitstests, das Analysieren der Befunde und das Ableiten von Gegenmaßnahmen, mit Betonung auf konkreten Techniken sowie deren Nutzen und Grenzen.

Übertragen auf eine API ergibt sich ein reproduzierbarer Ablauf:

1. Recon und Discovery: Endpunkte, Parameter, Versionen und Dokumentation (z. B. OpenAPI-Spezifikationen) erfassen, inklusive undokumentierter oder veralteter Endpunkte.
2. Auth-Analyse: Wie werden Sitzungen, Token (etwa JWT) und Rollen vergeben und geprüft?
3. Autorisierungstests: systematisches Durchspielen von Berechtigungsfehlern auf Objekt-, Funktions- und Property-Ebene.
4. Fuzzing und Eingabevalidierung: unerwartete Werte, Typen und Formate an jeden Parameter senden.
5. Business-Logic-Tests: Prüfen, ob die fachliche Logik durch abweichende Reihenfolgen oder manipulierte Schritte ausgehebelt werden kann.
6. Befund und Dokumentation: jeder Treffer wird als nachvollziehbarer Request/Response belegt.

Der WSTG ordnet diese Bausteine fest zu, etwa 4.1 Information Gathering, 4.4 Authentication Testing, 4.5 Authorization Testing und 4.10 Business Logic Testing.

Was findet was: Scanner gegen API-Pentest

Warum Scanner Logik- und Berechtigungsfehler verfehlen

Signatur- und musterbasierte Scanner suchen nach bekannten Mustern: gefährliche Payloads, verräterische Fehlermeldungen, bekannte verwundbare Versionen. Berechtigungs- und Logikfehler haben aber kein solches Muster. Der WSTG formuliert es direkt: Ein Grund, warum automatisierte Werkzeuge schlecht darin sind, auf Schwachstellen zu testen, ist, dass sie nicht kreativ denken. Kreatives Denken müsse fallweise erfolgen, weil nahezu jede Anwendung einzigartig gebaut sei, selbst bei Nutzung gängiger Frameworks.

Beim Berechtigungsfehler Broken Function Level Authorization (BFLA) ist das besonders deutlich: Laut OWASP API Security Top 10 2023 erfordert die Ausnutzung, dass der Angreifer legitime API-Aufrufe an einen Endpunkt sendet, auf den er keinen Zugriff haben sollte. Es gibt keinen schädlichen Payload, kein Muster, das ein Scanner erkennen könnte: Der Aufruf sieht aus wie jede andere gültige Anfrage. Ob er erlaubt sein darf, ergibt sich erst aus der Rolle des Aufrufenden und dem fachlichen Kontext.

Zur Business-Logik schreibt der WSTG, automatisierte Werkzeuge täten sich schwer, den Kontext zu verstehen, weshalb solche Tests einem Menschen obliegen. Diese Klasse von Fehlern lasse sich nicht mit einem Werkzeug oder Scanner erkennen und hänge von den Fähigkeiten und der Kreativität des Testers ab. Das ist die Trennlinie: Scanner finden Muster, ein Pentest findet Logik.

BOLA, BFLA und BOPLA systematisch durchspielen

Die drei Berechtigungsklassen der OWASP API Security Top 10 2023 werden im Pentest gezielt und getrennt geprüft, weil sie auf verschiedenen Ebenen brechen.

BOLA (API1:2023) - Objektebene

Geprüft wird, ob ein authentifizierter Nutzer durch Manipulation einer Objekt-ID auf fremde Objekte zugreift. Die kanonische Methode aus dem WSTG (Insecure Direct Object References): Man legt mindestens zwei Nutzer mit jeweils eigenen Objekten an, kartiert alle Stellen, an denen Eingaben direkt auf Objekte verweisen, und versucht dann, mit Nutzer A auf Objekte von Nutzer B zuzugreifen. Mehrere Nutzer sparen Zeit, weil reale fremde IDs vorliegen statt geratener Werte.

BFLA (API5:2023) - Funktionsebene

Hier wird geprüft, ob ein regulärer Nutzer auf Funktionen zugreift, die ihm nicht zustehen. OWASP nennt als Leitfragen: Kann ein normaler Nutzer administrative Endpunkte erreichen? Kann er durch bloßes Ändern der HTTP-Methode (etwa von GET zu DELETE) sensible Aktionen auslösen? Kann ein Nutzer aus Gruppe X eine nur für Gruppe Y gedachte Funktion durch Erraten der URL aufrufen, etwa /api/v1/users/export_all?

BOPLA (API3:2023) - Eigenschaftsebene

APIs geben laut OWASP häufig sämtliche Objekt-Eigenschaften zurück. Getestet wird, ob die API zu viele Properties preisgibt (Excessive Data Exposure) oder Properties akzeptiert, die der Nutzer nicht setzen dürfte (Mass Assignment), etwa ein role- oder is_admin-Feld im Request-Body. Alle drei Klassen sind laut OWASP gut auffindbar (Detectability Easy), aber eben durch gezieltes Probieren, nicht durch Signaturerkennung.

Fuzzing und Business-Logic-Tests

Fuzzing ergänzt die Berechtigungstests: An jeden Parameter werden unerwartete Werte, falsche Typen, Grenzwerte und Sonderzeichen gesendet, um Eingabevalidierung, Fehlerbehandlung und Injection-Pfade zu prüfen (WSTG 4.7 Input Validation Testing). Fuzzing lässt sich teilautomatisieren, die Bewertung der Antworten bleibt aber Aufgabe des Testers, weil eine ungewöhnliche Antwort nicht automatisch eine Schwachstelle ist.

Business-Logic-Tests prüfen die fachliche Folgerichtigkeit. Der WSTG fragt sinngemäß: Wenn ein Authentifizierungsablauf die Schritte 1, 2, 3 in dieser Reihenfolge vorsieht, was passiert, wenn ein Nutzer von Schritt 1 direkt zu Schritt 3 springt? Gewährt die Anwendung dann fälschlich Zugriff (fail open), verweigert sie ihn, oder bricht sie mit einem 500-Fehler ab? Typische Prüfpunkte sind:

• Überspringen oder Umordnen von Schritten in mehrstufigen Abläufen (z. B. Kauf, Freigabe, Bezahlung).
• Wiederholtes Aufrufen einer Funktion über vorgesehene Grenzen hinaus.
• Manipulation von Werten zwischen den Schritten, etwa ein nachträglich gesenkter Preis vor dem Tender.
• Race Conditions und Timing, um Sperr- oder Reservierungslogik zu umgehen.

Diese Tests setzen Verständnis der Entwicklerabsicht voraus und sind laut OWASP zugleich am schwersten zu erkennen und oft am schädlichsten, wenn sie ausgenutzt werden.

Manuell, automatisiert, kontinuierlich

Der WSTG warnt vor dem Ein-Methoden-Irrtum: Viele Organisationen setzten historisch allein auf Penetration Testing, das aber too little too late im Entwicklungszyklus komme. Empfohlen wird ein ausgewogener Ansatz, der manuelle Prüfung, Quellcode-Review und automatisierte Tests kombiniert. NIST SP 800-115 betont entsprechend die jeweiligen Stärken und Grenzen der einzelnen Techniken.

Die drei Modi spielen unterschiedliche Rollen:

• Automatisiert (DAST/SAST/SCA): schnell, breit und für CI/CD geeignet, um nach jedem Release die offensichtlichen Schwachstellen (low hanging fruit) abzufangen. Findet keine Berechtigungs- oder Logikfehler.
• Manuell: kontextbezogen und kreativ, findet BOLA/BFLA/BOPLA und Business-Logic-Fehler, ist aber punktuell und ressourcenintensiv.
• Kontinuierlich: laufende Wiederholung der Tests, weil APIs sich ständig ändern und mit jedem neuen Endpunkt neue Berechtigungspfade entstehen.

Venedy setzt genau an dieser Lücke an: kontextbezogene, fortlaufende Berechtigungs- und Logikprüfung an der eigenen API, mit nachvollziehbarem Befund statt undurchsichtiger Bewertung.

Der reproduzierbare Befund

Ein Pentest-Ergebnis ist nur dann verwertbar, wenn es reproduzierbar belegt ist. Der WSTG mahnt, eine oberflächliche Prüfung erzeuge ein falsches Sicherheitsgefühl, das so gefährlich sein könne wie gar keine Prüfung. Befunde müssten sorgfältig verifiziert und False Positives ausgesondert werden, da eine falsche Meldung die gültige Aussage des restlichen Berichts untergraben könne.

Ein belastbarer API-Befund enthält daher:

• den exakten Request (Methode, Pfad, Header, Body, verwendetes Token bzw. Rolle),
• die zugehörige Response (Statuscode wie 200 OK, Header, relevanter Body-Auszug),
• den Nachweis der Berechtigungsverletzung, also dass die Antwort fremde Daten oder eine unzulässige Aktion zeigt,
• die Schritte zum Nachstellen sowie die betroffene Nutzer-/Rollenkonstellation.

Erst dieser Request/Response-Beleg macht aus einer Vermutung einen prüfbaren Befund, den Entwickler nachstellen, beheben und per Regressionstest absichern können. Das ist der Unterschied zwischen einem Scanner-Report voller Mustertreffer und einem Pentest, der Logik belegt.

Quellen

• WSTG - Introduction: Principles of Testing, Testing Techniques and The Need for a Balanced Approach OWASP Web Security Testing Guide (Stable), 2024
• WSTG - Penetration Testing Methodologies (OWASP Testing Framework) OWASP Web Security Testing Guide (Stable), 2024
• WSTG - Introduction to Business Logic Testing OWASP Web Security Testing Guide (Stable), 2024
• WSTG - Testing for Insecure Direct Object References (How to Test) OWASP Web Security Testing Guide (Stable), 2024
• API5:2023 Broken Function Level Authorization OWASP API Security Top 10 2023, 2023
• API3:2023 Broken Object Property Level Authorization OWASP API Security Top 10 2023, 2023
• API1:2023 Broken Object Level Authorization OWASP API Security Top 10 2023, 2023
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment NIST (National Institute of Standards and Technology), 2008