Pentest von REST und GraphQL APIs: Technische Checkliste fur legales Bug Bounty

APIs sind die lukrativste Angriffsflache in jedem ernsthaften Bug-Bounty-Programm geworden, und gleichzeitig die meistvernachlassigte von Pentestern, die immer noch XSS im Kontaktformular jagen. Ein IDOR auf /api/v3/users/{id}/invoices zahlt drei bis acht tausend Dollar bei HackerOne, wahrend ein reflektiertes XSS auf einer Marketingseite bei 250 schliesst. Das Basilisk-OffSec-Team hat in dieser Checkliste den exakten Ablauf zusammengestellt, den wir in autorisierten Engagements und offentlichen Programmen wie GitLab, Shopify und Reddit anwenden. Vor allem: Lies den Scope, bestatige die Brand Domain und beruhre niemals Endpoints ausserhalb der Liste. Alles hier setzt eine schriftliche Autorisierung voraus, und alles wird gegen die OWASP API Security Top 10 (2023) gerahmt.

Autorisierung und Scope zuerst, immer

Bevor irgendein Tool startet, existiert nur eine Frage: darf ich das anfassen. Bug Bounty ohne Scope-Bestatigung ist kein Pentest, es ist ein Vorfall. Lies das Policy-Dokument, notiere die In-Scope-Domains, die ausdruecklich ausgeschlossenen Endpoints (oft /admin oder Zahlungsflows) und die verbotenen Techniken (fast immer DoS und Social Engineering). Dokumentiere das Datum, die Programmversion und deinen Testaccount. Diese Disziplin ist nicht Buerokratie, sie ist der Unterschied zwischen einer bezahlten Bounty und einer Anzeige. Legales Bug Bounty ist Disziplin vor Kreativitat.

Angriffsflache kartieren, bevor du ein Payload abfeuerst

Der Ausgangspunkt ist niemals Burp offen im Gesicht. Es ist Surface Mapping. Hol dir die Mobile App mit apktool, extrahiere URL-Strings und lade sie als manuelle Sitemap in Burp. Fahre ffuf mit der Wordlist api-endpoints-res.txt von SecLists gegen Pfade wie /api/, /v1/, /internal/, /graphql, /gql, /query. Wayback Machine uber gau und waybackurls fordert veraltete Endpoints zutage, die niemand gepatcht hat. In einem aktuellen Engagement fanden wir ein /api/v1/admin/export aus dem Jahr 2019, das ein normales User-Token akzeptierte, ahnlich wie in Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen beschrieben. Dokumentiere jeden Endpoint mit Methode, erwartetem Content-Type und benotigter Rolle, bevor du irgendein Payload abfeuerst.

Waehrend der Kartierung lohnt es sich, das Verhalten pro Version und pro Client zu vergleichen. Aeltere API-Versionen (/api/v1 neben /api/v3) tragen oft schwaechere Authorisierung, weil sie fuer Legacy-Clients am Leben gehalten werden; genau dort sitzen die vergessenen Endpoints. Vergleiche auch die Web- gegen die Mobile-Antwort desselben Endpoints: Mobile-Backends geben haeufig mehr Felder zurueck (interne IDs, E-Mail, Rollen), weil der Client sie angeblich filtert. Notiere fuer jeden Endpoint, welche Rolle ihn aufrufen darf, welche Parameter er akzeptiert und ob er einen zweiten Kontext hat (z. B. eine URL, die spaeter serverseitig abgerufen wird) - dieser sekundaere Kontext ist die Wurzel vieler SSRF- und Injection-Ketten. Eine vollstaendige Karte ist wertvoller als jedes einzelne Payload, weil sie dir sagt, wo du ueberhaupt suchen sollst.

IDOR/BOLA: der teuerste Bug in REST

IDOR bleibt der Bug Nummer eins in REST APIs aus einem einfachen Grund: Entwickler vertrauen der ID aus dem JWT, lesen aber die ID aus der URL. Erstelle zwei Konten in der Ziel-App, fang beide Sessions in Burp ab und nutze die Extension Autorize oder Auth Analyzer, um jeden Request von Konto A mit dem Cookie von Konto B erneut zu senden. Achte auf 200-Antworten mit unterschiedlichem Body, nicht nur auf Statuscodes. UUIDs sind kein Schutz: Enumeriere sie uber Suchendpoints, CSV-Exporte oder Benachrichtigungen. Teste auch die Schreibseite: PUT und DELETE mit fremder ID, denn Lese-IDOR ist Info-Disclosure, aber Schreib-IDOR ist Kontouebernahme.

Injection-Logik gilt auch in APIs, wie wir in SQL Injection in der Praxis: Ausnutzen, Erkennen und Mitigieren im Kontrollierten Lab gezeigt haben, besonders bei sort-, order- und search-Filtern, die als SQL-Konkatenation enden. Ein ?sort=name)-- oder ein Boolean-Delay im JSON-Body verrat oft, dass der Parameter ungeschuetzt in die Query wandert. Melde niemals eine SQLi ohne reproduzierbaren, nicht-destruktiven Proof (kein DROP, kein UPDATE), nur Extraktion eines harmlosen Wertes wie der DB-Version.

GraphQL andert die Spielregeln

GraphQL andert die Spielregeln. Beginne mit dem Test der Introspection auf /graphql mit der Query {__schema{types{name fields{name}}}}. Wenn sie in Produktion offen steht, hast du den halben Report schon geschrieben. Tools wie InQL, GraphQL Voyager und clairvoyance rekonstruieren Schemas selbst bei deaktivierter Introspection via Field Stuffing. Suche nach exponierten Mutations wie adminUpdateUser, impersonate, exportAllData. Batch Queries umgehen Rate Limits: schicke 1000 Login-Mutations in einem einzigen HTTP-Request. Alias Overloading bricht naive Validatoren. Anders als in Modernes XSS: DOM, Stored und Reflected mit Beispielen aus dem Testlabor besprochen, ist der Impact hier fast immer logikbasiert, keine Skript-Injection.

Auth-Bypass geht weit uber den none-Algorithmus hinaus

Auth-Bypass geht in diesem Kontext weit uber den klassischen none-Algorithmus im JWT hinaus. Teste jku- und kid-Injection, den Wechsel von RS256 zu HS256 mit dem Public Key als Secret und Refresh Tokens, die nie ablaufen. Header wie X-Original-URL, X-Rewrite-URL, X-Forwarded-For und X-User-Id umgehen Auth-Middleware haufig, wenn die API hinter einem fehlkonfigurierten Gateway liegt. In GraphQL verifiziere, dass die @auth-Directive jedes Feld abdeckt, oder ob ein verschachtelter Resolver Daten ohne Prufung leakt. Pruefe auch die Token-Ablauflogik: ein widerrufenes Token, das nach Logout noch akzeptiert wird, ist ein sauberer, gut bezahlter Report.

SSRF, Mass Assignment und Business Logic

SSRF tritt auch in APIs auf, die URLs als Parameter fur Webhooks oder Avatare akzeptieren, ein Muster, das wir in SSRF Entmystifiziert: Cloud Metadata im Lokalen AWS-Lab Ausnutzen mit Exploits gegen AWS IMDS detailliert haben. Fur Mass Assignment fuge Felder wie isAdmin:true, role:owner, verified:true in jedem PATCH oder PUT hinzu; Frameworks wie Rails und NestJS mit unvollstandigen Whitelists servieren Admin auf dem Silbertablett. Business Logic ist die Klasse, die Scanner nie finden: negative Mengen, Waehrungswechsel zwischen Preisberechnung und Charge, doppelte Coupon-Anwendung. Diese Bugs verlangen, dass du den Geschaeftsablauf verstehst, nicht nur das Protokoll.

Rate Limiting und Race Conditions

Rate Limiting, richtig getestet, ist selten eine eigene Bounty, aber der Multiplikator fur andere Bugs: fehlt es auf dem OTP- oder Login-Endpoint, wird ein 6-stelliger Code in Minuten gebruteforced. Fur Race Conditions auf Coupon- oder Withdrawal-Endpoints nutze Turbo Intruder mit der Single-Packet-Attack von James Kettle und feuere 30 simultane Requests ab; wenn ein 50-Dollar-Coupon fuenfmal einloest, hast du einen finanziellen Impact-Report. Kombiniere Race mit Business Logic: der klassische Doppel-Withdrawal, bei dem der Saldo-Check und der Abzug nicht atomar sind.

Datei-Uploads, Deserialisierung und versteckte Parameter

Zwei Bug-Klassen bleiben in API-Tests oft ungeprueft und zahlen gut. Erstens Datei-Uploads: teste jeden Upload-Endpoint auf Content-Type-Confusion (ein PHP- oder SVG-Payload als image/png deklariert), Path-Traversal im Dateinamen (../../avatar.php), fehlende Groessen- und MIME-Validierung und, bei Bildverarbeitung serverseitig, ImageMagick- oder ffmpeg-Ketten, die in RCE oder SSRF muenden. Zweitens Deserialisierung: APIs, die serialisierte Objekte in Cookies, Headern oder Bodies akzeptieren (Java, .NET, PHP, Python pickle, Ruby Marshal), sind ein direkter Weg zu RCE, wenn eine Gadget-Chain existiert. Suche nach base64-Bloecken, die mit bekannten Magic-Bytes beginnen (rO0 fuer Java, ac ed in Hex). Ergaenze das um Parameter-Mining mit Arjun oder param-miner: viele APIs verarbeiten undokumentierte Felder wie debug=true, preview oder internal, die in der offiziellen Doku nie auftauchen und Autorisierungspruefungen umgehen. Alle drei Klassen brauchen einen sauberen, nicht-destruktiven PoC und gehoeren nur in autorisierte Ziele.

Reporting: warum Impact bezahlt wird, nicht Technik

Dokumentiere den Impact mit der Zahl der exponierten Datensatze, geschatztem finanziellen Wert und einem reproduzierbaren curl-PoC. Programme zahlen fur demonstrierten Impact, nicht fur Technik. Baue ein Report-Template mit CWE-Titel, nummerierten Schritten, rohem Request, gekurzter Response und einer Einzeiler-Fix-Empfehlung. Reiche fruh ein, bevor Duplikate landen, aber niemals ohne den Scope bestatigt zu haben. Ein sauberer, knapper Report mit klarem Impact wird schneller und hoher bezahlt als eine Wall-of-Text mit spekulativen Szenarien.

Praktische Checkliste

(1) Scope und Autorisierung schriftlich bestatigt. (2) Surface komplett kartiert (mobile, Wayback, ffuf). (3) IDOR/BOLA lesend und schreibend mit zwei Konten. (4) GraphQL-Introspection, Batch, Alias, exponierte Mutations. (5) JWT: alg-confusion, kid/jku, Ablauf, Widerruf nach Logout. (6) Mass Assignment auf jedem Schreib-Endpoint. (7) SSRF auf jedem URL-Parameter. (8) Rate Limit auf Auth-Flows und Race auf Geld-Flows. (9) Business Logic gegen den echten Ablauf. (10) Report mit Impact, PoC und Fix.

FAQ: Womit soll ich als Anfaenger anfangen?

Mit IDOR/BOLA. Es ist der haeufigste, am leichtesten zu beweisende und gut bezahlte Bug, und es braucht nur zwei Testkonten und Burp mit Autorize. Baue zuerst im eigenen Lab Intuition auf, wie in unserem DVWA/Juice-Shop-Setup, bevor du ein echtes Programm anfasst. Sobald du IDOR sicher findest, erweitere um GraphQL und JWT-Fehlkonfigurationen, die technisch verwandt sind und in modernen APIs haeufig zusammen auftreten.

FAQ: Wie vermeide ich, aus Versehen den Scope zu verletzen?

Konfiguriere Burp mit einem strikten Target-Scope und aktiviere "Drop out-of-scope requests", damit kein Tool versehentlich fremde Hosts trifft. Verzichte auf automatisierte aktive Scanner, wenn die Policy sie nicht erlaubt, und feuere niemals hochvolumige Angriffe (das kann als DoS gewertet werden). Im Zweifel fragst du das Programm ueber den offiziellen Kanal, bevor du testest. Der teuerste Fehler ist nicht ein verpasster Bug, sondern ein Test ausserhalb der Erlaubnis.

Fazit

Legales Bug Bounty ist Disziplin vor Kreativitat, und auf dieser Disziplin baut Basilisk seine Reputation in Programmen wie Mercado Livre und Nubank auf. Der Ablauf ist reproduzierbar: Scope, Kartierung, systematisches Durchgehen der API-Bug-Klassen, sauberer Impact-Report. Wer diesen Prozess verinnerlicht, findet mehr und bessere Bugs als jemand, der planlos Payloads wirft, und tut es innerhalb der Regeln, was langfristig der einzige Weg ist, der bezahlt. Halte deine Wordlists, deine Burp-Extensions und dein Report-Template gepflegt und versioniert, denn in einem reifen Programm entscheidet die Geschwindigkeit vom ersten Request bis zum sauberen Report darueber, ob du die Bounty bekommst oder ein Duplikat kassierst.