API Security Testing: Waarom uw API's uw zwakste schakel zijn

TL;DR

API's drijven moderne applicaties aan. Ze vertegenwoordigen ook het snelst groeiende en meest onvoldoende geteste aanvalsoppervlak in de meeste organisaties. Terwijl webapplicatie beveiliging is gerijpt, is API-beveiliging achtergebleven: zwakkere authenticatie handhaving, inconsistente toegangscontroles, buitensporige datablootstelling en hele endpoints die beveiligingsteams niet weten dat ze bestaan. Deze gids legt uit wat API-beveiligingstesten dekt, hoe de meest voorkomende API-kwetsbaarheden er in de praktijk uitzien en waarom een webapplicatie test geen vervanging is voor toegewijd API-testen.

Waarom API's onevenredig kwetsbaar zijn

Verschillende structurele factoren maken API's consistent kwetsbaarder dan de webinterfaces die ze ondersteunen.

API's stellen ruwe data en functionaliteit direct bloot. Een webinterface filtert en formatteert wat het toont. Een API retourneert data-objecten direct. Als de toegangscontrole op een API-endpoint ontbreekt of onvolledig is, krijgt een aanvaller de ruwe data, niet een gefilterd beeld.

API's worden sneller gebouwd dan hun beveiliging wordt beoordeeld. Ontwikkelteams voegen snel endpoints toe. Beveiligingsbeoordeling houdt niet altijd gelijke tred. Authenticatie kan correct zijn geïmplementeerd op de primaire gebruikersgerichte endpoints maar ontbreken op een later toegevoegd batch-export endpoint.

Shadow API's zijn gebruikelijk. Ongedocumenteerde endpoints van legacy-versies, ontwikkelingssnelkoppelingen, verouderde integraties en verbindingen van derden bestaan in de meeste grote applicaties. Beveiligingsteams weten niet dat ze bestaan. Ze worden niet gemonitord. Ze hebben vaak zwakkere controles dan gedocumenteerde endpoints.

API-authenticatietokens zijn langlevend en van hoge waarde. API-sleutels, OAuth-tokens en JWT-tokens die worden gecompromitteerd verlenen persistente toegang. In tegenstelling tot sessiecookies die verlopen na een browsersessie, zijn API-tokens vaak langlevend en gedeeld door meerdere consumenten.

De OWASP API Security Top 10

De meest voorkomende en meest schadelijke API-kwetsbaarheden zijn goed gedocumenteerd. API-beveiligingstesten gebruikt de OWASP API Security Top 10 als basis testkader.

Broken object level authorization (BOLA)

BOLA is de meest uitgebuite API-kwetsbaarheid. Het treedt op wanneer een API-endpoint een objectreferentie van de client accepteert, zoals een gebruikers-ID, order-ID of document referentie, zonder te verifiëren of de verzoekende gebruiker bevoegd is om dat specifieke object te openen. Een aanvaller die het ID in een verzoek wijzigt om toegang te krijgen tot de gegevens van een andere gebruiker, maakt gebruik van BOLA. De oplossing vereist server-side verificatie van objecteigendom voor elk verzoek, niet alleen authenticatie.

Broken authentication

API-authenticatie zwakheden omvatten ontbrekende authenticatie op specifieke endpoints, zwakke tokenvalidatie, JWT-algoritme-verwarring aanvallen, API-sleutels in URL's die verschijnen in serverlogboeken en ontbrekende authenticatie op secundaire endpoints waarvan ontwikkelaars aannames dat ze niet openbaar toegankelijk waren.

Broken function level authorization

Functieniveau authorisatie controles bepalen of een gebruiker een specifiek API-endpoint kan aanroepen. Kwetsbaarheden treden op wanneer reguliere gebruikers administratieve endpoints kunnen bereiken, wanneer verschillende gebruikersrollen elkaars functies kunnen bereiken door de API direct aan te roepen en wanneer de gebruikersinterface een actie beperkt maar het onderliggende API-endpoint dezelfde beperking niet afdwingt.

Buitensporige datablootstelling

Veel API's retourneren volledige data-objecten in reacties en vertrouwen op de client om te filteren wat aan de gebruiker wordt getoond. Dit betekent dat gevoelige velden, interne identifiers en gegevens die de gebruiker niet zou mogen zien aanwezig zijn in API-reacties maar eenvoudigweg niet worden weergegeven in de interface. Een aanvaller die API-reacties direct kan lezen, kan toegang krijgen tot deze gegevens.

Onbeperkt resourceverbruik

Ontbrekende of ineffectieve rate limiting stelt aanvallers in staat onbeperkte API-aanroepen te doen, waardoor credential stuffing, opsomming van gebruikersgegevens, resource-uitputting en de extractie van grote datasets via herhaalde aanroepen mogelijk worden. Rate limiting moet worden afgedwongen op API-niveau, niet alleen in de gebruikersinterface.

Wat API-beveiligingstesten in de praktijk dekt

API-ontdekking en inventaris. Voor het testen begint, brengt de tester het volledige API-oppervlak in kaart, inclusief endpoints ontdekt via de verstrekte specificatie, via actieve verkenning en via passieve observatie van applicatieverkeer. Shadow endpoints die tijdens deze fase worden ontdekt, zijn vaak de meest significante bevindingen.

Authenticatie- en tokentesten. Testing dekt hoe authenticatietokens worden gegenereerd, verzonden, gevalideerd en ingetrokken. Dit omvat JWT-validatie, API-sleutelentropie en -blootstelling, OAuth-flowbeveiliging en of authenticatie consistent wordt afgedwongen op alle ontdekte endpoints.

Autorisatietesten per rol. Testing gebruikt meerdere testaccounts op verschillende privileges om te verifiëren dat object-level en function-level autorisatie correct wordt afgedwongen voor elk endpoint. Elk endpoint wordt getest op horizontale en verticale privilege-escalatie.

Invoervalidatie en injectie. API-endpoints die door de gebruiker gecontroleerde invoer verwerken, worden getest op injectiekwetsbaarheden inclusief SQL-injectie, NoSQL-injectie, opdrachtinjectie en mass assignment kwetsbaarheden waarbij de API objectvelden accepteert die niet door de gebruiker gecontroleerd zouden moeten worden.

Rate limiting en bedrijfslogica. Testing verifiëert dat rate limiting wordt afgedwongen op alle gevoelige endpoints, dat bedrijfslogicabepalingen worden afgedwongen op de API-laag en niet alleen in de client en dat gevoelige bewerkingen niet kunnen worden herhaald zonder passende controles.

FAQ

Wat is API-beveiligingstesten?

API-beveiligingstesten is een gestructureerde beoordeling van de beveiliging van applicatie programmeer interfaces, met dekking van authenticatie, autorisatie, invoervalidatie, rate limiting, data blootstelling en handhaving van bedrijfslogica. Het gebruikt zowel geautomatiseerde tools als handmatig testen om kwetsbaarheden te identificeren waarmee aanvallers toegang kunnen krijgen tot gegevens die ze niet zouden mogen zien, acties kunnen uitvoeren die ze niet zouden mogen uitvoeren, of de API kunnen misbruiken op manieren die de ontwikkelaar niet bedoeld heeft.

Wat is broken object level authorization in API's?

Broken object level authorization, vermeld als de topkwetsbaarheid in de OWASP API Security Top 10, treedt op wanneer een API-endpoint object referenties van de client accepteert zonder te verifiëren of de verzoekende gebruiker bevoegd is om dat specifieke object te openen. Een aanvaller die een order-ID, gebruikers-ID of document referentie in een API-verzoek kan wijzigen om toegang te krijgen tot de gegevens van een andere gebruiker, maakt gebruik van broken object level authorization. Dit is de meest uitgebuite API-kwetsbaarheid bij echte aanvallen.

Hoe verschilt API-beveiligingstesten van webapplicatietesten?

Webapplicatietesten richt zich doorgaans op de gebruikersgerichte interface en wat een browser gebaseerde aanvaller kan doen. API-testen richt zich op de onderliggende data- en servicelaag, vaak toegankelijk zonder enige gebruikersinterface. API's stellen vaak meer functionaliteit bloot dan de webinterface gebruikt, hebben zwakkere authenticatie handhaving op specifieke endpoints en stellen gevoelige gegevens rechtstreeks in reacties bloot zonder de presentatielaag filtering die een webinterface toepast. API-testen vereist begrip van het API-contract, niet alleen wat een browser toont.

Wat is de OWASP API Security Top 10?

De OWASP API Security Top 10 is een referentielijst van de meest kritieke API-beveiligingsrisico's. Het dekt broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server-side request forgery, beveiligingsmisconfiguratie, improper inventory management en unsafe consumption of APIs. API-penetratietesten gebruikt deze lijst als basis maar gaat er ver bovenuit.

Waarom zijn ongedocumenteerde of shadow API's een beveiligingsrisico?

Shadow API's zijn endpoints die bestaan in productie maar niet vermeld staan in officiële API-documentatie of inventarissen. Ze ontstaan door legacy-integraties, ontwikkelingssnelkoppelingen, verouderde versies die blijven draaien en integraties van derden. Omdat ze ongedocumenteerd zijn, worden ze niet gedekt door beveiligingstesten, worden ze niet gemonitord en hebben ze vaak zwakkere authenticatie en toegangscontroles dan gedocumenteerde endpoints. Ze vertegenwoordigen een significant risico omdat aanvallers ze kunnen ontdekken via verkenning.

Wat moet worden opgenomen in de scope van een API-beveiligingsbeoordeling?

Een API-beveiligingsbeoordeling scope moet alle API-endpoints omvatten inclusief ongedocumenteerde en legacy versies, alle authenticatiemechanismen inclusief API-sleutels, OAuth en JWT-tokens, alle gebruikersrollen en hun verwachte toegangsniveaus, batch- of export endpoints, administratieve endpoints, rate limiting en throttling-controles en de datamodellen die door de API worden blootgesteld. De scope moet worden gedefinieerd vanuit een API-specificatie document indien beschikbaar, aangevuld door ontdekking tijdens de test.

Gerelateerde diensten en bronnen

Sectricity biedt toegewijd API-beveiligingstesten voor REST, GraphQL en SOAP API's over alle gebruikersrollen en privileges. We bieden ook web applicatie penetratietesten en on-demand testen via ons RedSOC PTaaS-platform. Voor een diepere blik op webapplicatiebeveiliging, zie onze gids over web applicatie penetratietesten. Start met een gratis security scan.