Aanbevelingen om OWASP API Security Top 10-bedreigingen te beperken met behulp van API Management

  • Artikel

VAN TOEPASSING OP: Alle API Management-lagen

De Open Web Application Security Project (OWASP) Foundation werkt aan het verbeteren van de softwarebeveiliging via haar door de community geleide opensource-softwareprojecten, honderden hoofdstukken wereldwijd, tienduizenden leden en door lokale en wereldwijde conferenties te hosten.

Het OWASP API Security Project richt zich op strategieën en oplossingen om de unieke beveiligingsproblemen en beveiligingsrisico's van API's te begrijpen en te beperken. In dit artikel bespreken we aanbevelingen voor het gebruik van Azure API Management om de tien belangrijkste API-bedreigingen te beperken die zijn geïdentificeerd door OWASP.

Notitie

Naast het volgen van de aanbevelingen in dit artikel, kunt u Defender voor API's inschakelen, een mogelijkheid van Microsoft Defender voor Cloud, voor API-beveiligingsinzichten, aanbevelingen en detectie van bedreigingen. Meer informatie over het gebruik van Defender voor API's met API Management

Autorisatie op objectniveau verbroken

API-objecten die niet zijn beveiligd met het juiste autorisatieniveau, kunnen kwetsbaar zijn voor gegevenslekken en onbevoegde gegevensmanipulatie via zwakke objecttoegangs-id's. Een aanvaller kan bijvoorbeeld misbruik maken van een object-id voor een geheel getal, die kan worden ge curseerd.

Meer informatie over deze bedreiging: API1:2019 Broken Object Level Authorization

Aanbevelingen

  • De beste plek om autorisatie op objectniveau te implementeren, is binnen de back-end-API zelf. In de back-end kunnen de juiste autorisatiebeslissingen worden genomen op aanvraagniveau (of object), indien van toepassing, met behulp van logica die van toepassing is op het domein en de API. Denk aan scenario's waarbij een bepaalde aanvraag verschillende detailniveaus in het antwoord kan opleveren, afhankelijk van de machtigingen en autorisatie van de aanvrager.

  • Als een huidige kwetsbare API niet kan worden gewijzigd in de back-end, kan API Management worden gebruikt als een terugval. Voorbeeld:

    • Gebruik een aangepast beleid om autorisatie op objectniveau te implementeren als dit niet is geïmplementeerd in de back-end.

    • Implementeer een aangepast beleid om id's toe te wijzen van aanvraag naar back-end en van back-end naar client, zodat interne id's niet worden weergegeven.

      In dergelijke gevallen kan het aangepaste beleid een beleidsexpressie zijn met een opzoekactie (bijvoorbeeld een woordenlijst) of integratie met een andere service via het beleid voor het verzenden van aanvragen .

  • Voor GraphQL-scenario's dwingt u autorisatie op objectniveau af via het validatiebeleid voor GraphQL-aanvragen met behulp van het authorize element.

Verbroken gebruikersverificatie

Verificatiemechanismen worden vaak onjuist geïmplementeerd of ontbreken, waardoor aanvallers misbruik kunnen maken van implementatiefouten voor toegang tot gegevens.

Meer informatie over deze bedreiging: API2:2019 Broken User Authentication

Aanbevelingen

API Management gebruiken voor gebruikersverificatie en autorisatie:

  • Verificatie - API Management ondersteunt de volgende verificatiemethoden:

    • Basisverificatiebeleid : referenties voor gebruikersnaam en wachtwoord.

    • Abonnementssleutel: een abonnementssleutel biedt een vergelijkbaar beveiligingsniveau als basisverificatie en is mogelijk niet alleen voldoende. Als de abonnementssleutel is aangetast, kan een aanvaller onbeperkte toegang krijgen tot het systeem.

    • Clientcertificaatbeleid : het gebruik van clientcertificaten is veiliger dan basisreferenties of abonnementssleutel, maar biedt geen flexibiliteit die wordt geboden door verificatieprotocollen op basis van tokens, zoals OAuth 2.0.

  • Autorisatie : API Management ondersteunt een gevalideerd JWT-beleid om de geldigheid van een binnenkomend OAuth 2.0 JWT-toegangstoken te controleren op basis van gegevens die zijn verkregen uit het metagegevenseindpunt van de OAuth-id-provider. Configureer het beleid om relevante tokenclaims, doelgroep en verlooptijd te controleren. Meer informatie over het beveiligen van een API met OAuth 2.0-autorisatie en Microsoft Entra-id.

Meer aanbevelingen:

  • Gebruik beleidsregels in API Management om de beveiliging te verbeteren. Als de oproepsnelheid bijvoorbeeld wordt beperkt, worden slechte actoren vertraagd met behulp van brute force-aanvallen om referenties te compromitteren.

  • API's moeten TLS/SSL (transportbeveiliging) gebruiken om de referenties of tokens te beveiligen. Referenties en tokens moeten worden verzonden in aanvraagheaders en niet als queryparameters.

  • Configureer in de API Management-ontwikkelaarsportal Microsoft Entra ID of Azure Active Directory B2C als id-provider om de accountbeveiliging te verhogen. De ontwikkelaarsportal maakt gebruik van CAPTCHA om beveiligingsaanvallen te beperken.

Overmatige blootstelling aan gegevens

Het ontwerp van een goede API-interface is misleidend lastig. Met name bij verouderde API's die in de loop van de tijd zijn ontwikkeld, bevatten de aanvraag- en antwoordinterfaces meer gegevensvelden dan de verbruikende toepassingen vereisen.

Een slechte actor kan proberen om rechtstreeks toegang te krijgen tot de API (mogelijk door een geldige aanvraag opnieuw af te spelen) of het verkeer tussen de server en de API te snuiven. Analyse van de API-acties en de beschikbare gegevens kan gevoelige gegevens opleveren voor de aanvaller, die niet wordt weergegeven of gebruikt door de front-endtoepassing.

Meer informatie over deze bedreiging: API3:2019 Overmatige blootstelling aan gegevens

Aanbevelingen

  • De beste aanpak om dit beveiligingsprobleem te beperken, is ervoor te zorgen dat de externe interfaces die zijn gedefinieerd in de back-end-API zorgvuldig en idealiter onafhankelijk van de persistentie van gegevens worden ontworpen. Ze mogen alleen de velden bevatten die vereist zijn voor gebruikers van de API. API's moeten regelmatig worden gecontroleerd en verouderde velden worden afgeschaft en vervolgens worden verwijderd.

    Gebruik in API Management:

    • Revisies om niet-brekende wijzigingen correct te beheren, bijvoorbeeld de toevoeging van een veld aan een interface. U kunt revisies gebruiken, samen met een versiebeheer-implementatie in de back-end.

    • Versies voor wijzigingen die fouten veroorzaken, bijvoorbeeld het verwijderen van een veld uit een interface.

  • Als het niet mogelijk is om het ontwerp van de back-endinterface en overmatige gegevens te wijzigen, gebruikt u API Management-transformatiebeleid om nettoladingen van reacties te herschrijven en gegevens te maskeren of te filteren. Verwijder bijvoorbeeld overbodige JSON-eigenschappen uit een antwoordtekst.

  • Validatie van antwoordinhoud in API Management kan worden gebruikt met een XML- of JSON-schema om antwoorden met niet-gedocumenteerde eigenschappen of onjuiste waarden te blokkeren. Het beleid ondersteunt ook blokkerende antwoorden die een opgegeven grootte overschrijden.

  • Gebruik het beleid voor statuscode valideren om reacties te blokkeren met fouten die niet zijn gedefinieerd in het API-schema.

  • Gebruik het beleid voor het valideren van headers om antwoorden te blokkeren met headers die niet zijn gedefinieerd in het schema of om niet te voldoen aan hun definitie in het schema. Verwijder ongewenste headers met het setheaderbeleid .

  • Gebruik voor GraphQL-scenario's het beleid voor GraphQL-aanvragen valideren om GraphQL-aanvragen te valideren, toegang te verlenen tot specifieke querypaden en de antwoordgrootte te beperken.

Gebrek aan resources en snelheidsbeperking

Het ontbreken van frequentiebeperking kan leiden tot gegevensexfiltratie of geslaagde DDoS-aanvallen op back-endservices, waardoor er een storing optreedt voor alle consumenten.

Meer informatie over deze bedreiging: API4:2019 Gebrek aan resources en frequentiebeperking

Aanbevelingen

  • Gebruik beleidsregels voor frequentielimiet (korte termijn) en quotumlimiet (lange termijn) om het toegestane aantal API-aanroepen of bandbreedte per consument te beheren.

  • Definieer strikte aanvraagobjectdefinities en de bijbehorende eigenschappen in de OpenAPI-definitie. Definieer bijvoorbeeld de maximumwaarde voor pagginerende gehele getallen, maxLength en reguliere expressie (regex) voor tekenreeksen. Dwing deze schema's af met het valideren van inhoud en valideer parametersbeleid in API Management.

  • Dwing de maximale grootte van de aanvraag af met het inhoudsbeleid valideren.

  • Optimaliseer de prestaties met ingebouwde caching, waardoor het verbruik van CPU-, geheugen- en netwerkresources voor bepaalde bewerkingen wordt verminderd.

  • Verificatie afdwingen voor API-aanroepen (zie Verbroken gebruikersverificatie). Toegang intrekken voor beledigende gebruikers. U kunt bijvoorbeeld de abonnementssleutel deactiveren, het IP-adres blokkeren met het beleid voor ip-adressen van bellers beperken of aanvragen voor een bepaalde gebruikersclaim weigeren vanuit een JWT-token.

  • Pas een CORS-beleid toe om de websites te beheren die de resources mogen laden die via de API worden geleverd. Gebruik geen jokertekenwaarden (*) in het CORS-beleid om overmissieve configuraties te voorkomen.

  • Minimaliseer de tijd die een back-endservice nodig heeft om te reageren. Hoe langer de back-endservice nodig heeft om te reageren, hoe langer de verbinding in API Management wordt gebruikt, waardoor het aantal aanvragen dat in een bepaalde periode kan worden verwerkt, wordt verminderd.

  • Hoewel API Management back-endservices kan beschermen tegen DDoS-aanvallen, is het mogelijk kwetsbaar voor deze aanvallen zelf. Implementeer een botbeveiligingsservice vóór API Management (bijvoorbeeld Azure-toepassing Gateway, Azure Front Door of Azure DDoS Protection) om beter te beschermen tegen DDoS-aanvallen. Wanneer u een WAF met Azure-toepassing Gateway of Azure Front Door gebruikt, kunt u overwegen om Microsoft_BotManagerRuleSet_1.0 te gebruiken.

Autorisatie op functieniveau verbroken

Complexe beleidsregels voor toegangsbeheer met verschillende hiërarchieën, groepen en rollen, en een onduidelijke scheiding tussen beheer- en reguliere functies leiden tot autorisatiefouten. Door deze problemen te misbruiken, krijgen aanvallers toegang tot resources of beheerfuncties van andere gebruikers.

Meer informatie over deze bedreiging: AUTORISATIE op gebroken functieniveau API5:2019

Aanbevelingen

  • Beveilig standaard alle API-eindpunten in API Management met abonnementssleutels.

  • Definieer een JWT-beleid valideren en dwing vereiste tokenclaims af. Als voor bepaalde bewerkingen strengere handhaving van claims is vereist, definieert u alleen extra validate-jwt beleidsregels voor deze bewerkingen.

  • Gebruik een virtueel Azure-netwerk of Private Link om API-eindpunten van internet te verbergen. Meer informatie over opties voor virtuele netwerken met API Management.

  • Definieer geen API-bewerkingen met jokertekens (dat wil gezegd 'catch-all'-API's met * als pad). Zorg ervoor dat API Management alleen aanvragen verwerkt voor expliciet gedefinieerde eindpunten en dat aanvragen voor niet-gedefinieerde eindpunten worden geweigerd.

  • Publiceer GEEN API's met open producten waarvoor geen abonnement is vereist.

Massatoewijzing

Als een API meer velden biedt dan de client vereist voor een bepaalde actie, kan een aanvaller overmatige eigenschappen injecteren om onbevoegde bewerkingen uit te voeren op gegevens. Aanvallers kunnen niet-gedocumenteerde eigenschappen detecteren door de indeling van aanvragen en antwoorden of andere API's te inspecteren of door ze te raden. Dit beveiligingsprobleem is met name van toepassing als u geen sterk getypte programmeertalen gebruikt.

Meer informatie over deze bedreiging: API6:2019 Massatoewijzing

Aanbevelingen

  • Externe API-interfaces moeten worden losgekoppeld van de interne gegevensimplementatie. Vermijd het rechtstreeks binden van API-contracten aan gegevenscontracten in back-endservices. Controleer regelmatig het API-ontwerp en verwijder verouderde eigenschappen met behulp van versiebeheer in API Management.

  • Definieer XML- en JSON-contracten nauwkeurig in het API-schema en gebruik inhoud valideren en parametersbeleid valideren om aanvragen en antwoorden met niet-gedocumenteerde eigenschappen te blokkeren. Het blokkeren van aanvragen met niet-gedocumenteerde eigenschappen beperkt aanvallen, terwijl het blokkeren van reacties met niet-gedocumenteerde eigenschappen het moeilijker maakt om potentiële aanvalsvectoren omkeren.

  • Als de back-endinterface niet kan worden gewijzigd, gebruikt u transformatiebeleid om nettoladingen van aanvragen en antwoorden te herschrijven en de API-contracten los te koppelen van back-endcontracten. U kunt bijvoorbeeld gegevens maskeren of filteren of overbodige JSON-eigenschappen verwijderen.

Onjuiste configuratie van beveiliging

Aanvallers kunnen proberen misbruik te maken van beveiligingsproblemen met onjuiste configuratie, zoals:

  • Beveiligingsbeveiliging ontbreekt
  • Onnodige ingeschakelde functies
  • Netwerkverbindingen onnodig openstaan voor internet
  • Gebruik van zwakke protocollen of coderingen
  • Andere instellingen of eindpunten die onbevoegde toegang tot het systeem toestaan

Meer informatie over deze bedreiging: ONJUISTE configuratie van API7:2019-beveiliging

Aanbevelingen

  • Configureer gateway TLS correct. Gebruik geen kwetsbare protocollen (bijvoorbeeld TLS 1.0, 1.1) of coderingen.

  • Configureer API's om alleen versleuteld verkeer te accepteren, bijvoorbeeld via HTTPS- of WSS-protocollen.

  • Overweeg API Management te implementeren achter een privé-eindpunt of gekoppeld aan een virtueel netwerk dat is geïmplementeerd in de interne modus. In interne netwerken kan de toegang worden beheerd vanuit het particuliere netwerk (via firewall of netwerkbeveiligingsgroepen) en via internet (via een omgekeerde proxy).

  • Azure API Management-beleid gebruiken:

    • Neem altijd bovenliggende beleidsregels over via de <base> tag.

    • Wanneer u OAuth 2.0 gebruikt, configureert en test u het JWT-beleid valideren om het bestaan en de geldigheid van het JWT-token te controleren voordat het de back-end bereikt. Controleer automatisch de verlooptijd van het token, de tokenhandtekening en de verlener. Dwing claims, doelgroepen, verloop van tokens en tokenhandtekening af via beleidsinstellingen.

    • Configureer het CORS-beleid en gebruik geen jokertekens * voor een configuratieoptie. Geef in plaats daarvan expliciet toegestane waarden weer.

    • Stel validatiebeleidprevent in op in productieomgevingen om JSON- en XML-schema's, headers, queryparameters en statuscodes te valideren en om de maximale grootte voor aanvraag of antwoord af te dwingen.

    • Als API Management zich buiten een netwerkgrens bevindt, is validatie van client-IP-adressen nog steeds mogelijk met behulp van het ip-beleid van de beller beperken. Zorg ervoor dat er een acceptatielijst wordt gebruikt, niet een bloklijst.

    • Als clientcertificaten worden gebruikt tussen aanroeper en API Management, gebruikt u het beleid voor clientcertificaten valideren. Zorg ervoor dat de validate-revocationkenmerken , validate-trusten validate-not-aftervalidate-not-beforekenmerken zijn ingesteld op true.

      • Clientcertificaten (wederzijdse TLS) kunnen ook worden toegepast tussen API Management en de back-end. De back-end moet:

        • Autorisatiereferenties configureren

        • De certificaatketen waar van toepassing valideren

        • De certificaatnaam valideren indien van toepassing

  • Gebruik voor GraphQL-scenario's het beleid voor Het valideren van GraphQL-aanvragen . Zorg ervoor dat het element en max-size de authorizationmax-depth kenmerken zijn ingesteld.

  • Sla geen geheimen op in beleidsbestanden of in broncodebeheer. Gebruik altijd benoemde waarden van API Management of haal de geheimen tijdens runtime op met behulp van aangepaste beleidsexpressies.

    • Benoemde waarden moeten worden geïntegreerd met Key Vault of versleuteld in API Management door ze 'geheim' te markeren. Sla geheimen nooit op in benoemde waarden zonder opmaak.

  • Publiceer API's via producten waarvoor abonnementen zijn vereist. Gebruik geen open producten waarvoor geen abonnement is vereist.

  • Gebruik Key Vault-integratie om alle certificaten te beheren. Dit centraliseert het certificaatbeheer en kan helpen bij het vereenvoudigen van beheertaken voor bewerkingen, zoals het vernieuwen of intrekken van certificaten.

  • Wanneer u de zelf-hostende gateway gebruikt, moet u ervoor zorgen dat er een proces is om de installatiekopie periodiek bij te werken naar de nieuwste versie.

  • Back-endservices vertegenwoordigen als back-endentiteiten. Configureer waar van toepassing autorisatiereferenties, validatie van certificaatketens en validatie van certificaatnamen.

  • Wanneer u de ontwikkelaarsportal gebruikt:

    • Als u ervoor kiest om de ontwikkelaarsportal zelf te hosten , moet u ervoor zorgen dat er een proces is om de zelf-hostende portal periodiek bij te werken naar de nieuwste versie. Updates voor de standaard beheerde versie zijn automatisch.

    • Gebruik Microsoft Entra ID of Azure Active Directory B2C voor gebruikersaanmelding en -aanmelding. Schakel de standaardverificatie voor gebruikersnaam en wachtwoord uit, wat minder veilig is.

    • Wijs gebruikersgroepen toe aan producten om de zichtbaarheid van API's in de portal te beheren.

  • Gebruik Azure Policy om configuraties en RBAC-machtigingen (op rollen gebaseerd toegangsbeheer) op API Management-resourceniveau af te dwingen om de toegang tot resources te beheren. Ververleent minimaal vereiste bevoegdheden aan elke gebruiker.

  • Gebruik een DevOps-proces - en infrastructuur-as-codebenadering buiten een ontwikkelomgeving om consistentie van API Management-inhoud en configuratiewijzigingen te garanderen en menselijke fouten te minimaliseren.

  • Gebruik geen afgeschafte functies.

Injectie

Elk eindpunt dat gebruikersgegevens accepteert, is mogelijk kwetsbaar voor misbruik van injectie. Voorbeelden zijn onder andere, maar zijn niet beperkt tot:

  • Opdrachtinjectie, waarbij een slechte actor probeert de API-aanvraag te wijzigen om opdrachten uit te voeren op het besturingssysteem dat als host fungeert voor de API

  • SQL-injectie, waarbij een ongeldige actor probeert de API-aanvraag te wijzigen om opdrachten en query's uit te voeren op de database, is een API afhankelijk van

Meer informatie over deze bedreiging: API8:2019 Injectie

Aanbevelingen

  • Moderne WAF-beleidsregels (Web Application Firewall) hebben betrekking op veel veelvoorkomende beveiligingsproblemen met injecties. Hoewel API Management geen ingebouwd WAF-onderdeel heeft, wordt het implementeren van een WAF upstream (vóór) van het API Management-exemplaar sterk aanbevolen. Gebruik bijvoorbeeld Azure-toepassing Gateway of Azure Front Door.

    Belangrijk

    Zorg ervoor dat een slechte actor de gateway die als host fungeert voor de WAF niet kan omzeilen en rechtstreeks verbinding kan maken met de API Management-gateway of back-end-API zelf. Mogelijke oplossingen zijn: netwerk-ACL's, het gebruik van API Management-beleid om inkomend verkeer per client-IP te beperken, openbare toegang te verwijderen, indien niet vereist, en verificatie van clientcertificaten (ook wel wederzijdse TLS of mTLS genoemd).

  • Gebruik schema- en parametervalidatiebeleid, indien van toepassing, om de aanvraag verder te beperken en te valideren voordat deze de back-end-API-service bereikt.

    Het schema dat wordt geleverd met de API-definitie, moet een regex-patroonbeperking hebben die is toegepast op kwetsbare velden. Elke regex moet worden getest om ervoor te zorgen dat het veld voldoende beperkt om veelvoorkomende injectiepogingen te beperken.

Onjuist activabeheer

Beveiligingsproblemen met betrekking tot onjuist activabeheer zijn onder andere:

  • Gebrek aan juiste API-documentatie of eigendomsgegevens

  • Overmatige aantallen oudere API-versies, waarvoor mogelijk beveiligingsoplossingen ontbreken

Meer informatie over deze bedreiging: API9:2019 Onjuist activabeheer

Aanbevelingen

  • Gebruik een goed gedefinieerde OpenAPI-specificatie als bron voor het importeren van REST API's. De specificatie maakt inkapseling van de API-definitie mogelijk, inclusief metagegevens voor zelfdocumentatie.

    • Api-interfaces gebruiken met nauwkeurige paden, gegevensschema's, headers, queryparameters en statuscodes. Vermijd jokertekenbewerkingen. Geef beschrijvingen op voor elke API en elke bewerking en neem contact- en licentiegegevens op.

    • Vermijd eindpunten die niet rechtstreeks bijdragen aan de bedrijfsdoelstelling. Ze vergroten het kwetsbaarheid voor aanvallen onnodig en maken het moeilijker om de API te ontwikkelen.

  • Gebruik revisies en versies in API Management om de API-eindpunten te beheren en te beheren. Een sterke strategie voor back-endversies en doorvoeren naar een maximum aantal ondersteunde API-versies (bijvoorbeeld 2 of 3 eerdere versies). Plan om oudere, vaak minder veilige API-versies snel te verwijderen en uiteindelijk te verwijderen.

  • Gebruik een API Management-exemplaar per omgeving (zoals ontwikkeling, test en productie). Zorg ervoor dat elk API Management-exemplaar verbinding maakt met de bijbehorende afhankelijkheden in dezelfde omgeving. In de testomgeving moet de test-API Management-resource bijvoorbeeld verbinding maken met een Azure Key Vault-testresource en de testversies van back-endservices. Gebruik DevOps-automatisering en procedures voor infrastructuur als code om consistentie en nauwkeurigheid tussen omgevingen te behouden en menselijke fouten te verminderen.

  • Gebruik tags om API's en producten te organiseren en deze te groeperen voor publicatie.

  • Publiceer API's voor gebruik via de ingebouwde ontwikkelaarsportal. Zorg ervoor dat de API-documentatie up-to-date is.

  • Ontdek niet-gedocumenteerde of onbeheerde API's en maak deze beschikbaar via API Management voor betere controle.

Onvoldoende logboekregistratie en bewaking

Met onvoldoende logboekregistratie en bewaking, in combinatie met ontbrekende of ineffectieve integratie met incidentrespons, kunnen aanvallers verdere aanvalssystemen uitvoeren, persistentie behouden, draaien naar meer systemen om gegevens te knoeien en te extraheren of te vernietigen. De meeste inbreukstudies tonen aan dat de tijd voor het detecteren van een inbreuk meer dan 200 dagen is, meestal gedetecteerd door externe partijen in plaats van interne processen of bewaking.

Meer informatie over deze bedreiging: API10:2019 Onvoldoende logboekregistratie en bewaking

Aanbevelingen

Volgende stappen

Meer informatie over: