Wellicht kent u Cloudflare als het bedrijf dat bijna 20% van het internet ondersteunt. Maar ondersteunen en beschermen van websites en statische content is slechts een klein deel van wat we doen. Feitelijk bestaat meer dan de helft van het dynamische verkeer van ons netwerk niet uit webpagina's maar Application Programming Interface (API)-verkeer — de rode draad die technologie laat werken. Deze blog introduceert en is een aanvulling op het Rapport over beveiliging en beheer van API’s 2024 waarin we precies beschrijven hoe we onze klanten beschermen en wat dit betekent voor de toekomst van API-beveiliging. In tegenstelling tot andere API-rapporten uit de sector is ons rapport niet gebaseerd op gebruikersenquêtes, maar op echte verkeersgegevens.
Als er één ding is dat u uit ons rapport van dit jaar moet onthouden, is het dit: veel organisaties hebben geen nauwkeurige inventaris van hun API's, zelfs als ze denken dat ze API-verkeer correct kunnen identificeren. Cloudflare helpt organisaties al hun openbaar toegankelijke API's te ontdekken met twee benaderingen. Eerst configureren klanten onze API-opsporingstool om identificerende tokens in hun bekende API-verkeer te monitoren. Vervolgens gebruiken we een machine learning model dat niet alleen deze bekende API-oproepen scant, maar alle HTTP-verzoeken, om API-verkeer te identificeren dat mogelijk niet is opgemerkt. Het verschil tussen deze benaderingen is opvallend: we hebben 30,7% meer API-eindpunten ontdekt via machine learning dan met de zelfgerapporteerde benadering, wat suggereert dat bijna een derde van de API's “schaduw-API's” zijn — en mogelijk niet correct zijn geïnventariseerd en beveiligd.
Lees verder voor extra's en de belangrijkste zaken uit ons eerste API-beveiligingsrapport. In het volledige rapport vindt u bijgewerkte statistieken over de dreigingen die ze zien en voorkomen, samen met onze voorspellingen voor 2024. We voorspellen dat een gebrek aan focus op API-beveiliging bij organisaties zal leiden tot een grotere complexiteit en verlies van controle, en dat een grotere toegang tot generatieve AI zal leiden tot meer API-risico’s. We verwachten ook een toename van het aantal aanvallen op API-businesslogica in 2024. Ten slotte zullen alle bovengenoemde risico's een groter management rond API-beveiliging noodzakelijk maken.
Verborgen aanvalsplekken
Hoe verschillen webpagina's en API’s van elkaar? API’s zijn een snelle en eenvoudige manier voor applicaties om op de achtergrond gegevens op te halen, of verzoeken daarvoor doen bij andere applicaties. Iedereen kan bijvoorbeeld een weerapp maken zonder meteoroloog te zijn: een ontwikkelaar kan de structuur van de pagina of mobiele applicatie schrijven en een weer-API om de voorspelling vragen op basis van de locatie van de gebruiker. Cruciaal is dat de meeste eindgebruikers niet weten dat de gegevens afkomstig zijn van de weer-API en niet van de eigenaar van de app.
Hoewel API’s de rode draad zijn van het internet, zijn ze ook gevoelig voor misbruik. Lekken in API-authenticatie en authorisatie bij Optus leidde tot een dreiging waarbij 10 miljoen gebruikersrecords te koop werden aangeboden, en overheidsinstellingen hebben gewaarschuwd voor exact deze API-aanvallen. Ontwikkelaars in een organisatie zullen vaak internetgerichte API’s maken, die door hun eigen applicaties worden gebruikt om efficiënter te functioneren, maar het is aan het beveiligingsteam om deze nieuwe openbare interfaces te beschermen. Als het proces om API’s te documenteren en onder de aandacht van het beveiligingsteam te brengen niet duidelijk is, worden het schaduw-API’s - die in productie actief zijn, maar zonder medeweten van de organisatie. Dit is waar de veiligheidsuitdaging begint.
Om klanten te helpen dit probleem op te lossen, hebben we API Discovery. Toen we onze laatste versie uitbrachten, we hebben vermeld hoe weinig organisaties over nauwkeurige API-inventarisaties beschikken. Beveiligingsteams worden soms gedwongen om een ‘e-mail en vraag’-aanpak te hanteren om een inventaris op te bouwen. Daarbij zijn de reacties onmiddellijk verouderd bij de volgende applicatie-release wanneer API’s veranderen. Het is beter om API-wijzigingen bij te houden aan de hand van wijzigingen in de code, zodat u op de hoogte blijft van nieuwe releases. Dit heeft echter nog steeds het nadeel dat alleen actief onderhouden code wordt geïnventariseerd. Verouderde applicaties krijgen mogelijk geen nieuwe releases, ondanks dat ze productieverkeer ontvangen.
De benadering van Cloudflare voor beheer van API’s omvat het maken van een uitgebreide, accurate API-inventaris met een combinatie van machine learning-gebaseerde API-detectie en inspectie van netwerkverkeer. Dit is een integraal onderdeel van ons API Gateway-product, waar klanten hun internetgerichte eindpunten kunnen beheren en de API-status kunnen monitoren. Met de API Gateway kunnen klanten hun API-verkeer ook identificeren met behulp van sessie-ID's (meestal een header of cookie), wat helpt bij het specifiek identificeren van API-verkeer voor het detectieproces.
Zoals eerder opgemerkt blijkt uit onze analyse dat zelfs goed geïnformeerde klanten vaak een aanzienlijk deel van hun API-verkeer over het hoofd zien. Door het vergelijken van sessiegebaseerde API-detectie (met API-sessies om verkeer te detecteren) met onze machine learning-gebaseerde API-detectie (dat al het inkomende verkeer analyseert), ontdekten we dat de laatste gemiddels 30,7% meer eindpunten ziet! Zonder uitgebreide verkeersanalyse mist u mogelijk bijna een derde van uw API-inventaris.
Als u geen klant bent van Cloudflare, kunt u nog steeds starten met het inventariseren van uw API’s. Deze zijn doorgaans gerangschikt in een standaard formaat, genaamd OpenAPI, en veel ontwikkeltools kunnen OpenAPI-geformatteerde schemafiles maken. Als u een bestand heeft met dat formaat, kunt u zelf starten met het maken van een API-inventarisatie door deze schema's te verzamelen. Hier is een voorbeeld van hoe u de eindpunten uit een schemafile kunt halen, aangenomen dat u een bestand heeft in OpenAPI v3-formaat, genaamd `my_schema.json`:
import json
import csv
from io import StringIO
# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
schema = json.load(file)
# Prepare CSV output
output = StringIO()
writer = csv.writer(output)
# Write CSV header
writer.writerow(["Server", "Path", "Method"])
# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
url = server['url']
for path, methods in schema['paths'].items():
for method in methods.keys():
writer.writerow([url, path, method])
# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)
Tenzij u vanaf het begin van het ontwikkelingsproces van uw applicatie OpenAPI-schema's hebt gegenereerd en de API-inventaris hebt bijgehouden, mist u waarschijnlijk enkele eindpunten in de API-inventaris van uw productieapplicatie.
Nauwkeurige hoeveelheidslimieten minimaliseren het aanvalspotentieel
Als het gaat om stoppen van misbruik denken de meeste mensen in de praktijk aan hoeveelheidsbeperking. Instellen van limieten op uw API is een waardevolle tool om misbruik tegen te gaan en ongewenste overbelasting van de bron te voorkomen. Maar hoe weet u of u de juiste hoeveelheidsbeperkende aanpak hebt gekozen? De benaderingen kunnen variëren, maar komen over het algemeen neer op de gekozen foutcode en de basis voor de limiet zelf.
Voor sommige API’s worden hoeveelheidsbeperkende fouten geconfigureerd om te reageren met een HTTP 403 (verboden), terwijl andere zullen reageren met HTTP 429 (te veel verzoeken). Het gebruik van HTTP 403 klinkt onschuldig genoeg totdat u zich realiseert dat andere beveiligingstools ook reageren met 403-codes. Wanneer u wordt aangevallen, kan het moeilijk zijn om te onderscheiden welke tools verantwoordelijk zijn voor welke fouten/blokkeringen.
Als u HTTP 429 gebruikt voor uw hoeveelheidslimieten, weten aanvallers onmiddellijk dat er een hoeveelheidslimiet voor hen geldt en kunnen ze vlak onder de limiet gaan zitten zonder te worden opgemerkt. Dit kan prima zijn als u alleen maar verzoeken beperkt om ervoor te zorgen dat uw back-end overeind blijft, maar het kan uw aanvallers ook te veel inzicht geven. Bovendien kunnen aanvallers ‘uitschalen’ naar meer API-clients om per saldo wel een hoeveelheid aanvragen boven de limiet te doen.
Er zijn voor- en nadelen aan beide benaderingen, maar we merken dat verreweg de meeste API’s reageren met HTTP 429 van alle 4xx- en 5xx-foutmeldingen (bijna 52%).
Wat als het gaat om de logica van de hoeveelheidslimiet zelf, niet om de responsecode alleen? Implementeren van aanvraaglimieten op IP-adressen kan verleidelijk zijn, maar we raden aan dat u de limiet baseert op een sessie-ID als beste praktijk en alleen terugvalt op een IP-adres (of IP + JA3 vingerafdruk) als sessie-ID's niet beschikbaar zijn. Instellen van hoeveelheidslimieten op gebruikerssessies in plaats van IP-nummers zal op betrouwbare wijze identificeren welke gebruikers echt zijn en valse detecties minimaliseren die ontstaan bij gedeelde IP-nummers. Cloudflare’s Advanced Rate Limiting en API Gateway’s misbruikbescherming op aantallen maken het eenvoudig om deze limieten af te dwingen door sessieverkeer op elk API-eindpunt te monitoren en oplossingen met één klik te bieden om de snelheidslimieten per eindpunt in te stellen.
Om waarden te vinden voor uw hoeveelheidslimieten, berekent Cloudflare API Gateway sessieverzoek-statistieken voor u. We raden een limiet aan door te kijken naar de distributie van aanvragen per sessie over alle sessies naar uw API, zoals geïdentificeerd diir de klantgeconfigureerde API-sessie-identifier. Dan berekenen we statistische p-niveaus — die de aanvraaghoeveelheiden beschrijven voor verschillende verkeersgroepen — voor p50, p90 en p99 op deze distributie en gebruiken de variatie van de distributie om te komen tot een aanbevolen drempel voor elk afzonderlijk eindpunt in uw API-inventaris. De aanbeveling komt wellicht niet overeen met de p-niveaus, wat een belangrijk verschil is en een reden om p-niveaus niet alleen te gebruiken. Samen met de aanbeveling informeert API Gateway gebruikers over ons vertrouwen in de aanbeveling. Over het algemeen geldt dat hoe meer API-sessies we kunnen verzamelen, hoe meer vertrouwen we hebben in de aanbeveling.
Het activeren van een hoeveelheidslimiet is net zo eenvoudig als klikken op de link 'regel maken', en API Gateway brengt uw sessie-ID automatisch naar de pagina voor het maken van geavanceerde hoeveelheidslimietregels, zodat uw regels uiterst nauwkeurig zijn u zich tegen aanvallen te verdedigen en valse detecties te minimaliseren, vergeleken met traditionele, doorgaans te ruime grenzen.
API’s zijn ook onderhevig aan webapplicatie-aanvallen
API’s zijn niet immuun voor normale OWASP Top 10-aanvallen zoals SQL-injectie. De inhoud van API-aanvragen kan ook worden ingezet als database-invoer zoals met een invoerformulier op een internetpagina of een URL-argument. Zorg voor een web application firewall (WAF) die uw API-verkeer ook beschermd tegen deze vormen van aanval.
Toen we naar de door Cloudflare beheerde WAF-regels keken, waren injectie-aanvallen de op één na meest voorkomende bedreiging die Cloudflare op API’s uitgevoerd zag worden. De meest voorkomende bedreiging was HTTP-afwijking. Voorbeelden van HTTP-afwijkingen zijn verkeerd ingedeelde methodenamen, null-bytetekens in headers, niet-standaard poorten of een inhoudslengte van nul bij een POST-verzoek. Hier zijn de statistieken over de andere belangrijkste bedreigingen die we voor API’s hebben geconstateerd:
Niet op de kaart staan een verbroken authenticatie en autorisatie. Verbroken authenticatie en autorisatie doen zich voor wanneer een API er niet in slaagt te controleren of de entiteit die verzoeken om informatie naar een API verzendt, daadwerkelijk de toestemming heeft om die gegevens op te vragen of niet. Het kan ook gebeuren wanneer aanvallen proberen inloggegevens te vervalsen en minder beperkte machtigingen in te voegen in hun bestaande (geldige) inloggegevens die beperktere machtigingen hebben. OWASP categoriseert deze aanvallen op een aantal verschillende manieren, maar de hoofdcategorieën zijn Broken Object Level Authorization (BOLA) en Broken Function Level Authorization (BFLA) aanvallen.
De hoofdoorzaak van een succesvolle BOLA/BFLA-aanval ligt in het feit dat een bron-API het juiste eigendom van databaserecords niet controleert aan de hand van de identiteit die om die records vraagt. Het volgen van deze specifieke aanvallen kan moeilijk zijn, omdat de toestemmingsstructuur eenvoudigweg ontbreekt, ontoereikend is of onjuist is geïmplementeerd. Ziet u hier het kip-en-ei-verhaal? Het zou gemakkelijk zijn om deze aanvallen te stoppen als we de juiste toestemmingsstructuur kenden, maar als wij of onze klanten de juiste toestemmingsstructuur kenden of de handhaving ervan konden garanderen, zouden de aanvallen in beginsel al niet succesvol zijn. Houd ons in de gaten voor toekomstige lanceringen van API Gateway-functies, waarbij we onze kennis van API-verkeersnormen zullen gebruiken om automatisch beveiligingsbeleid voor te stellen dat BOLA-/BFLA-aanvallen markeert en stopt.
Hier zijn vier manieren om de mazen in de authenticatie te dichten die mogelijk bestaan voor uw API’s, zelfs als u niet over een gedetailleerd autorisatiebeleid beschikt:
- Ten eerste, dwing authenticatie af op elke openbaar toegankelijke API, tenzij er een door het bedrijf goedgekeurde uitzondering is. Zoek naar technologieën als mTLS en JSON Web Tokens.
- Beperk de snelheid van API-verzoeken naar uw servers om potentiële aanvallers af te remmen.
- Blokkeer abnormale uitstroomvolumes van gevoelige gegevens.
- Blokkeer aanvallers om legitieme reeksen API-verzoeken over te slaan.
API’s zijn verrassend mensgestuurd, niet meer machine-gestuurd
Als je al met technologie bezig bent sinds de tijd vóór de smartphone, toen minder mensen online waren, kan het verleidelijk zijn om te denken dat API’s alleen worden gebruikt voor machine-to-machine-communicatie tijdens een nachtelijk batchtaakproces. De waarheid is echter geheel anders. Zoals we hebben besproken, worden veel web- en mobiele applicaties aangedreven door API’s, die alles faciliteren, van authenticatie tot transacties tot het aanbieden van mediabestanden. Naarmate mensen deze applicaties gebruiken, is er een overeenkomstige toename van het API-verkeersvolume.
We kunnen dit illustreren door te kijken naar de API-verkeerspatronen die worden waargenomen tijdens vakanties, wanneer mensen samenkomen met vrienden en familie en meer tijd besteden aan sociale contacten en minder tijd online. We hebben de volgende wereldwijde API-verkeersgrafiek voorzien van algemene feestdagen en promoties. Merk op hoe het verkeer piekt rond Black Friday en Cyber Monday rond het niveau van +10% wanneer mensen online winkelen, maar vervolgens afneemt tijdens de feestdagen rond Kerstmis en Nieuwjaar.
Dit patroon lijkt sterk op wat we zien in regulier HTTP-verkeer. Het is duidelijk dat API’s niet langer alleen het domein van geautomatiseerde processen zijn, maar nauw verbonden zijn met menselijk gedrag en sociale trends.
Aanbevelingen
Er bestaat geen wondermiddel voor holistische API-beveiliging. Voor het beste effect raadt Cloudflare vier strategieën aan om de API-beveiligingshouding te verbeteren:
- Combineren van de ontwikkeling, zichtbaarheid, prestaties en beveiliging van API-applicaties met een uniform controlepunt dat een up-to-date API-inventaris kan bijhouden.
- Gebruiken van beveiligingstools met machine learning-technologieën om personeel vrij te maken en de kosten te verlagen.
- Hanteren van een positief beveiligingsmodel voor uw API’s (zie hieronder voor een uitleg over positieve en negatieve beveiligingsmodellen).
- Meten en verbeteren van het API-ontwikkelingsniveau van uw organisatie in de loop van de tijd (zie ook hieronder voor een uitleg van een API-ontwikkelingsniveau).
Wat bedoelen we met een “positief” of “negatief” beveiligingsmodel? In een negatief model zoeken beveiligingstools naar bekende tekenen van aanvallen en ondernemen actie om deze aanvallen te stoppen. Binnen een positief model zoeken beveiligingstools naar bekende goede verzoeken en laten deze alleen door, waardoor al het andere wordt geblokkeerd. API’s zijn vaak zo gestructureerd dat positieve beveiligingsmodellen zinvol zijn voor de hoogste beveiligingsniveaus. U kunt ook beveiligingsmodellen combineren, zoals het gebruik van een WAF in negatieve modellen, en het gebruik van API Schema Validation in positieve modellen.
Hier is een snelle manier om het ontwikkelingsniveau van de API-beveiliging van uw organisatie in de loop van de tijd te meten: Beginnende organisaties gaan aan de slag met het samenstellen van hun eerste API-inventaris, hoe onvolledig deze ook is. Meer volwassen organisaties zullen streven naar nauwkeurigheid van de API-inventaris en automatische updates. De meest volwassen organisaties zullen actief beveiligingscontroles afdwingen in een positief beveiligingsmodel op hun API‘s, waarbij ze het API-schema afdwingen, authenticatie controleren en gedrag controleren op tekenen van misbruik.
Voorspellingen
Tot slot onze top vier voorspellingen voor 2024 en daarna:
Toename in verlies van controle en complexiteit: we hebben praktijkmensen op het gebied van API-beveiliging en -beheer ondervraagd en 73% antwoordde dat beveiligingsvereisten hun productiviteit en innovatie belemmeren. In combinatie met de steeds groter wordende applicaties en onnauwkeurige inventarissen zullen de API-risico's en de complexiteit toenemen.
Eenvoudigere toegang tot AI leidt tot meer API-risico’s: de opkomst van generatieve AI brengt potentiële risico's met zich mee, waaronder de API’s van AI-modellen die kwetsbaar zijn voor aanvallen, maar ook ontwikkelaars die slordige, door AI geschreven code leveren. Forrester voorspelt dat in 2024, zonder de juiste vangnetten, “minstens drie datalekken publiekelijk zullen worden toegeschreven aan onveilige, door AI gegenereerde code – hetzij als gevolg van beveiligingsfouten in de gegenereerde code zelf, hetzij als gevolg van kwetsbaarheden in door AI gesuggereerde afhankelijkheden.”
Toename in op businesslogica gebaseerde fraude-aanvallen: professionele fraudeurs runnen hun activiteiten als een bedrijf, en ze hebben net als ieder ander kosten. We verwachten dat aanvallers nog efficiënter fraudebots tegen API’s zullen gebruiken dan in voorgaande jaren.
Toenemende behoefte aan toezicht: De eerste versie van PCI DSS die rechtstreeks betrekking heeft op API-beveiliging, wordt van kracht in maart 2024. Controleer de specifieke vereisten voor uw branche bij uw auditafdeling, zodat u voorbereid bent op de vereisten zodra deze van kracht worden.
Als u geïnteresseerd bent in het volledige rapport, kunt u het Rapport voor beveiliging en beheer van API’s 2024 hier downloaden, met alle informatie over onze aanbevelingen.
Cloudflare API Gateway is onze API-beveiligingsoplossing, en het is beschikbaar voor alle zakelijke klanten. Als u niet bent aangemeld voor API Gateway, klik dan hier om onze eerste API-opsporingsresultaten te zien en een proefperiode starten in het Cloudflare-dashboard. Voor meer informatie over hoe u de API Gateway kunt gebruiken om uw verkeer te beveiligen, klikt u hier om onze ontwikkelingsdocumenten te zien en hier voor onze opstartgids.