Dela via

Rekommendationer för att begränsa OWASP API Securitys topp 10 hot med API Management

GÄLLER FÖR: Alla API Management-nivåer

Anmärkning

Den här artikeln har uppdaterats för att återspegla den senaste OWASP API Security Top 10-listan för 2023.

Open Web Application Security Project (OWASP) Foundation arbetar för att förbättra programvarusäkerheten genom sina community-ledda programvaruprojekt med öppen källkod, hundratals kapitel över hela världen, tiotusentals medlemmar och genom att vara värd för lokala och globala konferenser.

OWASP API Security Project fokuserar på strategier och lösningar för att förstå och minska de unika säkerhetsriskerna för API:er. I den här artikeln diskuterar vi de senaste rekommendationerna för att minimera de 10 främsta API-hoten som identifieras av OWASP i deras 2023-lista med Hjälp av Azure API Management.

Även om API Management tillhandahåller omfattande kontroller för API-säkerhet tillhandahåller andra Microsoft-tjänster kompletterande funktioner för att identifiera eller skydda mot OWASP API-hot:

Behörighet på felaktig objektsnivå

API-objekt som inte skyddas med lämplig auktoriseringsnivå kan vara sårbara för dataläckor och obehörig datamanipulering via svaga objektåtkomstidentifierare. En angripare kan till exempel utnyttja en heltalsobjektidentifierare som kan itereras.

Mer information om det här hotet: API1:2023 Auktorisering på bruten objektnivå

Rekommendationer

  • Det bästa stället att implementera auktorisering på objektnivå finns i själva serverdels-API:et. På serverdelen kan rätt auktoriseringsbeslut fattas på begärandenivå (eller objekt), i förekommande fall med hjälp av logik som gäller för domänen och API:et. Överväg scenarier där en viss begäran kan ge olika detaljnivåer i svaret, beroende på beställarens behörigheter och auktorisering.

  • Om ett aktuellt sårbart API inte kan ändras på serverdelen kan API Management användas som reserv. Till exempel:

    • Använd en anpassad princip för att implementera auktorisering på objektnivå om den inte implementeras i serverdelen.

    • Implementera en anpassad princip för att mappa identifierare från begäran till serverdel och från serverdel till klient, så att interna identifierare inte exponeras.

      I dessa fall kan den anpassade principen vara ett principuttryck med en uppslagning (till exempel en ordlista) eller integrering med en annan tjänst via skicka-begäran-principen.

  • För GraphQL-scenarier framtvingar du auktorisering på objektnivå via principen validate-graphql-request med hjälp av elementet authorize .

Bruten autentisering

Autentiseringsmekanismen för en webbplats eller ETT API är särskilt sårbar eftersom den är öppen för anonyma användare. Tillgångar och slutpunkter som krävs för autentisering, inklusive bortglömda lösenordsflöden eller återställning av lösenordsflöden, bör skyddas för att förhindra utnyttjande.

Mer information om det här hotet: API2:2023 Bruten autentisering

Rekommendationer

  • Använd Microsoft Entra för att implementera API-autentisering. Microsoft Entra tillhandahåller automatiskt skyddade, motståndskraftiga och geografiskt distribuerade inloggningsslutpunkter. Använd policyn validate-azure-ad-token för att verifiera Microsoft Entra-token i inkommande API-begäranden.
  • Där autentisering krävs stöder API Management verifiering av OAuth 2-token, grundläggande autentisering, klientcertifikat och API-nycklar.
    • Se till att autentiseringsmetoderna konfigureras korrekt. Ange till exempel require-expiration-time och require-signed-tokens till true när du verifierar OAuth2-token med hjälp av principen validate-jwt .
  • Hastighetsbegränsning kan användas för att minska effektiviteten hos råstyrkeattacker.
  • Klient-IP-filtrering kan användas för att minska attackytan. Nätverkssäkerhetsgrupper kan tillämpas på virtuella nätverk som är integrerade med API Management.
  • Autentisera om möjligt till serverdelar från API Management via säkra protokoll och hanterad identitets - eller autentiseringshanterare för att autentisera till serverdelar.
  • Se till att token eller nycklar skickas i huvudena och inte i URL:erna för de inkommande begärandena till API Management och de utgående begärandena till backend-tjänsterna.
  • Använd Microsoft Entra för att skydda åtkomsten till API Management-utvecklarportalen.

Auktorisering på egenskapsnivå för trasiga objekt

Bra API-gränssnittsdesign är bedrägligt utmanande. Ofta, särskilt med äldre API:er som har utvecklats över tid, innehåller gränssnitten för begäran och svar fler datafält än vad de förbrukande programmen kräver, vilket möjliggör datainmatningsattacker. Angripare kan också identifiera odokumenterade gränssnitt. Dessa sårbarheter kan ge känsliga data till angriparen.

Mer information om det här hotet: API3:2023 Auktorisering på egenskapsnivå för brutet objekt

Rekommendationer

  • Det bästa sättet att minimera den här sårbarheten är att se till att de externa gränssnitt som definieras i serverdels-API:et utformas noggrant och helst oberoende av databeständighet. De bör endast innehålla de fält som krävs av API:ets konsumenter. API:er bör granskas ofta och äldre fält ska vara inaktuella och sedan tas bort.
  • I API Management använder du revisioner för att hantera ändringar som inte bryter mot kompatibilitet, till exempel tillägg av ett fält i ett gränssnitt, och versioner för att implementera brytande ändringar. Du bör också versionera bakomliggande gränssnitt, som vanligtvis har en annan livscykel än konsumentriktade API:er.
  • Frikoppla externa API-gränssnitt från den interna dataimplementeringen. Undvik att binda API-kontrakt direkt till datakontrakt i serverdelstjänster.
  • Om det inte går att ändra designen för serverdelsgränssnittet och överdrivna data är ett problem kan du använda API Management-transformeringsprinciper för att skriva om svarsnyttolaster och maskera eller filtrera data. Innehållsverifiering i API Management kan användas med ett XML- eller JSON-schema för att blockera svar med odokumenterade egenskaper eller felaktiga värden. Du kan till exempel ta bort onödiga JSON-egenskaper från en svarstext. Blockering av begäranden med odokumenterade egenskaper minimerar attacker, samtidigt som blockering av svar med odokumenterade egenskaper gör det svårare att omvänt konstruera potentiella attackvektorer. Principen för valideringsinnehåll stöder också blockeringssvar som överskrider en angiven storlek.
  • Använd principen validate-status-code för att blockera svar med fel som inte har definierats i API-schemat.
  • Använd principen validate-headers för att blockera svar med rubriker som inte har definierats i schemat eller som inte överensstämmer med definitionen i schemat. Ta bort oönskade rubriker med principen set-header .
  • För GraphQL-scenarier använder du principen validate-graphql-request för att validera GraphQL-begäranden, auktorisera åtkomst till specifika frågesökvägar och begränsa svarsstorleken.

Obegränsad resursförbrukning

API:er kräver att resurser körs, t.ex. minne eller CPU, och kan innehålla underordnade integreringar som representerar en driftskostnad (till exempel tjänster för betalning per begäran). Om du tillämpar gränser kan du skydda API:er från överdriven resursförbrukning.

Mer information om det här hotet: API4:2023 Obegränsad resursförbrukning

Rekommendationer

  • Använd principer för hastighetsbegränsning efter nyckel eller hastighetsbegränsning för att tillämpa begränsning på kortare tidsfönster. Tillämpa striktare principer för hastighetsbegränsning på känsliga slutpunkter, till exempel återställning av lösenord, inloggning eller registreringsåtgärder eller slutpunkter som förbrukar betydande resurser.
  • Använd principer för kvot per nyckel eller kvotgräns för att styra det tillåtna antalet API-anrop eller bandbredd under längre tidsramar.
  • Optimera prestanda med inbyggd cachelagring, vilket minskar förbrukningen av processor-, minnes- och nätverksresurser för vissa åtgärder.
  • Tillämpa valideringsprinciper.
    • max-size Använd attributet i policyn för valideringsinnehåll för att framtvinga maximal storlek på begäranden och svar
    • Definiera scheman och egenskaper, till exempel stränglängd eller maximal matrisstorlek, i API-specifikationen. Använd principer för validering av innehåll, valideringsparametrar och valideringshuvuden för att framtvinga dessa scheman för begäranden och svar.
    • Använd policyn validate-graphql-request för GraphQL-API:er och konfigurera max-depth och max-size parametrar.
    • Konfigurera aviseringar i Azure Monitor för överdriven dataförbrukning av användare.
  • För generativa AI-API:er:
  • Minimera den tid det tar för en serverdelstjänst att svara. Ju längre serverdelstjänsten tar att svara, desto längre tid är anslutningen upptagen i API Management, vilket minskar antalet begäranden som kan hanteras inom en viss tidsram.
    • Definiera timeout i principen för vidarebefordran och sträva efter det kortaste acceptabla värdet.
    • Begränsa antalet parallella backend-anslutningar med policyn begränsa samtidighet.
  • Tillämpa en CORS-princip för att kontrollera de webbplatser som tillåts läsa in de resurser som hanteras via API:et. För att undvika alltför tillåtande konfigurationer, använd inte jokerteckenvärden (*) i CORS-policyn.
  • Även om Azure har både skydd på plattformsnivå och förbättrat skydd mot DDoS-attacker (Distribuerad överbelastning), kan programskydd (layer 7) för API:er förbättras genom att distribuera en robotskyddstjänst framför API Management – till exempel Azure Application Gateway, Azure Front Door eller Azure DDoS Protection. När du använder en webbapplikationsbrandvägg (WAF) policy med Azure Application Gateway eller Azure Front Door, överväg att använda Microsoft_BotManagerRuleSet_1.0.

Auktorisering på bruten funktionsnivå

Komplexa principer för åtkomstkontroll med olika hierarkier, grupper och roller samt en oklar uppdelning mellan administrativa och vanliga funktioner leder till auktoriseringsfel. Genom att utnyttja dessa problem får angripare åtkomst till andra användares resurser eller administrativa funktioner.

Mer information om det här hotet: API5:2023 Auktorisering på bruten funktionsnivå

Rekommendationer

  • Som standard skyddar du alla API-slutpunkter i API Management med prenumerationsnycklar eller auktoriseringsprincip på alla API:er-nivå. Om tillämpligt definierar du andra auktoriseringsprinciper för specifika API:er eller API-åtgärder.
  • Verifiera OAuth-token med hjälp av principer.
    • Använd policyn validate-azure-ad-token för att verifiera Microsoft Entra-token. Ange alla nödvändiga anspråk och, om tillämpligt, ange auktoriserade applikationer.
    • För validering av token som inte utfärdats av Microsoft Entra definierar du en validate-jwt-princip och framtvingar nödvändiga tokenanspråk. Om möjligt kräver du förfallotid.
    • Om möjligt använder du krypterade token eller listar specifika program för åtkomst.
    • Övervaka och granska begäranden som avvisas på grund av bristande auktorisering.
  • Använd ett virtuellt Azure-nätverk eller Private Link för att dölja API-slutpunkter från Internet. Läs mer om alternativ för virtuella nätverk med API Management.
  • Definiera inte wildcard-API-operationer (t.ex. "catch-all"-API:er med * som sökväg). Se till att API Management endast hanterar begäranden för explicit definierade slutpunkter och att begäranden till odefinierade slutpunkter avvisas.
  • Publicera inte API:er med öppna produkter som inte kräver en prenumeration.
  • Om klient-IP-adresser är kända använder du en ip-filterprincip för att endast tillåta trafik från auktoriserade IP-adresser.
  • Använd principen validate-client-certificate för att framtvinga att ett certifikat som presenteras av en klient för en API Management-instans matchar angivna verifieringsregler och anspråk.

Obegränsad åtkomst till känsliga affärsflöden

API:er kan exponera ett brett spektrum av funktioner för det förbrukande programmet. Det är viktigt för API-författare att förstå de affärsflöden som API:et tillhandahåller och den associerade känsligheten. Det finns en större risk för verksamheten om API:er som exponerar känsliga flöden inte implementerar lämpliga skydd.

Mer information om det här hotet: API6:2023 Obegränsad åtkomst till känsliga affärsflöden

Rekommendationer

  • Minska eller blockera åtkomst baserat på klient fingeravtryck. Använd till exempel return-response-policy med välja-policy för att blockera trafik från huvudlösa webbläsare baserat på User-Agent-headern eller konsistensen hos andra headers.
  • Använd policyn validate-parameters för att framtvinga att begärandehuvuden matchar API-specifikationen.
  • Använd ip-filterprincip för att endast tillåta begäranden från kända IP-adresser eller neka åtkomst från specifika IP-adresser.
  • Använd privata nätverksfunktioner för att begränsa den externa anslutningen till interna API:er.
  • Använd principen rate-limit-by-key för att begränsa toppar i API-förbrukningen baserat på användaridentitet, IP-adress eller något annat värde.
  • Front API Management med Azure Application Gateway eller Azure DDoS Protection-tjänsten för att identifiera och blockera robottrafik.

Förfalskning av begäran på serversidan

En förfalskningsrisk på serversidan kan inträffa när API:et hämtar en nedströmsresurs baserat på värdet för en URL som har skickats av API-anroparen utan lämpliga verifieringskontroller.

Mer information om det här hotet: API7:2023 Förfalskning av serversidans begäran

Rekommendationer

  • Använd om möjligt inte URL:er som anges i klientens nyttolaster, till exempel som parametrar för serverdels-URL:er, principen för att skicka begäran eller skriva om url-principen .
  • Om API Management eller serverdelstjänster använder URL:er som tillhandahålls i begärans belastning för affärslogik, definierar och tillämpar du en begränsad lista över värdnamn, portar, medietyper eller andra attribut med principer i API Management, till exempel principer som välja och uttryck för principer.
  • timeout Definiera attributet i principerna för vidarebefordran och skicka begäran.
  • Verifiera och sanera begärande- och svarsdata med valideringsprinciper. Om det behövs använder du principen set-body för att bearbeta svaret och undvika att returnera rådata.
  • Använd privata nätverk för att begränsa anslutningen. Om API:et till exempel inte behöver vara offentligt begränsar du anslutningen från Internet för att minska attackytan.

Felkonfiguration av säkerhet

Angripare kan försöka utnyttja säkerhetsfelkonfigurationsproblem, till exempel:

  • Bristande säkerhetshärdning
  • Funktioner som inte är aktiverade i onödan
  • Nätverksanslutningar som är onödigt öppna för Internet
  • Användning av svaga protokoll eller chiffer

Mer information om det här hotet: API8:2023 Säkerhetsfelkonfiguration

Rekommendationer

  • Konfigurera gateway-TLS korrekt. Använd inte sårbara protokoll (till exempel TLS 1.0, 1.1) eller chiffer.
  • Konfigurera API:er att endast acceptera krypterad trafik, till exempel via HTTPS- eller WSS-protokoll. Du kan granska och tillämpa den här inställningen med hjälp av Azure Policy.
  • Överväg att distribuera API Management bakom en privat slutpunkt eller ansluta till ett virtuellt nätverk som distribuerats i internt läge. I interna nätverk kan åtkomst styras inifrån det privata nätverket (via brandväggs- eller nätverkssäkerhetsgrupper) och från Internet (via en omvänd proxy).
  • Använd Azure API Management-principer:
    • Ärv alltid policyer från överordnade genom taggen <base>.
    • När du använder OAuth 2.0 konfigurerar och testar du principen validate-jwt för att kontrollera tokens existens och giltighet innan den når serverdelen. Kontrollera förfallotiden för token automatiskt, tokensignaturen och utfärdaren. Framtvinga anspråk, målgrupper, förfallodatum för token och tokensignatur via principinställningar. Om du använder Microsoft Entra ger policyn validate-azure-ad-token ett mer omfattande och enklare sätt att verifiera säkerhetstoken.
    • Konfigurera CORS-principen och använd inte jokertecken * för något konfigurationsalternativ. I stället listar du uttryckligen tillåtna värden.
    • Ange valideringsprinciper i produktionsmiljöer för att verifiera JSON- och XML-scheman, rubriker, frågeparametrar och statuskoder och för att framtvinga maximal storlek för begäran eller svar.
    • Om API Management ligger utanför en nätverksgräns är klientens IP-validering fortfarande möjlig med hjälp av principen begränsa anroparens IP-adresser . Se till att den använder en tillåten lista, inte en blockeringslista.
    • Om klientcertifikat används mellan anroparen och API Management använder du principen validate-client-certificate . Kontrollera att attributen validate-revocation, validate-trust, validate-not-beforeoch validate-not-after är inställda på true.
  • Klientcertifikat (ömsesidig TLS) kan också tillämpas mellan API Management och serverdelen. Serverdelen bör:
    • Auktoriseringsuppgifter är konfigurerade
    • Verifiera certifikatkedjan där det är tillämpligt
    • Verifiera certifikatnamnet där det är tillämpligt
    • För GraphQL-scenarier använder du policyn validate-graphQL-request . Kontrollera att authorization-elementet och attributen max-size och max-depth har angetts.
  • Lagra inte hemligheter i principfiler eller i källkontrollen. Använd alltid namngivna värden i API Management eller hämta hemligheter vid körning med hjälp av anpassade principuttryck. Namngivna värden ska integreras med Azure Key Vault eller krypteras i API Management genom att markera dem som "hemliga". Lagra aldrig hemligheter i klartextnamngivna värden.
  • Publicera API:er via produkter som kräver prenumerationer. Använd inte öppna produkter som inte kräver en prenumeration.
  • Se till att dina API:er kräver prenumerationsnycklar, även om alla produkter är konfigurerade för att kräva prenumerationsnycklar. Läs mer
  • Kräv prenumerationsgodkännande för alla produkter och granska noggrant alla prenumerationsbegäranden.
  • Använd Key Vault-integrering för att hantera alla certifikat. Detta centraliserar certifikathantering och kan underlätta åtgärder för hantering av uppgifter som förnyelse av certifikat eller återkallande. Använd hanterad identitet för att autentisera till nyckelvalv.
  • När du använder den självhostade gatewayen, säkerställ att det finns en process för att uppdatera avbildningen till den senaste versionen regelbundet.
  • Representera serverdelstjänster som serverdelsentiteter. Konfigurera autentiseringsuppgifter för auktorisering, validering av certifikatkedja och validering av certifikatnamn i förekommande fall.
  • Se till att dina backends skyddas mot stigtraversering (katalogbläddring). API Management kan vidarebefordra begäranden som innehåller ..%2f i URL-sökvägen till en bakända. Om serverdelen avkodar den till ../kan den vara känslig för en sökvägsattack. Du kan också använda en princip i API Management för att identifiera och blockera begäranden som de som innehåller ..%2f i sökvägen.
  • Använd där det är möjligt autentiseringshanteraren eller den hanterade identiteten för att autentisera mot serverdelstjänster.
  • När du använder utvecklarportalen:
    • Om du väljer att själv vara värd för utvecklarportalen kontrollerar du att det finns en process för att regelbundet uppdatera den lokalt installerade portalen till den senaste versionen. Uppdateringar för den hanterade standardversionen är automatiska.
    • Använd Microsoft Entra-ID eller Externt ID för Microsoft Entra för registrering och inloggning av användare. Inaktivera standardautentiseringen för användarnamn och lösenord, vilket är mindre säkert.
    • Tilldela användargrupper till produkter för att styra synligheten för API:er i portalen.
  • Använd Azure Policy för att framtvinga API Management-behörigheter på resursnivå och rollbaserad åtkomstkontroll (RBAC) för att styra resursåtkomsten. Bevilja minsta nödvändiga behörigheter till varje användare.
  • Använd en DevOps-process - och infrastruktur-som-kod-metod utanför en utvecklingsmiljö för att säkerställa konsekvens i API Management-innehåll och konfigurationsändringar och för att minimera mänskliga fel.
  • Använd inte inaktuella funktioner.

Felaktig lagerhantering

Säkerhetsrisker som rör hantering av felaktiga tillgångar är:

  • Brist på korrekt API-dokumentation eller ägarskapsinformation
  • Överdrivet många äldre API-versioner, vilket kan saknas säkerhetskorrigeringar

Mer information om det här hotet: API9:2023 Felaktig lagerhantering

Rekommendationer

  • Använd en väldefinierad OpenAPI-specifikation som källa för import av REST-API:er. Specifikationen tillåter inkapsling av API-definitionen, inklusive självdokumenterande metadata.
  • Använd API-gränssnitt med exakta sökvägar, datascheman, rubriker, frågeparametrar och statuskoder. Undvik jokerteckenåtgärder. Ange beskrivningar för varje API och åtgärd och inkludera kontakt- och licensinformation.
  • Undvik slutpunkter som inte direkt bidrar till affärsmålet. De ökar attackytan i onödan och gör det svårare att utveckla API:et.
  • Använd revisioner och versioner i API Management för att hantera API-ändringar. Ha en stark strategi för versionering av backend och förbind dig till ett maximalt antal av tidigare API-versioner som stöds (till exempel 2 eller 3 tidigare versioner). Planera att snabbt avveckla och slutligen ta bort äldre API-versioner som ofta är mindre säkra. Se till att säkerhetskontroller implementeras i alla tillgängliga API-versioner.
  • Avgränsa miljöer (till exempel utveckling, testning och produktion) med olika API Management-tjänster. Se till att varje API Management-tjänst ansluter till sina beroenden i samma miljö. I testmiljön bör till exempel test-API Management-resursen ansluta till en Azure Key Vault-testresurs och testversionerna av serverdelstjänster. Använd DevOps-automatiserings- och infrastruktur-som-kod-metoder för att upprätthålla konsekvens och noggrannhet mellan miljöer och minska mänskliga fel.
  • Isolera administrativa behörigheter till API:er och relaterade resurser med hjälp av arbetsytor.
  • Använd taggar för att organisera API:er och produkter och gruppera dem för publicering.
  • Publicera API:er för förbrukning via en utvecklarportal. Kontrollera att API-dokumentationen är uppdaterad.
  • Identifiera odokumenterade eller ohanterade API:er och exponera dem via API Management för bättre kontroll.
  • Använd Azure API Center för att upprätthålla en omfattande, centraliserad inventering av API:er, versioner och distributioner, även om API:er inte hanteras i Azure API Management.

Osäker förbrukning av API:er

Resurser som hämtas via nedströmsintegreringar tenderar att vara mer betrodda än API-indata från anroparen eller slutanvändaren. Om lämpliga sanitiserings- och säkerhetsstandarder inte tillämpas kan API:et vara sårbart, även om integreringen tillhandahålls via en betrodd tjänst.

Mer information om det här hotet: API10:2023 Osäker förbrukning av API:er

Rekommendationer

  • Överväg att använda API Management för att fungera som en fasad för nedströmsberoenden som backend-API:erna integreras med.
  • Om underordnade beroenden frontas med API Management eller om underordnade beroenden används med en send-request-princip i API Management använder du rekommendationerna från andra avsnitt i den här dokumentationen för att säkerställa säker och kontrollerad förbrukning, inklusive:
    • Se till att säker transport är aktiverad och framtvinga TLS/SSL-konfiguration
    • Om möjligt autentisera med autentiseringshanteraren eller hanterad identitet
    • Kontrollera förbrukningen med principer för hastighetsgräns per nyckel och kvotgräns för nyckel
    • Logga eller blockera svar som är inkompatibla med API-specifikationen med hjälp av policyerna validate-content och validate-header
    • Transformera svar med policyn set-body, till exempel för att ta bort onödig eller känslig information
    • Konfigurera tidsgränser och begränsa samtidighet

Relaterat innehåll

Läs mer om:

  • Last updated on