Moderne cloudstrategieën maken veelvuldig gebruik van API's voor gecontroleerde, interactieve toegang tot gehoste services. Maar de toegang wordt alleen gecontroleerd als de API's veilig zijn geïmplementeerd en niet vatbaar zijn voor misbruik.
Web API's
Een Application Programming Interface (API) laat software communiceren met andere software. Dat vereist een reeks specificaties. Er moet een gedocumenteerde set functies zijn die het API-eindpunt biedt en regels over wat de API-client moet doen om die functies te gebruiken. Het type en de indeling van de gegevens die door de API worden geretourneerd, moeten voor elke functie worden gedefinieerd. Meestal wilt u beperken wie toegang heeft tot de API, dus API-clients moeten zich op de een of andere manier verifiëren. In een beperkte API mogen verzoeken alleen worden afgehandeld als het API-eindpunt heeft geverifieerd dat het verzoek legitiem is.
GERELATEERDWat is een “API” en hoe gebruik je er een?
Zoals bij alle softwareontwikkeling, is een methode voor beveiliging door ontwerp veel beter dan eerst bouwen en later beveiligen. De ramp met de Peloton API illustreert dit perfect. Door een gebrekkige API-implementatie die nu is opgelost, konden niet-geverifieerde API-aanroepen worden afgehandeld.
Iedereen kan persoonlijke gegevens over elke Peloton-klant terughalen. De eerste “reparatie” eenvoudig de API beperkt tot Peloton-eigenaren. Dit was slechts marginaal beter. Met de definitieve oplossing zijn de gegevens van een Peloton-gebruiker eindelijk privé, tenzij ze er expliciet voor kiezen om deze te delen.
Er zijn veel andere voorbeelden van zwakke of slecht ontworpen API's. Facebook heeft de persoonlijke gegevens van 533 miljoen van zijn gebruikers openbaar gemaakt omdat een API iedereen in staat stelde een database te doorzoeken met telefoonnummers, met een snelheid van maximaal 1000 per minuut.
Advertentie
Meer dan 80 procent van al het internetverkeer is API-verkeer. Dat zijn veel API's. Medio 2021 is de top 10 van beveiligingsrisico's van het Open Web Application Security Project (OWASP) de afgelopen jaren niet veranderd. Helaas worden dezelfde fouten die tot dezelfde kwetsbaarheden leiden keer op keer herhaald. En dat is te verleidelijk voor cybercriminelen om te negeren.
Development Stakeholders
API's zijn vaak minder goed beveiligd dan websites en mobiele apps. Prestatie-eisen kunnen het ontwikkelteam dwingen zich te concentreren op het lean and mean maken. Zo slank dat ze heel weinig of geen code bevatten die is bedoeld om de API en de gegevens die ze beveiligen te beschermen. Een slecht ontworpen of slecht geïmplementeerde API heeft zwakke punten die kunnen worden uitgebuit. De juiste sanering is niet om er een pleister op te plakken en te proberen de gaten te dichten. U moet de code repareren, of mogelijk de bedrijfslogica die in de API is gemodelleerd.
GERELATEERDHoe u uw organisatie kunt beschermen tegen aanvallen op wachtwoordwoordenboek
Wanneer veel softwarecomponenten met elkaar praten via API-aanroepen, zoals microservices, wordt het erg moeilijk om procesfouten in de bedrijfslaag te herkennen. Uw code kan de eenheids-, regressie- en andere tests doorstaan. Het is mogelijk dat u geen crashes ervaart. Al je logs zijn schoon. Maar dat betekent niet dat de logica correct is, noch dat alle mogelijke kwetsbaarheden zijn overwogen. Het samenbrengen van uw beveiligingsteam en uw ontwikkelteam kan verrassende inzichten opleveren.
Het ontwikkelteam is verantwoordelijk voor het schrijven van de API's die de benodigde functionaliteit leveren. Het beveiligingsteam is verantwoordelijk voor het beschermen van de gegevens die via de API worden beheerd. Ze zijn beide belanghebbenden bij het succes van het ontwikkelingsproces. Ontwikkelaars zullen nooit nadenken over beveiliging, bedreigingen en aanvallen zoals het beveiligingsteam. Waarom zou u niet beide expertises inzetten op het probleem?
Typen aanvallen
De veelvoorkomende aanvalstypes die u zult tegenkomen, kunnen worden gegroepeerd op basis van hun aanvalstechniek.
- Inloggegevens vullen: dit is vergelijkbaar met brute-force-aanvallen van wachtwoorden, maar het gebruikt API-referenties in plaats van wachtwoorden van gebruikersaccounts.< /li>
- Injectie-aanvallen: Bij een injectie-aanval voegt de cybercrimineel computerinstructies toe aan hun API-verzoeken op zo'n manier dat de ingebedde instructies werken op het API-eindpunt. SQL-injectie is een aanval waarbij misbruik wordt gemaakt van SQL-databases. Vaak is het gemakkelijk om uit te zoeken welke tekstelementen in een API-aanroep in SQL-instructies zullen worden opgenomen. Het toevoegen van SQL-instructies aan die API-functieaanroepen kan ertoe leiden dat die SQL-fragmenten worden verwerkt door de SQL-servers van het API-eindpunt. Cross-site scripting is een vergelijkbare aanval waarbij de ingesloten instructies in een scripttaal zijn, meestal JavaScript.
- Distributed Denial-of-Service (DDoS): deze aanvallen lijken erg op de DDoS-aanvallen die een website overspoelen met verkeer, waardoor echte verzoeken niet kunnen worden afgehandeld. DDoS-aanvallen gericht op API-eindpunten worden steeds populairder bij bedreigingsactoren.
- Man-in-the-Middle (MitM)Deze aanvallen zijn afhankelijk van het onderscheppen van verkeer tussen een echte, onschuldige API-client en het API-eindpunt. Als API-verificatiegegevens worden vastgelegd, kunnen ze worden gebruikt om opnieuw verbinding te maken door zich voor te doen als de echte API-client. Soms worden de API-aanroepen van de echte client aangepast zodat het API-eindpunt doet wat de aanvallers willen, niet wat de daadwerkelijke client wil.
Bescherming Uw API's
Als u een subset van uw IT-infrastructuur wilt beveiligen, kan het verleidelijk zijn om naar specifieke of nieuwe oplossingen te zoeken. Maar vergeet de basisprincipes van cyberbeveiliging niet.
Kwantificeer waar je mee te maken hebt
Als je niet weet wat je hebt, kun je het niet beheren. U moet alle API's die u gebruikt identificeren en karakteriseren, of u ze nu hebt gemaakt of niet. De resultaten van uw API-audit kunnen mogelijkheden aan het licht brengen om uw gebruik van API's te vereenvoudigen of te rationaliseren. Het zal ook alle verouderde of verweesde API's markeren die moeten worden bijgewerkt of uitgeschakeld.
Advertentie
Zodra u weet welke API's u heeft, wat ze doen en hoe ze worden beschermd en veerkrachtig gemaakt, kunt u uw API-beveiligingsstrategie documenteren. Maak van de gelegenheid gebruik om basisregels vast te stellen voor op beveiliging gebaseerde ontwikkeling en plan uw API-roadmap.
Welke gegevens zijn toegankelijk via de API-aanroepen? Is het persoonlijk identificeerbare informatie of op een andere manier gevoelig? Wat is de gegevensclassificatie? Als uw gegevensbeschermingsbeleid correct is geïmplementeerd, bevatten ze deze informatie al. Bekijk kritisch de toegang tot de gegevens. Geeft u meer gegevens vrij dan nodig is?
Maak uw API's beknopt
Als u van uw API een rijke ervaring voor de dataconsument wilt maken, kan dit leiden tot overrapportage en het onnodig prijsgeven van details van het API-eindpunt zelf. Informatie over betrokkenen, coderingssleutels en authenticatietokens zijn allemaal gelekt door overdreven uitgebreide API's. Een meer doordachte en veilige benadering is om de minimale hoeveelheid gegevens te retourneren die de API-client nodig heeft om de gevraagde functie te vervullen.
Dit keert terug naar het principe van de minste toestemming, een cyberbeveiligingsmiddel. U moet gebruikers, processen, IoT-apparaten of iets anders dat interactie heeft met uw IT alleen de minimale bevoegdheden verlenen die nodig zijn om hun rol of functie te vervullen. Doe hetzelfde met uw API's.
Gebruik versleuteling
Versleutel uw API-verkeer met TSL, de opvolger van SSL. Laat u niet leiden door de waarde van de gegevens. Onthoud dat u ook API-clientverificatietokens beschermt. Aanvallers geven misschien niet om de gegevens. Maar als ze authenticatietokens verwerven, kunnen ze de API misschien gebruiken om meer aanwijzingen over uw systemen te verkrijgen, zodat ze verschillende aanvallen kunnen uitvoeren.
Authenticatie en Invoerwaarden
Uiteraard heb je een sterk authenticatiesysteem nodig. Vind het wiel niet opnieuw uit. Gebruik waar mogelijk een erkende oplossing zoals OAuth2.0. Je zou kunnen denken dat interne API's niet hoeven te worden geverifieerd. Maar kunt u garanderen dat een interne API niet per ongeluk openbaar wordt gemaakt, misschien omdat deze in een ander project wordt hergebruikt?
Advertentie
Accepteer nooit blindelings invoer van een API zonder deze te valideren eerste. Scan het op misvormde inhoud, ingesloten scripts en overschrijdingsaanvallen.
Houd rekening met de frequentie van verbindingsverzoeken en pas verstandige snelheidsbeperkende maatregelen toe. Is een hoogfrequente bezoeker iemand die met brute kracht naar binnen probeert te komen, of probeert hij op verzoek gegevens uit uw database te halen?
Allied Technologies
Allied Technologies
h3>
Webtoepassingsfirewalls (WAF's) helpen websites, gehoste toepassingen en API's te beschermen door verkeer van en naar de beschermde bron te filteren en te bewaken. Ze kunnen onder andere aanvallen detecteren, zoals cross-site scripting en SQL-injectie. Een WAF is een technologie voor bescherming van de applicatielaag (niveau 7 in het ISO-model), geen pasklare oplossing voor al uw website- of API-beveiliging. Ze kunnen het beste worden ingezet als één element in een gelaagde reeks verdedigingen.
Een API-gateway bevindt zich tussen het API-eindpunt en de API-clients. Ze bemiddelen API-verzoeken tussen de clients en het API-eindpunt, waarbij ze soms een verzoek opsplitsen in kleinere stukken die worden bediend door verschillende back-end-microservices. antwoorden worden verzameld en teruggestuurd naar de API-client. API-gateways kunnen worden geïntegreerd met, of voorzien in, authenticatie- en snelheidsbeperkende faciliteiten. Er zijn Software-as-a-Service API-gateways beschikbaar, die hoge beschikbaarheid en automatische schaling bieden.
API's zijn in de frontlinie
Met de meedogenloze opkomst van cloud en microservices bevinden API's zich in de frontlinie van cyberaanvallen. Cybercriminelen houden van kansen als ze in hun voordeel worden gestapeld. met zoveel API's die er zijn, is het onvermijdelijk dat veel van hen slecht of zelfs onbeschermd zullen zijn. Laat ze niet van jou zijn.