Als je hebt gelet op de OWASP API Security Top-10, is je waarschijnlijk opgevallen dat de versie van 2023 aanzienlijk is veranderd. Hoewel sommige wijzigingen vooral semantisch zijn, is de nieuwe vermelding op nummer 10 allesbehalve oppervlakkig. Deze heet “Unsafe Consumption of APIs“. Het is begrijpelijk als dit niet meteen een belletje doet rinkelen, laat staan alarmbellen doet afgaan. Toch is het een groeiende bedreiging die anders van aard is dan de andere bedreigingen. Maar ik heb een eenvoudige oplossing voor je. Laat me het uitleggen.
Begrijpen van onveilige API consumptie
Wat is onveilige API consumptie? Bedrijven gebruiken steeds vaker software systemen als een dienst in de cloud. APIs zijn zeker een zeer handige manier om die cloudsystemen met elkaar te verbinden, en met de resterende on-premises systemen. Er is nauwelijks assemblage nodig. Geweldig. Maar ben je je er voldoende van bewust dat er een daadwerkelijke dreiging is bij het blindelings verwerken van API-reacties? Een dreiging vergelijkbaar met het onveilig aanbieden van APIs?
Waarom is het een groeiende bedreiging? Als consument van clouddiensten verwacht je dat deze systemen betrouwbaar zijn. Een professioneel bedrijf beheert ze, en ze hebben waarschijnlijk meer expertise in het veilig hosten van hun systemen dan jij zou hebben in een on-premises scenario. Toch? Nou, meestal wel. Je gaat ervan uit dat je providers nooit het slachtoffer kunnen worden van een insider-dreiging, een kwaadaardige inbraak of gewoon een foutieve update. En je gaat ervan uit dat er niemand tussen zit die je berichten verknoeit. Toch zijn supply chain-aanvallen echt.
Het belang van vertrouwen en verificatie
De rol van Zero Trust Security
Er is een reden waarom zero trust security zo belangrijk is geworden. Weet je echt zeker dat je verbonden bent met je leverancier? Weet je echt zeker dat er geen man-in-the-middle is? Je zou zeker niet de eerste zijn die in een veelvoorkomende valkuil trapt. En zelfs als je een VPN of een wederzijds geauthenticeerde TLS-verbinding hebt opgezet, kun je nog steeds kwaadaardig worden omgeleid naar een derde partij als je niet oppast.
Mogelijke risico’s bij API consumptie
Je provider kan het slachtoffer worden van een insider-aanval of zelfs een supply-chain-aanval, wat de reacties op je API-aanroepen kan verstoren. Dat is een bekende manier om valse omleidingen, malware, exploderende zip-bestanden of willekeurige wartaal te injecteren, ontworpen om je clientsysteem neer te halen. Helaas gebeurt dit echt, anders zou het niet in de OWASP Top-10 staan.
Onveilige consumptie van APIs is in wezen een gebrek aan responsvalidatie. Gelukkig is er een eenvoudige strategie om dit tegen te gaan.
Hoe je te beschermen tegen onveilige API consumptie?
Als consument van een API bezit je de Open API Specificatie niet. Deze wordt aan je geleverd door de API-eigenaar. Bovendien wordt de levenscyclus ervan ook beheerd door de eigenaar. Een verantwoordelijke API-eigenaar moet een rijke specificatie van zijn API bieden, ontworpen om misbruik te voorkomen. Immers, een Open API Specificatie fungeert als het contract tussen de API-provider en de API-client. Een slecht contract is een broedplaats voor misinterpretaties en conflicten. Dus investeren in een duidelijk, goed geschreven contract is een investering in een gezonde relatie met je klanten.
Onthoud, de Open API Specificatie formaliseert de semantiek van het contract, waardoor automatische handhaving mogelijk is. Het veronderstelt een proces van het detailleren van je contract tot een niveau waarop elke API-aanroep er zinvol tegen kan worden gevalideerd. Ik noem het ‘API Hardening‘. Het haalt de kwetsbaarheid uit de integraties.
Helaas biedt niet elke API-eigenaar om welke reden dan ook een goed gedefinieerd contract. Maar dit mag je er niet van weerhouden om de API Specificatie die je gebruikt te versterken. Vooral de definitie van de informatie die je toestaat in je systemen te laten stromen, zou van belang moeten zijn.
Hoe til je je schild op?
Gebruik van tools voor API Security audits
Je neemt de API Specificatie zoals die wordt geleverd. Laten we de SCIMv2 API als voorbeeld nemen. SCIM, System for Cross-domain Identity Management, is een industriestandaard API voor gebruikersprovisioning. Het wordt veel geĂŻmplementeerd in Identity Management Systems, HR Systems en CRM Systems, bijvoorbeeld.
Ik heb vrij willekeurig het SCIM2 yaml-bestand van gravity.io genomen en geladen in mijn VS Code IDE. Mijn eerste stap is altijd het scannen met de 42Crunch Audit Scanner. Het blijkt dat de API-specificatie beweert een swagger: ‘2.0’ bestand te zijn, maar niet voldoet aan de standaard. Dat is slecht, maar helaas niet zo ongebruikelijk. In dit geval is het oauth2 grant type ‘client-credentials’ een probleem. Het veranderen in ‘password’ voldoet ten minste aan de audit scanner. Maar voor interne doeleinden zou je kunnen overwegen om het beveiligingsschema te wijzigen in APIkey.
Bovendien was er een typefout in een trefwoord om te corrigeren: slordig! En dit blokkeerde mijn scanner incidenteel van het doen van zijn werk.
Na deze correcties onthulde onze vertrouwde 42Crunch Audit Scanner snel voldoende ruimte voor verbetering. Een magere audit score van 10/100. Tijd om aan het werk te gaan!
Voorbeeld: Verbeteren van SCIMv2 API specificaties
Zoals je waarschijnlijk weet, heeft de Open API Specificatie JSON Schema overgenomen voor het definiĂ«ren van de berichtinhoud – zowel uitgaande verzoeken als inkomende reacties. Uiteraard gaan we ons richten op de inkomende reacties. In feite zijn er twee verschillende soorten JSON-objecten om te overwegen: geldige reacties en foutreacties. Laten we de GET /Groups als voorbeeld nemen.
Het blijkt dat de geleverde definitie veel meer toestaat dan je zou willen. Er zit echter waardevolle informatie verborgen in de opmerkingen binnen het swagger-bestand. Als je in de eigenlijke API Specificatie duikt en naar de objectbeschrijvingen kijkt, vind je nuttige hints zoals “description: REQUIRED”, of “description: Non-negative integer”. Het trieste is dat dergelijke informatieve opmerkingen geen formele specificatie hebben, dus je kunt ze niet automatisch afdwingen. Maar gelukkig heeft JSON Schema de semantiek om aan onze behoeften te voldoen. Het is eigenlijk heel eenvoudig. Het invoeren van een “minimum: 1” in de specificatie maakt het geheel niet-negatief per definitie. Evenzo zal het toevoegen van het ‘required’ trefwoord aan het objecttype je in staat stellen een reactie beter automatisch te valideren. Zoals dit:
Group: {
   type: object
   required: [schemas, totalResults, Resources],
   properties: …Er zijn meer eenvoudige schema-verbeteringen te overwegen, bijvoorbeeld het toevoegen van een RegEx-patroon voor strings, een formatspecificatie voor een geldige URI die een namespace van de SCIM-schema’s specificeert,
schemas :
type: string,
format: uri,
maxLength: 1024
}of een opsomming van geldige waarden,
enum: [book, movie, video, blog, podcast, webinar],of iets dat bijdraagt aan je defensieve schild.
Wanneer je tevreden bent met het specificeren van de gegevens die je bereid bent te accepteren, is er nog Ă©Ă©n ding om voor te zorgen. En dat is het handhavingsgedeelte. Door een 42Crunch WebAPI Firewall tussen je client en de externe service te plaatsen, met je verbeterde specificatie van de API, kun je er zeker van zijn dat geen gegevens die in strijd zijn met je API-definitie zullen worden doorgegeven. Bovendien neemt het je API Specificatie als een allowlist, wat betekent dat alleen vooraf gespecificeerde elementen de firewall mogen passeren. Dus zelfs zonder de “unevaluatedProperties: false” richtlijn, worden niet-gedefinieerde eigenschappen – hoewel technisch toegestaan in de standaard – geblokkeerd.
Evenzo, zolang er geen http:301 (Moved Permanently) of http:308 (Permanent Redirect) reactie is verklaard in je API Contract, zal je API Firewall zo’n reactie simpelweg laten vallen. Mocht zo’n redirect ooit optreden, dan wordt een mogelijk kwaadaardige redirect effectief geneutraliseerd. Jij bent in controle over de reacties die je bereid bent te accepteren, en met behulp van de 42Crunch API Firewall, heb je de controle terug. Geen onveilige consumptie van APIs op jouw wacht. Dat is waar defensieve API Consumptie om draait.
Is er een nadeel?
Ik kan je bijna horen bezwaar maken.
“Maar, maar, elke keer dat mijn leverancier een wijziging aanbrengt in hun JSON Schema, zou ik mijn API Specificatie moeten bijwerken en mijn clients zouden ook naar de nieuwe versie moeten migreren. Zou dat niet onnodig omslachtig zijn?”
Nou, ik geloof sterk dat het eigenlijk goed is om je API specificatie bij te werken als je de implementatie of het contract ervan hebt veranderd. Het geeft consumenten de kans om de impact van de verandering te analyseren en pas de nieuwe versie te adopteren wanneer ze er klaar voor zijn. Je wilt toch nooit je clients breken?
Echter, in dit specifieke geval run je de client. Desalniettemin beheer je je eigen API specificatie. In feite heb ik je een tool gegeven om te voorkomen dat je ernstig kapot gaat. Wie weet hoe je client zich gedraagt met niet-gedefinieerde reacties? Je kunt simpelweg niet voor alles testen wat zou kunnen gebeuren. Herinner je je Hyrum’s law? Aan de veilige kant blijven in plaats van blindelings veranderingen accepteren, zal je helpen om beter te slapen ’s nachts.
Natuurlijk moet je in geval van een noodwijziging een proces hebben om je API Firewall snel bij te werken. Misschien zelfs tijdelijk je firewall in luistermodus zetten, zodra je zeker weet dat de verandering geldig is. Je kunt ook een waarschuwing triggeren zodra een API-reactie door de firewall wordt geweigerd. Het is tenslotte een beveiligingsgebeurtenis die je wilt opvolgen. Maar dat is een kleine prijs om te betalen voor het vermijden van onveilige consumptie van APIs.
Als je meer wilt weten over 42Crunch en wat het kan doen om je APIs te beschermen, ben je hier aan het juiste adres. We delen graag onze ervaring. Waarom neem je niet meteen contact met ons op?
