APIs, of application programming interfaces, spelen een belangrijke rol in de hedendaagse softwareontwikkeling. Zij laten applicaties en services met elkaar communiceren, en laten verschillende softwarecomponenten samenwerken. Met behulp van APIs kan een enkele backend-service een groot aantal verschillende klanten bedienen, waaronder websites, mobiele applicaties en zelfs andere servers. Volgens een onlangs verschenen Cloudfare studie, zijn APIs zo populair geworden dat zij het merendeel van al het internetverkeer genereren.
Maar APIs zijn, net als iedere andere softwarecomponent, kwetsbaar en vormen een risico voor de beveiliging. Denk aan de cyberaanval op de Amerikaanse tak van T-Mobile getroffen eind 2022, een cybercrimineel was erin geslaagd in de systemen in te breken via een API. Resultaat de persoonlijke gegevens van 37 miljoen klanten zijn gestolen.Maar zij zijn zeker niet de enige geweest. In een recent rapport staat dat 41% van de ondervraagde organisaties in 2022 met een API-beveiligingsincident te maken heeft gehad. Bij 63% van hen ging het om een datalek of het verlies van data. Hackers kunnen zwakke plekken in APIs misbruiken om toegang te krijgen tot gevoelige gegevens, services te verstoren of zelfs de controle over hele systemen over te nemen. Daarom is het absoluut noodzakelijk om APIs tegen deze dreigingen te beschermen.
De meeste organisaties hebben een strategie voor applicatiebeveiliging nodig, maar dat is vaak makkelijker gezegd dan gedaan. Het kan moeilijk zijn om mensen te vinden die de juiste security-opleiding hebben en daarom zien we veel training on-the-job. Door developers te laten zien hoe producten beveiligd zijn, help je ze, ongeacht hun kennis van security. Wanneer er een zwakke plek wordt gevonden, is het goed te focussen op leren in plaats van iemand de schuld te geven. En waarom projecteer je de laatste resultaten van een security scan niet op een scherm in de koffiecorner of de pauzeruimte?
In deze blogpost beschrijf ik vier stappen die je helpen om je API-beveiliging naar een hoger niveau te tillen.
Stap 1 – Inventariseer
Laten we bij het begin beginnen: inventariseer welke APIs in jouw organisatie aanwezig zijn. Wanneer je met APIs werkt, is dit nog belangrijker dan bij andere assets omdat APIs vaak verborgen zijn. En zoals altijd het geval is: je kan alleen de zaken beveiligen waarvan je weet dat je ze hebt. Het is niet altijd duidelijk welke APIs betrokken zijn bij het leveren van een bepaalde functionaliteit aan een eindgebruiker! We hebben weleens gezien dat iemand vergeten was de apparatuur te verwijderen die was gebruikt voor de ontwikkeling van de software. Inventariseren zou een belangrijk onderdeel van ieder business-proces moeten zijn en tools zoals geautomatiseerde API discovery kunnen daarbij zeker helpen.
Stap 2 – Ken de OWASP Foundation en de ASVS
Een prima bron voor alles wat met applicatiebeveiliging te maken heeft, is de OWASP Foundation. Deze stichting onderhoudt onder andere het Top 10 bewustzijnsdocument voor webapps. Dit document is noodzakelijk leesvoer voor alle web-ontwikkelaars, maar er is ook een minder bekende versie voor API-beveiliging. Het is belangrijk om deze lijsten met veel voorkomende beveiligingsrisico’s te kennen omdat zij de veel voorkomende fouten die steeds weer in de hele branche voorkomen, beschrijven. Het komt er in de basis op neer dat beveiliging behoorlijk saai is. Voorkomen, signaleren en stoppen van aanvallen heeft meer te maken met een goede beveiligingshygiëne (de saaie dingen) dan met de nieuwste, hippe gaten in de beveiliging die de krant halen. (Tip: lees Developers guide to API security.) De Top 10-lijsten zijn nuttige leermiddelen, maar zijn niet bruikbaar voor development teams. Daarvoor moet je naar een ander OWASP-project kijken: de Application Security Verification Standard (ASVS). Dit project geeft ontwikkelaars verschillende pass/fail criteria waarmee ze hun APIs kunnen vergelijken. De ASVS kan zich ook aan verschillende behoeften aanpassen, afhankelijk van het gewenste beveiligingsniveau van de applicatie:
- Niveau 1 is voor lage betrouwbaarheidsniveaus en beschermt tegen de meest elementaire aanvallen
- Niveau 2 is het meest gebruikelijke niveau en vereist effectieve beveiligingscontroles
- Niveau 3 is bestemd voor de meest bedrijfskritische applicaties en vereist meer diepgaande testen dan de andere twee niveaus.
Stap 3 – Vaste waarde: pentesting
De ASVS leidt ons rechtstreeks naar het volgende essentiële element van API-beveiliging: penetratietesten. Het inschakelen van een expert maakt het mogelijk grondig te werk te gaan en problemen die anders moeilijk te vinden zouden zijn, aan het licht te brengen. Volgens de ASVS worden geautomatiseerde tools sterk aangemoedigd, maar niet genoeg. De verschillende niveaus stellen verschillende eisen aan de testfase. In theorie kan een ASVS Level 1-applicatie op een black box manier worden getest, terwijl voor de andere niveaus meer informatie nodig is, zoals documentatie, broncode, configuratie etc. Toch wordt altijd aanbevolen om testen uit te voeren met zoveel middelen als maar mogelijk is. Ook hangt de waarde van een pentest af van hoe goed de test wordt beheerd. Krijgen testers de juiste scope? Hebben ze genoeg tijd om hun testen af te ronden? Hoe zit het met documentatie?
Stap 4 – Tooling voor het scannen van security (SAST en DAST)
Mijn laatste tip is: gebruik tooling voor beveiligingsscans. Een API wordt gedefinieerd via een zogenaamd schema. Dit is een tekstbestand dat met een machine te lezen is en dat alle endpoints of toegangsapparatuur beschrijft. Maar ook welke methoden ze ondersteunen, welke gegevens ze verwachten en hoe gegevens worden teruggestuurd. Dit schema wordt gedefinieerd voordat de toepassing wordt ontwikkeld of wordt achteraf gegenereerd. Hoe dan ook, als je het schema bestudeert, leer je misschien dingen over je toepassing die je niet wist. Misschien zijn er enkele eindpunten die je tijdens de inventarisatie hebt gemist, of merk je dat een statuscode op de verkeerde waarde is ingesteld. Dit zijn slechts een paar voorbeelden van wat je allemaal kan vinden. Het handmatig bestuderen van het schema kan vervelend zijn, maar er zijn natuurlijk ook hulpmiddelen.
Vervolgens is het tijd om beveiligingsscans uit te voeren en wij raden aan om met een statische applicatiebeveiligingstest (SAST) te beginnen. Dit is een inside-out test die de broncode analyseert. Het helpt bij het op de juiste manier aanroepen van de methoden, bij het correct configureren van jouw framework en bij het controleren van de interne datastromen. SAST kan en moet in een vroeg stadium worden uitgevoerd. Wij raden aan ermee te beginnen bij het schrijven van de eerste regel code. Door vroeg te testen van je bugs op het moment dat ze nog makkelijk te repareren zijn en je je architectuur nog niet helemaal hebt vastgelegd. SAST is vooral goed in het vinden van zogenaamde injection attacks.
Zodra de applicatie zelfstandig kan draaien, is het verstandig dynamische beveiligingstesten (DAST) toe te voegen. Je test dan van outside-in. Deze test stuurt speciaal vervaardigde verzoeken naar de API en controleert de reactie, waarbij verschillende soorten aanvallen worden gesimuleerd. DAST is een holistische test van het hele ecosysteem. En legt vaak authenticatiebugs van zowel de OWASP Top 10 als de API Top 10 bloot. Houd er rekening mee dat een DAST-scanner het API-schema nodig heeft dat we eerder noemden, dus zorg ervoor dat je dat bij de hand hebt om de scan te starten.
Vergeet niet gebruik te maken van tools die je al hebt! Lever je je API’s via een cloudprovider? Maak dan gebruik van de beveiligingsfeatures die daar aanwezig zijn en waarvoor je al betaalt. Rate limiting, firewalls voor webapplicaties, logboekregistratie van audits en sterke authenticatie zijn slechts enkele functionaliteiten die me hier te binnen schieten.
Penetratietesten werken het beste, maar zijn duur en duren lang. Daarom is het belangrijk dat jouw testers zich richten op het belangrijkste onderdeel van de applicatie. Met geautomatiseerde beveiligingsscans worden zoveel mogelijk zwakke plekken gevonden en opgelost voordat de pentest begint. Als je goede scanners gebruikt, integreren ze SAST en DAST in je IDE, waardoor ontwikkelaars direct feedback kunnen krijgen over het verbeteren van de beveiliging van hun code. Onthoud: geen enkele tool kan een penetratietest volledig vervangen, maar het kan er wel voor zorgen dat je minder vaak volledige tests hoeft uit te voeren en dat bespaart geld.
Samenvattend
Het beveiligen van API’s kan een lange reis zijn, maar de beste manier om te beginnen is door de eerste stap te zetten. Deze blog geeft je een aantal uitgangspunten die je in overweging moet nemen. Weet je welke API’s je hebt en wie de eigenaar is? Volg je een methodiek zoals de ASVS en voer je penetratietesten op de goede manier uit? Geavanceerde tools voor beveiligingsscans, zoals die in ons Fortify-portfolio, helpen geautomatiseerde tests uit te voeren en eenvoudig te integreren in een DevSecOps-workflow, zodat je snel en vaak met vertrouwen releases kunt vrijgeven.
Wil je meer weten over API security, wat een ideale aanpak is en hoe dit er werkend uitziet? Neem deel aan ons evenement over best practices in API-beveiliging in Utrecht op woensdagmiddag 22 maart. https://events.microfocus.com/API_security
Of download de gratis Developers guide to API security
Dit is een ingezonden bijdrage van OpenText Cybersecurity. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.
3 uur geleden
