AI API reverse engineering
Expert10 min lezenBijgewerkt op 2026-03-15
Technieken om AI-API's te reverse-engineeren, waaronder het in kaart brengen van ongedocumenteerde endpoints, parameter discovery, profileren van rate limits en het extraheren van implementatiedetails uit API-gedrag.
AI API reverse engineering is het proces waarbij je de volledige capaciteiten, beperkingen en implementatiedetails van een AI-dienst systematisch ontdekt door het externe gedrag ervan te analyseren. Anders dan traditionele API-verkenning bieden AI-API's unieke uitdagingen en kansen: modelgedrag lekt implementatiedetails, foutmeldingen kunnen architectuur prijsgeven en rate limiting-patronen onthullen infrastructuurkeuzes.
Endpoint discovery
Systematisch endpoints in kaart brengen
AI-applicaties stellen doorgaans meerdere endpoints beschikbaar naast de primaire chat- of completion-API. Het ontdekken hiervan onthult het volledige aanvalsoppervlak:
| Endpoint-categorie | Veelvoorkomende patronen | Wat ze onthullen |
|---|---|---|
| Inference-endpoints | /v1/chat/completions, /v1/completions, /predict, /generate | Primaire AI-functionaliteit, modelversies |
| Embedding-endpoints | /v1/embeddings, /embed, /encode | Details van embedding-modellen, dimensiegroottes |
| Fine-tuning-endpoints | /v1/fine-tuning/jobs, /train, /finetune | Fine-tuning-capaciteiten, omgang met trainingsdata |
| Modelbeheer | /v1/models, /models/list, /deployments | Beschikbare modellen, versiebeheer, deployment-info |
| Bestands-/databeheer | /v1/files, /upload, /datasets | Datafunctionaliteit, opslagdetails |
| Admin/intern | /admin, /internal, /debug, /health, /metrics | Infrastructuurdetails, debug-informatie |
| Batchverwerking | /v1/batch, /bulk, /async | Batch-capaciteiten, queue-architectuur |
Discovery-technieken
Documentatieanalyse
Begin met openbare documentatie, OpenAPI/Swagger-specs, SDK-broncode en changelog-geschiedenis. Zelfs goed gedocumenteerde API's hebben vaak ongedocumenteerde features.
Bronnen om te onderzoeken:
- Officiële API-documentatie en changelogs
- SDK-broncode (Python, JavaScript, enz.) -- onthult vaak endpoints die niet in de publieke documentatie staan
- OpenAPI/Swagger-specificatiebestanden
- Posts op developerforums en community-discussies
- Gearchiveerde versies van documentatie (Wayback Machine)
Path-enumeratie
Tast systematisch veelvoorkomende API-padpatronen af met wordlists die zijn afgestemd op AI-diensten.
AI-specifieke padpatronen om te testen:
/v1/, /v2/, /api/, /ml/, /ai/ /completions, /chat, /generate, /predict, /classify /embeddings, /encode, /vectors /models, /deployments, /engines /fine-tune, /train, /finetune, /jobs /files, /upload, /documents, /datasets /admin, /internal, /debug, /metrics, /health /moderate, /filter, /safety, /content-filter /tokenize, /count-tokens, /usageVersie-enumeratie
Test op meerdere API-versies die mogelijk verschillende capaciteiten blootleggen of andere security-controles hebben.
Versiepatronen:
/v1/..., /v2/..., /v3/... /api/v1/..., /api/v2/... /2023-01-01/..., /2024-01-01/... (datum-versionering) /?api-version=2024-01-01 (versionering via query-parameter)Method-enumeratie
Test voor ontdekte endpoints alle HTTP-methoden (GET, POST, PUT, PATCH, DELETE, OPTIONS) om extra functionaliteit te vinden.
Parameter discovery
Verborgen parameters detecteren
AI-API's accepteren vaak parameters die niet in de openbare documentatie vermeld staan. Deze ontdekken kan verborgen capaciteiten, debug-features of security-relevante configuratieopties onthullen.
| Discovery-methode | Techniek | Wat het vindt |
|---|---|---|
| Analyse van foutmeldingen | Stuur ongeldige requests en analyseer de foutmeldingen | Parameternamen, geldige waarden, typebeperkingen |
| SDK-broncodeanalyse | Lees de broncode van clientbibliotheken | Alle parameters die de SDK ondersteunt, ook ongedocumenteerde |
| Header-analyse | Bestudeer response-headers voor configuratiehints | Modelversie, serveridentiteit, feature flags |
| Fuzzing | Stuur requests met veelvoorkomende parameternamen | Verborgen parameters die het gedrag aanpassen |
| Differentiële analyse | Vergelijk gedrag met/zonder specifieke parameters | Parameters die de output wijzigen maar niet gedocumenteerd zijn |
Veelvoorkomende verborgen parameters in AI-API's
| Parameter | Doel | Security-relevantie |
|---|---|---|
raw_response / include_raw | Ongefilterde modeloutput teruggeven | Kan content filtering omzeilen |
debug / verbose | Debug-informatie teruggeven | Kan interne architectuur blootgeven |
model_version / engine | Specifieke modelversie selecteren | Kan toegang geven tot oudere, minder beveiligde versies |
system_prompt / instructions | System-level-instructies overschrijven | Directe prompt injection-vector |
max_retries / retry_strategy | Retry-gedrag aansturen | Risico op resource-uitputting |
cache / use_cache | Response-caching aansturen | Kan gecachete responses van andere gebruikers teruggeven |
internal / admin | Beheerfuncties inschakelen | Privilege-escalatie |
filter_level / safety_level | Strengheid van content filtering aansturen | Kan veiligheidscontroles verzwakken |
logprobs / log_probabilities | Token-level kansen teruggeven | Informatie lekken over interne werking van het model |
echo / echo_prompt | De prompt in de response echoën | Kan verwerkte/aangepaste prompts onthullen |
Methodologie voor parameter-fuzzing
Voor elk ontdekt endpoint:
1. Stuur een baseline-request met gedocumenteerde parameters
2. Voeg telkens één kandidaatparameter toe
3. Vergelijk de response met de baseline:
- Andere statuscode → parameter herkend
- Andere response body → parameter beïnvloedt gedrag
- Andere responstijd → parameter triggert verwerking
- Specifieke foutmelding → parameter bestaat maar waarde klopt niet
4. Voor herkende parameters: enumereer geldige waarden:
- Boolean: true/false
- Numeriek: grenswaarden (0, 1, -1, MAX_INT)
- String: veelvoorkomende waarden, lege string, speciale tekens
- Enum: afleiden uit foutmeldingen
Rate limits profileren
Waarom rate limits belangrijk zijn voor redteaming
Rate limits onthullen infrastructuurarchitectuur en bepalen wat haalbaar is bij aanvallen:
| Informatie over rate limits | Wat het onthult | Implicatie voor red team |
|---|---|---|
| Requests per minuut | API-capaciteitsplanning, tier-configuratie | Beperkt snelheid van brute-force en enumeratie |
| Tokens per minuut | Capaciteit van model-serving | Beperkt volume van output-extractie |
| Limiet op gelijktijdige requests | Parallelisme van infrastructuur | Beperkt multi-threaded aanvallen |
| Per-key versus per-IP-limiet | Authenticatiearchitectuur | Roteren van keys kan limieten omzeilen |
| Reset-mechanisme | Tijdgebaseerd versus sliding window | Timing-gebaseerde ontwijkingsstrategieën |
| Burst-tolerantie | Kortetermijncapaciteit | Maakt snelle initiële enumeratie mogelijk |
Technieken voor rate limit discovery
| Techniek | Hoe uit te voeren | Waar op te letten |
|---|---|---|
| Header-analyse | Bestudeer X-RateLimit-*- en Retry-After-headers | Limietwaarden, resterend quotum, reset-timing |
| Incrementeel opvoeren | Verhoog het requesttempo geleidelijk tot het wordt gelimiteerd | Exacte drempel, throttling-gedrag |
| Burst-testen | Stuur snel achter elkaar gelijktijdige requests | Burst-tolerantie, queuing-gedrag |
| Multi-key-testen | Gebruik verschillende API-keys vanaf hetzelfde IP | Per-key versus per-account versus per-IP-limiet |
| Multi-IP-testen | Gebruik verschillende IP's met dezelfde API-key | IP-gebaseerde versus key-gebaseerde handhaving |
| Endpoint-vergelijking | Vergelijk rate limits over verschillende endpoints | Inconsistente handhaving, zwakkere endpoints |
| Tijdanalyse | Volg rate limit-resets in de tijd | Vast window versus sliding window, reset-timing |
Technieken om rate limits te omzeilen
| Techniek | Methode | Toepasbaarheid |
|---|---|---|
| Key-rotatie | Gebruik meerdere API-keys om requests te verdelen | Wanneer rate limiting per key plaatsvindt |
| IP-rotatie | Verdeel requests over meerdere bron-IP's | Wanneer rate limiting een IP-component bevat |
| Endpoint-substitutie | Gebruik alternatieve endpoints voor dezelfde functionaliteit | Wanneer verschillende endpoints andere limieten hebben |
| Batch-optimalisatie | Maximaliseer informatie per request om het aantal requests te verlagen | Wanneer rate limiting request-gebaseerd is |
| Timing-optimalisatie | Time requests om de doorvoer binnen limieten te maximaliseren | Wanneer rate limiting vaste windows gebruikt |
| Versie-targeting | Gebruik oudere API-versies met andere rate limits | Wanneer rate limits per API-versie verschillen |
Implementatiedetails extraheren
Analyse van foutmeldingen
Foutmeldingen van AI-API's lekken vaak implementatiedetails:
| Foutpatroon | Gelekte informatie | Voorbeeld |
|---|---|---|
| "Model not found"-fouten | Beschikbare modelnamen en -versies | "model 'gpt-4-turbo-preview' not found. Available: gpt-4o, gpt-4o-mini" |
| Validatiefouten | Parameterbeperkingen en -types | "temperature must be between 0 and 2" |
| Rate limit-fouten | Limietwaarden en resettijden | "Rate limit exceeded: 60 RPM. Reset in 42s" |
| Internal server errors | Backend-technologiestack | Stack traces die Python/Java-versies of frameworknamen onthullen |
| Tokenlimietfouten | Groottes van het contextvenster | "Maximum context length is 128000 tokens" |
| Content filter-fouten | Filtercategorieën en drempels | "Content filtered: category=violence, severity=high" |
Timing-analyse
De timing van responses onthult kenmerken van model en infrastructuur:
| Timing-patroon | Wat het aanduidt | Meetmethode |
|---|---|---|
| Consistent lage latency | Gecachete responses of eenvoudige modellen | Herhaal identieke requests, meet de variantie |
| Latency evenredig aan outputlengte | Autoregressieve generatie (token voor token) | Varieer max_tokens, correleer met responstijd |
| Bimodale latency-verdeling | Load balancing over verschillende hardware | Grote steekproef requests, plot de verdeling |
| Plotselinge latency-spikes | Queue-saturatie of cold starts | Aanhoudende belastingtests |
| Consistente latency tot eerste token | Prefill-tijd onthult modelgrootte | Meet tijd tot eerste token bij wisselende inputlengtes |
Inlichtingen uit response-headers
| Header | Onthulde informatie |
|---|---|
Server | Webservertechnologie |
X-Request-ID | Request-routing en infrastructuurtopologie |
X-Model-Version | Specifieke modelversie die requests bedient |
X-Processing-Time | Backend-verwerkingstijd |
X-Region | Geografische regio van de bedienende infrastructuur |
CF-Ray / X-Amz-* / X-Goog-* | Identificatie van cloudprovider |
X-Content-Filter-* | Details van content filtering |
API-kaarten opbouwen
Documentatie van de API-kaart
Verzamel alle ontdekte informatie in een gestructureerde API-kaart:
| Sectie | Inhoud |
|---|---|
| Endpoint-inventaris | Alle ontdekte endpoints met methoden, parameters en authenticatievereisten |
| Authenticatieschema | Formaat van API-keys, OAuth-flows, sessiebeheer, tokentypes |
| Rate limit-profiel | Limieten per endpoint, per key, per IP; reset-mechanismen; burst-toleranties |
| Modelinventaris | Beschikbare modellen met versies, contextvensters en capaciteiten |
| Parametercatalogus | Alle parameters (gedocumenteerd en ongedocumenteerd) met types en geldige waarden |
| Fouttaxonomie | Foutcodes, meldingen en wat ze onthullen |
| Infrastructuurvingerafdruk | Cloudprovider, CDN, load balancing, geografische verdeling |
| Security-controles | Content filtering, input-validatie, output-sanitisatie |
| Timing-profielen | Latencykenmerken per endpoint en configuratie |
Van verkenning naar exploitatie
Elk stuk API-inlichting wijst op mogelijke exploitatiepaden:
| Ontdekking | Exploitatiemogelijkheid |
|---|---|
| Ongedocumenteerd admin-endpoint | Privilege-escalatie, wijziging van configuratie |
Verborgen debug-parameter | Openbaarmaking van informatie, omzeilen van filter |
| Inconsistente rate limits | Resource-uitputting op zwak gelimiteerde endpoints |
| Oudere API-versie beschikbaar | Aanvallen op verouderde security-controles |
| Categorieën van content filter in foutmeldingen | Gerichte filter-evasie op basis van categoriegrenzen |
| Modelversie in headers | Bekende kwetsbaarheden in specifieke modelversies aanvallen |
| Gedrag van gecachete responses | Datalek tussen gebruikers via cache poisoning |
Defensief bewustzijn
Begrip van deze technieken vertaalt zich ook in defensieve aanbevelingen:
| Verkenningstechniek | Defensieve tegenmaatregel |
|---|---|
| Path-enumeratie | Geef consistent 404 terug voor alle niet-bestaande paden (geen gedragsverschil) |
| Parameter-fuzzing | Negeer onbekende parameters stilzwijgend (geen foutmeldingen) |
| Analyse van foutmeldingen | Standaardiseer foutmeldingen en strip implementatiedetails |
| Timing-analyse | Voeg willekeurige jitter toe aan responstijden |
| Header-analyse | Minimaliseer informatie in response-headers |
| Versie-enumeratie | Stoot oude API-versies snel af en verwijder ze |
| Rate limit-profiling | Hanteer consistente rate limiting over alle endpoints |
Redteamers moeten zowel de offensieve bevindingen als deze defensieve aanbevelingen in hun rapportages opnemen, zodat organisaties hun API-oppervlakken kunnen verharden tegen toekomstige verkenning.