API’s vormen de ruggengraat van moderne applicaties – en het meest aangevallen oppervlak.Meer dan 80% van het webverkeer loopt nu via API's, en de API-aanvallen zijn de afgelopen jaren met 700% toegenomen. API beveiligingstests zijn niet langer optioneel; het is essentieel voor elke organisatie die API's beschikbaar stelt aan partners, mobiele applicaties of internet.
Belangrijkste afhaalrestaurants
- API's hebben unieke kwetsbaarheden:De OWASP API Security Top 10 behandelt bedreigingen die specifiek zijn voor API's en die traditionele webtests over het hoofd zien.
- Broken Object Level Authorization (BOLA) is het grootste API-risico:Aanvallers manipuleren object-ID's in API-verzoeken om toegang te krijgen tot de gegevens van andere gebruikers.
- Authenticatie- en snelheidsbeperkende hiaten zijn alomtegenwoordig:Bij veel API's ontbreekt het aan de juiste tokenvalidatie, snelheidsbeperking en preventie van misbruik.
- Geautomatiseerd + handmatig testen is vereist:Geautomatiseerde scanners vinden veelvoorkomende API-fouten. Handmatig testen brengt kwetsbaarheden in de bedrijfslogica en complexe omzeilingen van autorisaties aan het licht.
OWASP API Beveiliging Top 10 (2023)
| # | Kwetsbaarheid | Beschrijving | Testaanpak |
|---|---|---|---|
| API1 | Autorisatie op objectniveau verbroken | Toegang krijgen tot objecten van andere gebruikers door ID's te wijzigen | Test elk eindpunt met verschillende gebruikerstokens, inventariseer object-ID's |
| API2 | Verbroken authenticatie | Zwakke tokengeneratie, ontbrekende validatie, onveilige stromen | Tokenanalyse, brute kracht, stroommanipulatie |
| API3 | Autorisatie op eigendomsniveau van gebroken object | Massale toewijzing, overmatige gegevensblootstelling in reacties | Voeg onverwachte velden toe aan verzoeken, analyseer antwoordgegevens |
| API4 | Onbeperkt hulpbronnenverbruik | Ontbrekende snelheidslimiet, paginering of groottelimiet | Overstromingstests, testen van grote ladingen, paginering-bypass |
| API5 | Autorisatie op functieniveau | Toegang tot beheerderseindpunten als gewone gebruiker | Test beheerderseindpunten met niet-beheerderstokens |
| API6 | Onbeperkte toegang tot gevoelige bedrijfsstromen | Geautomatiseerd misbruik van bedrijfsfunctionaliteit | Botsimulatie, geautomatiseerde flowtests |
| API7 | Vervalsing aan serverzijde (SSRF) | API haalt door de aanvaller beheerde URL's op | Manipulatie van URL-parameters, onderzoek naar intern netwerk |
| API8 | Verkeerde configuratie van beveiliging | Uitgebreide fouten, CORS-misconfiguratie, onnodige methoden | Configuratiescannen, headeranalyse |
| API9 | Onjuist voorraadbeheer | Verouderde, niet-gedocumenteerde of schaduw-API-eindpunten | API ontdekking, documentatievergelijking |
| API10 | Onveilig gebruik van API's | API-antwoorden van derden vertrouwen zonder validatie | Reactiemanipulatie, upstream API spoofing |
API Methodologie voor beveiligingstests
Ontdekking en documentatiebeoordeling
Begin met het in kaart brengen van alle API eindpunten. Vergelijk API-documentatie (OpenAPI/Swagger-specificaties) met daadwerkelijk gedrag. Gebruik tools zoals Burp Suite, Postman en aangepaste scripts om ongedocumenteerde eindpunten te ontdekken. Schaduw-API’s – eindpunten die bestaan maar niet zijn gedocumenteerd – zijn gebruikelijk en missen vaak beveiligingscontroles omdat ze werden vergeten.
Authenticatietest
Test API authenticatiemechanismen: JWT-tokenvalidatie (kunnen tokens worden gemanipuleerd, vervalst of opnieuw worden afgespeeld?), OAuth-stromen (wordt statusparameter afgedwongen? Kunnen omleidings-URI's worden gemanipuleerd?), API sleutelbeheer (zijn sleutels op de juiste manier gedefinieerd? Kunnen ze worden geëxtraheerd uit code aan de clientzijde?) en sessiebeheer (verlopen tokens? Kunnen ze worden ingetrokken?).
Autorisatie testen
Test elk eindpunt met verschillende bevoegdheidsniveaus. Vervang gebruikers-ID's, tenant-ID's en object-ID's in aanvragen om toegangscontroles te verifiëren. Test horizontale autorisatie (gebruiker A heeft toegang tot de gegevens van gebruiker B) en verticale autorisatie (gewone gebruiker heeft toegang tot beheerderseindpunten). Gebruik automatisering om alle eindpunten systematisch te testen; alleen bij handmatig testen worden eindpunten in grote API's gemist.
Invoervalidatie en injectietesten
Test alle invoerparameters op injectiekwetsbaarheden: SQL injectie in queryparameters, NoSQL injectie in JSON hoofdteksten, opdrachtinjectie in verwerkingseindpunten en GraphQL-specifieke injectie (geneste query's, misbruik van introspectie). Test met zowel verkeerd ingedeelde inputs (fuzzing) als zorgvuldig vervaardigde payloads die gericht zijn op specifieke injectietypen.
API Hulpmiddelen voor beveiligingstests
- Burp-suite:Uitgebreide API-beveiligingstests met proxy-, scanner- en automatiseringsmogelijkheden.
- Postbode:API ontwikkelingsplatform met collecties voor beveiligingstests en geautomatiseerde testscripts.
- OWASP-ZAP:Gratis API beveiligingsscanner met OpenAPI-import en geautomatiseerd scannen.
- Kernen:Op sjablonen gebaseerde scanner met API-specifieke sjablonen voor veelvoorkomende kwetsbaarheden.
- Arjun:Hulpprogramma voor het ontdekken van HTTP-parameters voor het vinden van verborgen API-parameters.
- GraphQL Reiziger:GraphQL API hulpmiddel voor visualisatie en introspectie.
Hoe Opsio de beveiliging van API test
- OWASP API Top 10 dekking:Elke API-test omvat alle 10 categorieën met platformspecifieke testtechnieken.
- Geautomatiseerde + handmatige aanpak:Geautomatiseerd scannen op bekende kwetsbaarheden, handmatig testen van bedrijfslogica en complexe autorisatiefouten.
- GraphQL expertise:Gespecialiseerde tests voor GraphQL API's, waaronder introspectie, geneste query-aanvallen en misbruik van batchquery's.
- CI/CD integratie:Wij helpen bij het integreren van geautomatiseerde API-beveiligingstests in uw implementatiepijplijn voor continue zekerheid.
Veelgestelde vragen
Waarin verschilt het testen van API-beveiliging van het testen van webapplicaties?
Het testen van webapplicaties richt zich op de gebruikersinterface en browsergebaseerde interacties. API-testen richten zich rechtstreeks op de API-laag: het testen van eindpunten, parameters, authenticatietokens en gegevensserialisatie die de gebruikersinterface mogelijk niet blootlegt. Veel kwetsbaarheden bestaan alleen in de API-laag en kunnen niet worden ontdekt door alleen UI-testen.
Moet ik interne API's testen of alleen openbare API's?
Beide. Openbare API's zijn direct blootgesteld aan aanvallers en moeten eerst worden getest. Interne API's zijn vaak minder beveiligd omdat ontwikkelaars uitgaan van bescherming op netwerkniveau. Als een aanvaller interne toegang verkrijgt (via phishing, VPN-compromis of verkeerde configuratie van de cloud), worden interne API's het aanvalsoppervlak voor zijdelingse verplaatsing en gegevensdiefstal.
Hoe beveilig ik GraphQL API's specifiek?
GraphQL introduceert unieke risico's: onbeperkte diepgang van zoekopdrachten (denial of service), openbaarmaking van introspectie (lekken van schema's) en misbruik van batchquery's (het omzeilen van snelheidslimieten). Beveilig GraphQL door introspectie in de productie uit te schakelen, limieten voor de diepte en complexiteit van zoekopdrachten te implementeren, autorisatie per veld af te dwingen en de snelheid te beperken op basis van de kosten van zoekopdrachten in plaats van het aantal verzoeken.