Aanbevelingen voor het beperken van OWASP API Security Top 10-bedreigingen met behulp van API Management

  • Artikel

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

Het OWASP API-beveiligingsproject 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 door OWASP zijn geïdentificeerd.

Notitie

Naast het volgen van de aanbevelingen in dit artikel kunt u Defender voor API's (preview) inschakelen, een mogelijkheid van Microsoft Defender voor cloud, voor API-beveiligings insights, 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 met een geheel getal, die kan worden ge itereerd.

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

Aanbevelingen

  • De beste plaats voor het implementeren van autorisatie op objectniveau is binnen de back-end-API zelf. Op 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. Overweeg scenario's waarin 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 op de back-end, kan API Management worden gebruikt als een terugval. Bijvoorbeeld:

    • 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 van aanvraag aan back-end en van back-end aan client toe te wijzen, zodat interne id's niet zichtbaar zijn.

      In deze gevallen kan het aangepaste beleid een beleidsexpressie zijn met een zoekactie (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 beleid graphQL-aanvraag valideren met behulp van het authorize -element.

Verbroken gebruikersverificatie

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

Meer informatie over deze bedreiging: API2:2019 Verbroken gebruikersverificatie

Aanbevelingen

Gebruik API Management 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 voldoende. Als de abonnementssleutel is aangetast, kan een aanvaller onbeperkte toegang tot het systeem krijgen.

    • Beleid voor clientcertificaten : het gebruik van clientcertificaten is veiliger dan basisreferenties of abonnementssleutel, maar biedt niet de flexibiliteit die wordt geboden door autorisatieprotocollen op basis van tokens, zoals OAuth 2.0.

  • Autorisatie: API Management ondersteunt een JWT-beleid valideren om de geldigheid van een binnenkomend OAuth 2.0 JWT-toegangstoken te controleren op basis van informatie die is verkregen van het eindpunt voor metagegevens 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 Azure Active Directory.

Meer aanbevelingen:

  • Gebruik toegangsbeperkingsbeleid in API Management om de beveiliging te verbeteren. Het beperken van de aanroepsnelheid vertraagt bijvoorbeeld slechte actoren die beveiligingsaanvallen gebruiken 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 ontwikkelaarsportalAzure Active Directory 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

Goed API-interfaceontwerp is misleidend lastig. Met name bij verouderde API's die in de loop van de tijd zijn ontwikkeld, bevatten de aanvraag- en antwoordinterfaces vaak meer gegevensvelden dan de verbruikende toepassingen vereisen.

Een slechte actor kan proberen rechtstreeks toegang te krijgen tot de API (mogelijk door een geldige aanvraag opnieuw af te spelen) of het verkeer tussen server en API te snuffelen. Analyse van de API-acties en de beschikbare gegevens kan gevoelige gegevens opleveren voor de aanvaller, die niet worden 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 gegevenspersistentie worden ontworpen. Ze mogen alleen de velden bevatten die zijn vereist door gebruikers van de API. API's moeten regelmatig worden gecontroleerd en verouderde velden moeten worden afgeschaft en vervolgens worden verwijderd.

    Gebruik in API Management:

    • Revisies voor het afhandelen van vaste wijzigingen, bijvoorbeeld het toevoegen van een veld aan een interface. U kunt revisies gebruiken in combinatie met een versiebeheer-implementatie op 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 te wijzigen en overmatige gegevens een probleem zijn, 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 het blokkeren van antwoorden die een opgegeven grootte overschrijden.

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

  • Gebruik het beleid headers valideren om antwoorden te blokkeren met headers die niet zijn gedefinieerd in het schema of die niet voldoen aan de definitie in het schema. Verwijder ongewenste headers met het ingestelde headerbeleid .

  • Voor GraphQL-scenario's gebruikt u het beleid GraphQL-aanvraag valideren om GraphQL-aanvragen te valideren, toegang tot specifieke querypaden te autoriseren en de antwoordgrootte te beperken.

Gebrek aan resources en snelheidsbeperking

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

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

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 het pagiëren van gehele getallen, maxLength en reguliere expressie (regex) voor tekenreeksen. Dwing deze schema's af met het beleid inhoud valideren en parameters valideren in API Management.

  • Dwing de maximale grootte van de aanvraag af met het beleid voor het valideren van inhoud .

  • 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. Deactiveer bijvoorbeeld de abonnementssleutel, blokkeer het IP-adres met het beleid voor het beperken van aanroeper-IP's of weiger aanvragen voor een bepaalde gebruikersclaim van een JWT-token.

  • Pas een CORS-beleid toe om de websites te beheren die de resources mogen laden die via de API worden geleverd. Als u te tolerante configuraties wilt voorkomen, gebruikt u geen jokertekenwaarden (*) in het CORS-beleid.

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

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

Autorisatie op functieniveau verbroken

Complex toegangsbeheerbeleid met verschillende hiërarchieën, groepen en rollen en een onduidelijke scheiding tussen administratieve en reguliere functies leiden tot autorisatiefouten. Door deze problemen te misbruiken, krijgen aanvallers toegang tot de resources of beheerfuncties van andere gebruikers.

Meer informatie over deze bedreiging: API5:2019 Autorisatie op verbroken functieniveau

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 afdwinging 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 virtuele netwerkopties 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 voor expliciet gedefinieerde eindpunten verwerkt 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 nodig heeft voor een bepaalde actie, kan een aanvaller overmatige eigenschappen injecteren om niet-geautoriseerde bewerkingen op gegevens uit te voeren. Aanvallers kunnen niet-gedocumenteerde eigenschappen detecteren door de indeling van aanvragen en antwoorden of andere API's te inspecteren of te raden. Dit beveiligingsprobleem is vooral 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 het beleid voor het valideren van inhoud en het valideren van parameters om aanvragen en antwoorden met niet-gedocumenteerde eigenschappen te blokkeren. Het blokkeren van aanvragen met niet-gedocumenteerde eigenschappen vermindert aanvallen, terwijl het blokkeren van reacties met niet-gedocumenteerde eigenschappen het moeilijker maakt om potentiële aanvalsvectoren reverse-engineeren.

  • Als de back-endinterface niet kan worden gewijzigd, gebruikt u transformatiebeleidsregels 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:

  • Ontbrekende beveiligingsbeveiliging
  • Overbodige ingeschakelde functies
  • Netwerkverbindingen worden onnodig geopend op internet
  • Gebruik van zwakke protocollen of coderingen
  • Andere instellingen of eindpunten die onbevoegde toegang tot het systeem mogelijk maken

Meer informatie over deze bedreiging: API7:2019 Onjuiste configuratie van 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 om 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 firewalls of netwerkbeveiligingsgroepen) en via internet (via een omgekeerde proxy).

  • Azure API Management-beleid gebruiken:

    • Neem bovenliggend beleid altijd over via de <base> tag.

    • Wanneer u OAuth 2.0 gebruikt, configureert en test u het JWT-beleid valideren om de aanwezigheid en 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. Claims, doelgroepen, het verlopen van tokens en tokenhandtekening afdwingen via beleidsinstellingen.

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

    • Stel validatiebeleid in op prevent 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 client-IP-validatie nog steeds mogelijk met behulp van het beleid voor het beperken van ip-adressen voor oproepen. Zorg ervoor dat er een acceptatielijst wordt gebruikt, geen blokkeringslijst.

    • Als clientcertificaten worden gebruikt tussen aanroeper en API Management, gebruikt u het beleid clientcertificaat valideren. Zorg ervoor dat de validate-revocationkenmerken , validate-trust, validate-not-beforeen validate-not-after allemaal 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 valideren, indien van toepassing

        • De certificaatnaam valideren, indien van toepassing

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

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

    • Benoemde waarden moeten worden geïntegreerd met Key Vault of worden versleuteld in API Management door ze als 'geheim' te markeren. Sla geheimen nooit op in benoemde waarden in tekst 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 operationele beheertaken, 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 regelmatig bij te werken naar de nieuwste versie.

  • Back-endservices vertegenwoordigen als back-endentiteiten. Configureer autorisatiereferenties, certificaatketenvalidatie en certificaatnaamvalidatie, indien van toepassing.

  • 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 regelmatig bij te werken naar de nieuwste versie. Updates voor de standaard beheerde versie zijn automatisch.

    • Gebruik Azure Active Directory (Azure AD) of Azure Active Directory B2C voor het registreren en aanmelden van gebruikers. 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 API Management machtigingen voor configuratie op resourceniveau en op rollen gebaseerd toegangsbeheer (RBAC) af te dwingen om toegang tot resources te beheren. Wijs minimaal vereiste bevoegdheden toe aan elke gebruiker.

  • Gebruik een DevOps-proces en infrastructuur-als-code-benadering 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 injecties. Voorbeelden zijn, maar zijn niet beperkt tot:

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

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

Meer informatie over deze bedreiging: API8:2019-injectie

Aanbevelingen

  • Waf-beleid (Modern Web Application Firewall) dekt veel veelvoorkomende beveiligingsproblemen met injecties. Hoewel API Management geen ingebouwd WAF-onderdeel heeft, wordt het sterk aanbevolen om een WAF upstream (vóór) het API Management-exemplaar te implementeren. Gebruik bijvoorbeeld Azure Application 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 binnenkomend verkeer te beperken via client-IP, het verwijderen van openbare toegang waar niet vereist, en verificatie van clientcertificaten (ook wel bekend als wederzijdse TLS of mTLS).

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

    Voor het schema dat bij de API-definitie wordt geleverd, moet een regex-patroonbeperking worden 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 beveiligingspatches 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 zelfdocumenterende metagegevens.

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

    • Vermijd eindpunten die niet rechtstreeks bijdragen aan de bedrijfsdoelstelling. Ze vergroten onnodig de kwetsbaarheid voor aanvallen 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-endversiebeheer hebben en een maximum aantal ondersteunde API-versies doorvoeren (bijvoorbeeld 2 of 3 eerdere versies). Plan om oudere, vaak minder veilige, API-versies snel af te heffen 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 testresource van Azure Key Vault 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 ordenen en te groeperen voor publicatie.

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

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

Onvoldoende logboekregistratie en bewaking

Onvoldoende logboekregistratie en bewaking, in combinatie met ontbrekende of ineffectieve integratie met incidentrespons, stelt aanvallers in staat om systemen verder aan te vallen, persistentie te behouden, meer systemen te gebruiken om mee te knoeien en gegevens te extraheren of te vernietigen. De meeste inbreukonderzoeken tonen aan dat de tijd voor het detecteren van een inbreuk langer is dan 200 dagen, meestal gedetecteerd door externe partijen in plaats van door interne processen of bewaking.

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

Aanbevelingen

Volgende stappen

Meer informatie over: