Delen via

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

  • Artikel

VAN TOEPASSING OP: Alle API Management-lagen

Notitie

Dit artikel is bijgewerkt met de nieuwste OWASP API Security Top 10-lijst voor 2023.

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 de meest recente aanbevelingen om de tien belangrijkste API-bedreigingen te beperken die zijn geïdentificeerd door OWASP in hun lijst met 2023 met behulp van Azure API Management.

Hoewel API Management uitgebreide besturingselementen biedt voor API-beveiliging, bieden andere Microsoft-services aanvullende functionaliteit om OWASP API-bedreigingen te detecteren of te beveiligen:

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:2023 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 deze gevallen kan het aangepaste beleid een beleidsexpressie zijn met een opzoekactie (bijvoorbeeld een woordenlijst) of integratie met een andere service via het beleid voor verzenden-aanvragen .

  • Voor GraphQL-scenario's dwingt u autorisatie op objectniveau af via het beleid validate-graphql-request met behulp van het authorize element.

Verbroken verificatie

Het verificatiemechanisme voor een site of API is met name kwetsbaar omdat het toegankelijk is voor anonieme gebruikers. Assets en eindpunten die vereist zijn voor verificatie, waaronder vergeten wachtwoord- of wachtwoordstromen opnieuw instellen, moeten worden beveiligd om misbruik te voorkomen.

Meer informatie over deze bedreiging: API2:2023 Verbroken verificatie

Aanbevelingen

Autorisatie op objectniveau verbroken

Het ontwerp van een goede API-interface is misleidend lastig. Met name met verouderde API's die na verloop van tijd zijn ontwikkeld, bevatten de aanvraag- en antwoordinterfaces vaak meer gegevensvelden dan de verbruikende toepassingen vereisen, waardoor aanvallen voor gegevensinjectie mogelijk zijn. Aanvallers kunnen ook niet-gedocumenteerde interfaces detecteren. Deze beveiligingsproblemen kunnen gevoelige gegevens opleveren voor de aanvaller.

Meer informatie over deze bedreiging: AUTORISATIE op eigenschapsniveau API3:2023 Broken Object

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 het toevoegen van een veld aan een interface en versies om belangrijke wijzigingen te implementeren. U moet ook back-endinterfaces versien, die doorgaans een andere levenscyclus hebben dan consumenten-API's.
  • Externe API-interfaces loskoppelen van de interne gegevensimplementatie. Vermijd het rechtstreeks binden van API-contracten aan gegevenscontracten in back-endservices.
  • 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. Inhoudsvalidatie in API Management kan worden gebruikt met een XML- of JSON-schema om antwoorden met niet-gedocumenteerde eigenschappen of onjuiste waarden te blokkeren. Verwijder bijvoorbeeld overbodige JSON-eigenschappen uit een antwoordtekst. 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. Het beleid voor validatie-inhoud ondersteunt ook het blokkeren van antwoorden die een opgegeven grootte overschrijden.
  • Gebruik het beleid voor validatiestatuscode om reacties te blokkeren met fouten die niet zijn gedefinieerd in het API-schema.
  • Gebruik het beleid voor validatieheaders om antwoorden te blokkeren met headers die niet in het schema zijn gedefinieerd of niet voldoen aan hun definitie in het schema. Verwijder ongewenste headers met het set-headerbeleid .
  • Voor GraphQL-scenario's gebruikt u het beleid validate-graphql-request om GraphQL-aanvragen te valideren, toegang te verlenen tot specifieke querypaden en de antwoordgrootte te beperken.

Onbeperkt resourceverbruik

Api's vereisen dat resources worden uitgevoerd, zoals geheugen of CPU, en kunnen downstreamintegraties bevatten die een operationele kosten vertegenwoordigen (bijvoorbeeld services voor betalen per aanvraag). Het toepassen van limieten kan helpen API's te beschermen tegen overmatig resourceverbruik.

Meer informatie over deze bedreiging: API4:2023 Onbeperkt resourceverbruik

Aanbevelingen

  • Gebruik beleid voor frequentielimiet per sleutel of frequentielimiet om beperking toe te passen op kortere tijdvensters. Pas strenger beleid voor snelheidsbeperking toe op gevoelige eindpunten, zoals wachtwoordherstel, aanmelding of registratiebewerkingen of eindpunten die aanzienlijke resources verbruiken.
  • Gebruik quota per sleutel - of quotumlimietbeleid om het toegestane aantal API-aanroepen of bandbreedte voor langere tijdsframes te beheren.
  • Optimaliseer de prestaties met ingebouwde caching, waardoor het verbruik van CPU-, geheugen- en netwerkresources voor bepaalde bewerkingen wordt verminderd.
  • Validatiebeleid toepassen.
  • Voor generatieve AI-API's:
    • Gebruik semantische caching om de belasting van de back-ends te verminderen.
    • Gebruik tokenbeperking om het verbruik en de kosten te beheren.
    • Metrische gegevens over tokenverbruik verzenden om het tokengebruik te bewaken en waarschuwingen te configureren.
  • 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 bepaald tijdsbestek kan worden verwerkt, wordt verminderd.
  • 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.
  • Hoewel Azure zowel beveiliging op platformniveau als verbeterde beveiliging tegen DDoS-aanvallen (Gedistribueerde Denial of Service) heeft, kan de beveiliging van toepassingen (laag 7) voor API's worden verbeterd door een botbeveiligingsservice te implementeren vóór API Management, bijvoorbeeld Azure-toepassing Gateway, Azure Front Door of Azure DDoS Protection. Wanneer u een WAF-beleid (Web Application Firewall) gebruikt met Azure-toepassing Gateway of Azure Front Door, 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:2023

Aanbevelingen

  • Beveilig standaard alle API-eindpunten in API Management met abonnementssleutels of autorisatiebeleid op basis van alle API's. Definieer indien van toepassing andere autorisatiebeleidsregels voor specifieke API's of API-bewerkingen.
  • OAuth-tokens valideren met behulp van beleid.
    • Gebruik validate-azure-ad-tokenbeleid om Microsoft Entra-tokens te valideren. Geef alle vereiste claims op en geef, indien van toepassing, geautoriseerde toepassingen op.
    • Voor het valideren van tokens die niet zijn uitgegeven door Microsoft Entra, definieert u een validatie-jwt-beleid en dwingt u vereiste tokenclaims af. Indien mogelijk moet u verlooptijd vereisen.
    • Gebruik indien mogelijk versleutelde tokens of vermeld specifieke toepassingen voor toegang.
    • Aanvragen bewaken en controleren die zijn geweigerd vanwege een gebrek aan autorisatie.
  • 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.
  • Als client-IP-adressen bekend zijn, gebruikt u een ip-filterbeleid om alleen verkeer van geautoriseerde IP-adressen toe te staan.
  • Gebruik het beleid validate-client-certificate om af te dwingen dat een certificaat dat door een client aan een API Management-exemplaar wordt gepresenteerd, overeenkomt met de opgegeven validatieregels en claims.

Onbeperkte toegang tot gevoelige bedrijfsstromen

API's kunnen een breed scala aan functionaliteit beschikbaar maken voor de verbruikende toepassing. Het is belangrijk voor API-auteurs om inzicht te hebben in de bedrijfsstromen die de API biedt en de bijbehorende gevoeligheid. Er is een groter risico voor het bedrijf als API's die gevoelige stromen blootstellen, geen geschikte beveiligingen implementeren.

Meer informatie over deze bedreiging: API6:2023 Onbeperkte toegang tot gevoelige bedrijfsstromen

Aanbevelingen

  • Toegang beperken of blokkeren op basis van clientvingerafdruk. Gebruik bijvoorbeeld het retourantwoordbeleid met het beleid kiezen om verkeer van hoofdloze browsers te blokkeren op basis van de header user-agent of consistentie van andere headers.
  • Gebruik beleid voor validatieparameters om af te dwingen dat aanvraagheaders overeenkomen met de API-specificatie.
  • Gebruik ip-filterbeleid om alleen aanvragen van bekende IP-adressen toe te staan of toegang van specifieke IP-adressen te weigeren.
  • Gebruik privénetwerkfuncties om externe connectiviteit met interne API's te beperken.
  • Gebruik beleid voor frequentielimiet per sleutel om pieken in API-verbruik te beperken op basis van gebruikersidentiteit, IP-adres of een andere waarde.
  • Front API Management met Azure-toepassing Gateway of Azure DDoS Protection-service om botverkeer te detecteren en te blokkeren.

Aanvraagvervalsing aan serverzijde

Een aanvraagvervalsing aan de serverzijde kan optreden wanneer de API een downstreamresource ophaalt op basis van de waarde van een URL die is doorgegeven door de API-aanroeper zonder de juiste validatiecontroles.

Meer informatie over deze bedreiging: API7:2023 Aanvraagvervalsing aan serverzijde

Aanbevelingen

  • Gebruik indien mogelijk geen URL's die zijn opgegeven in de nettoladingen van de client, bijvoorbeeld als parameters voor back-end-URL's, beleid voor verzenden-aanvragen of herschrijf-URL-beleid .
  • Als API Management- of back-endservices URL's gebruiken die worden geleverd in de nettolading van aanvragen voor bedrijfslogica, definieert en afdwingt u een beperkte lijst met hostnamen, poorten, mediatypen of andere kenmerken met beleidsregels in API Management, zoals het kiezen van beleid en beleidsexpressies.
  • Definieer het timeout kenmerk in het beleid voor forward-request en send-request .
  • Aanvraag- en antwoordgegevens valideren en opschonen met validatiebeleid. Gebruik indien nodig het setbody-beleid om het antwoord te verwerken en te voorkomen dat onbewerkte gegevens worden geretourneerd.
  • Gebruik privénetwerken om de connectiviteit te beperken. Als de API bijvoorbeeld niet openbaar hoeft te zijn, beperkt u de connectiviteit van internet om de kwetsbaarheid voor aanvallen te verminderen.

Onjuiste configuratie van beveiliging

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

  • Beveiligingsbeveiliging ontbreekt
  • Onnodig ingeschakelde functies
  • Netwerkverbindingen onnodig openstaan voor internet
  • Gebruik van zwakke protocollen of coderingen

Meer informatie over deze bedreiging: API8:2023 Beveiligingsfoutconfiguratie

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. U kunt deze instelling controleren en afdwingen met behulp van Azure Policy.
  • 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 beleid validate-jwt om het bestaan en de geldigheid van het 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. Als u Microsoft Entra gebruikt, biedt het beleid validate-azure-ad-token een uitgebreidere en eenvoudigere manier om beveiligingstokens te valideren.
    • Configureer het CORS-beleid en gebruik geen jokertekens * voor een configuratieoptie. Geef in plaats daarvan expliciet toegestane waarden weer.
    • Stel validatiebeleid in productieomgevingen in 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 validate-client-certificate . Zorg ervoor dat de validate-revocationkenmerken , validate-trusten validate-not-after validate-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 validate-graphQL-request . Zorg ervoor dat het element en max-size de authorization max-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 Azure 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.
  • Zorg ervoor dat uw API's abonnementssleutels vereisen, zelfs als alle producten zijn geconfigureerd om abonnementssleutels te vereisen. Meer informatie
  • Goedkeuring van het abonnement vereisen voor alle producten en alle abonnementsaanvragen zorgvuldig controleren.
  • Key Vault-integratie gebruiken om alle certificaten te beheren. Hiermee centraliseert u certificaatbeheer en kunt u bewerkingsbeheertaken vereenvoudigen, zoals certificaatvernieuwing of intrekking. Gebruik beheerde identiteit om te verifiëren bij sleutelkluizen.
  • 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.
  • Gebruik waar mogelijk referentiebeheer of beheerde identiteit om te verifiëren bij back-endservices.
  • 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.

Onjuist voorraadbeheer

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:2023 Onjuist voorraadbeheer

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 API-wijzigingen 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. Zorg ervoor dat beveiligingscontroles worden geïmplementeerd in alle beschikbare API-versies.
  • Afzonderlijke omgevingen (zoals ontwikkeling, testen en productie) met verschillende API Management-services. Zorg ervoor dat elke API Management-service verbinding maakt met de 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.
  • Beheermachtigingen isoleren voor API's en gerelateerde resources met behulp van werkruimten.
  • Gebruik tags om API's en producten te organiseren en deze te groeperen voor publicatie.
  • Publiceer API's voor gebruik via een 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.
  • Gebruik Azure API Center om een uitgebreide, gecentraliseerde inventarisatie van API's, versies en implementaties te onderhouden, zelfs als API's niet worden beheerd in Azure API Management.

Onveilig verbruik van API's

Resources die zijn verkregen via downstream-integraties, worden doorgaans meer vertrouwd dan API-invoer van de aanroeper of eindgebruiker. Als de juiste opschonings- en beveiligingsstandaarden niet worden toegepast, kan de API kwetsbaar zijn, zelfs als de integratie wordt geleverd via een vertrouwde service.

Meer informatie over deze bedreiging: API10:2023 Onveilig gebruik van API's

Aanbevelingen

  • Overweeg het gebruik van API Management om te fungeren als een gevel voor downstreamafhankelijkheden waarmee de back-end-API's zijn geïntegreerd.
  • Als downstream-afhankelijkheden worden gekoppeld aan API Management of als downstream-afhankelijkheden worden gebruikt met een beleid voor verzenden-aanvragen in API Management, gebruikt u de aanbevelingen uit andere secties van deze documentatie om ervoor te zorgen dat het veilige en gecontroleerde verbruik wordt beheerd, waaronder:
    • Controleren of veilig transport is ingeschakeld en TLS/SSL-configuratie afdwingen
    • Verifieer indien mogelijk met referentiebeheer of beheerde identiteit
    • Verbruik beheren met beleid voor frequentielimiet per sleutel en quotalimiet-per-sleutel
    • Reacties die niet compatibel zijn met de API-specificatie, registreren of blokkeren met behulp van het beleid voor validatie-inhoud en validatieheaders
    • Reacties transformeren met het beleid voor de setbody, bijvoorbeeld om onnodige of gevoelige informatie te verwijderen
    • Time-outs configureren en gelijktijdigheid beperken

Gerelateerde inhoud

Meer informatie over: