Nu application programming interfaces (api’s) steeds meer de grondslag vormen voor applicatie-ontwikkeling, is daarmee ook het aanvalsoppervlak gegroeid. Gartner verwacht dat api-misbruik in 2022 de meest voorkomende aanvalsmethode is om data te stelen uit webapplicaties. Hoe gaan we hier veilig mee om?
Api’s (application programming interfaces) bieden een manier voor app-ontwikkelaars om informatie van buitenaf te verwerken in applicaties die ze bouwen. Dit is belangrijk voor ze omdat het het codeerproces vereenvoudigt en hen toegang biedt tot een enorme hoeveelheid data. Api’s zijn ook een zegen voor serviceproviders omdat het nieuwe mogelijkheden biedt om andere data en diensten te leveren. De eindgebruiker profiteert hierdoor van innovatieve interactieve apps.
Het nadeel van publiekelijk beschikbare webapi’s is dat ze risico’s opleveren. Het doel van api’s is om buitenstaanders toegang te geven tot je data. Achter elke api hangt een endpoint – de server (en bijbehorende databases) die reageert op aanvragen (requests). De endpoints en de risico’s zijn vergelijkbaar met een internetgerichte webserver. Het verschil is dat websites meestal iets van toegangscontrole hebben, en api’s niet.
In het ergste geval is het niet alleen de data die risico loopt, maar de hele infrastructuur. Kwetsbare api’s zijn een geweldig startpunt voor uiteenlopende netwerk-hijacking aanvallen. De juiste tactiek, vaak een aanval met meerdere niveaus, kan ertoe leiden dat gevoelige data wordt blootgesteld.
Veelvoorkomende aanvallen
Api’s worden dus slachtoffer van dezelfde soort aanvallen als netwerken en webgebaseerde applicaties. Hieronder een klein overzicht van de meest voorkomende aanvallen.
- Injection. Dit gebeurt wanneer een aanvaller kwaadaardige code of opdrachten toevoegt aan een programma, vaak op een plek waar input van een gebruiker normaal is, zoals gebruikersnaam en wachtwoord. SQL-injection is een specifiek type hiervan dat de aanvaller in staat stelt een SQL-database over te nemen. Door alle api-verzoeken te valideren is dit tegen te gaan. Gelimiteerde response data zorgt ervoor dat gevoelige gegevens niet zomaar worden gelekt.
- Cross-site scripting (xss) is een type injection-aanval waarbij een kwetsbaarheid wordt gebruikt om aanvullend script (vaak JavaScript) toe te voegen aan code van een webapp of website. Een bescherming hiertegen is input valideren en character escaping en filtering toe te passen.
- DDoS-aanvallen maken een netwerk, systeem of website ontoegankelijk voor bezoekers door meer verkeer eropaf te sturen dan het aankan. Api-endpoints vormen een steeds populairder DDoS-doelwit. Rate limiting en gelimiteerde payload-groottes is een eerste stap dit tegen te gaan.
- De man-in-the-middle-aanvallen kenmerken zich door het onderscheppen van de communicatie tussen twee systemen middels een onzichtbare, legitiem lijkende proxy. Bij api’s kunnen deze aanvallen plaatsvinden tussen de client (app) en de api, of tussen de api en het endpoint. Door verkeer te versleutelen worden deze risico’s verkleind.
- Credential stuffing is het gebruik van gestolen credentials voor api-authenticatie endpoints om toegang te krijgen. Middels intelligente feeds is dit te identificeren en rate limits houden brute force aanvallen onder controle.
Beveiliging
Naast de genoemde tegenmaatregelen is het van belang om meer te doen. Eigenlijk de basisbeveiliging en de bewezen securitycontroles.
Beveiliging moet prioriteit zijn, niet iets dat achteraf kan worden toegepast. Security moet in api’s worden gebouwd op het moment dat ze worden ontwikkeld. Breng ze in kaart en werk samen met het devops-team om ze te beheren.
Slechte of ontbrekende authenticatie en autorisatie kan grote gevolgen hebben. Veel private api’s die voor interne doeleinden zijn, vereisen niet vaak authenticatie of missen een authenticatie-factor (iets dat je weet, hebt of bent) waardoor de beveiliging ondermijnd wordt. Aangezien api’s toegang bieden tot een database van een organisatie is het cruciaal dat het bedrijf strenge toegangscontrole toepast. Bewezen mechanismen als OAuth2.0 en OpenID Connect moet worden overwogen. Pas ook het principe van least privilege toe. Gebruikers, processen, programma’s, systemen en apparatuur moeten de minimale toegangsrechten krijgen die ze nodig hebben voor hun doel.
Api’s die regelmatig gevoelige data uitwisselen, zoals credentials, creditcardgegevens, bankinformatie en gezondheidsgegevens, moeten worden voorzien van tls-encryptie dat het verkeer versleutelt. Kijk ook of er data is die verwijderd kan worden. Api’s zijn ontwikkelaars-tools dus vaak bevatten ze wachtwoorden, keys of andere info die weg moet worden gehaald zodra ze publiekelijk beschikbaar worden gesteld. Dit wordt vaak over het hoofd gezien. In de devsecops moet dit een standaard handeling zijn. Ga ook na of een api niet meer informatie geeft dan nodig is. Zorg voor datatoegangcontroles op api-niveau, monitor data, en verwijder het zodra er toch vertrouwelijke data zichtbaar is.
Ten slotte moet input vanuit een api naar het endpoint altijd gevalideerd worden. Dankzij rate limiting wordt het aantal opeenvolgende requests beperkt en worden denial-of-service-aanvallen tegengegaan. Een web application firewall die api-payloads begrijpt biedt een extra beschermingslaag.
Veilige applicatie-ontwikkeling
Api’s lijken snel de populairste manier te worden om moderne applicaties te bouwen, zeker voor mobiele en internet of things (iot)-apparatuur. De constant veranderende methodes voor app-ontwikkeling, gecombineerd met de druk om te innoveren, betekent dat veel organisaties onvoldoende oog hebben voor de risico’s die komen kijken bij het publiekelijk maken van de api’s.
Het goede nieuws is dat veel bedrijven al maatregelen hebben genomen om de bekende aanvallen te weerstaan. Het is goed om bovenaan de lijst te beginnen en verder naar beneden te werken. Los van hoeveel api’s er in een organisatie zijn en publiekelijk worden gemaakt, moet het doel altijd zijn om stevige security-policies toe te passen vanaf een vroeg stadium en ze gedurende de hele tijd te beheren.
