Rekommendationer för att minska OWASP API Security de 10 främsta hoten med API Management

  • Artikel

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

Open Web Application Security Project (OWASP) Foundation arbetar för att förbättra programvarusäkerheten genom sin community-ledda öppen källkod programvaruprojekt, 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 går vi igenom rekommendationer för att använda Azure API Management för att minska de 10 främsta API-hoten som identifierats av OWASP.

Kommentar

Förutom att följa rekommendationerna i den här artikeln kan du aktivera Defender för API:er, en funktion för Microsoft Defender för molnet, för API-säkerhetsinsikter, rekommendationer och hotidentifiering. Läs mer om hur du använder Defender för API:er med API Management

Auktorisering på bruten objektnivå

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:2019 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 uppslagspunkt (till exempel en ordlista) eller integrering med en annan tjänst via principen för att skicka begäran .

  • För GraphQL-scenarier framtvingar du auktorisering på objektnivå genom att verifiera GraphQL-begärandeprincipen med hjälp av elementet authorize .

Bruten användarautentisering

Autentiseringsmekanismer implementeras ofta felaktigt eller saknas, vilket gör att angripare kan utnyttja implementeringsfel för att komma åt data.

Mer information om det här hotet: API2:2019 Bruten användarautentisering

Rekommendationer

Använd API Management för användarautentisering och auktorisering:

  • Autentisering – API Management stöder följande autentiseringsmetoder:

    • Grundläggande autentiseringsprincip – Autentiseringsuppgifter för användarnamn och lösenord.

    • Prenumerationsnyckel – En prenumerationsnyckel ger en liknande säkerhetsnivå som grundläggande autentisering och kanske inte räcker till ensam. Om prenumerationsnyckeln komprometteras kan en angripare få obegränsad åtkomst till systemet.

    • Klientcertifikatprincip – Att använda klientcertifikat är säkrare än grundläggande autentiseringsuppgifter eller prenumerationsnyckel, men det tillåter inte flexibiliteten i tokenbaserade auktoriseringsprotokoll som OAuth 2.0.

  • Auktorisering – API Management stöder en verifierad JWT-princip för att kontrollera giltigheten för en inkommande OAuth 2.0 JWT-åtkomsttoken baserat på information som hämtats från OAuth-identitetsproviderns metadataslutpunkt. Konfigurera principen för att kontrollera relevanta tokenanspråk, målgrupper och förfallotid. Läs mer om att skydda ett API med OAuth 2.0-auktorisering och Microsoft Entra-ID.

Fler rekommendationer:

  • Använd principer i API Management för att öka säkerheten. Till exempel saktar anropsfrekvensbegränsningen ned dåliga aktörer med råstyrkeattacker för att kompromettera autentiseringsuppgifter.

  • API:er bör använda TLS/SSL (transportsäkerhet) för att skydda autentiseringsuppgifterna eller token. Autentiseringsuppgifter och token ska skickas i begärandehuvuden och inte som frågeparametrar.

  • I UTVECKLARportalen för API Management konfigurerar du Microsoft Entra-ID eller Azure Active Directory B2C som identitetsprovider för att öka kontosäkerheten. Utvecklarportalen använder CAPTCHA för att minimera råstyrkeattacker.

Överdriven dataexponering

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.

En felaktig aktör kan försöka komma åt API:et direkt (kanske genom att spela upp en giltig begäran) eller sniffa trafiken mellan servern och API:et. Analys av API-åtgärderna och tillgängliga data kan ge känsliga data till angriparen, som inte visas för eller används av klientdelsprogrammet.

Mer information om det här hotet: API3:2019 Överdriven dataexponering

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 korrekt kontrollera icke-inbrytningsändringar, till exempel tillägg av ett fält i ett gränssnitt. Du kan använda revisioner tillsammans med en versionsimplementering på serverdelen.

    • Versioner för icke-bakåtkompatibla ändringar, till exempel borttagning av ett fält från ett gränssnitt.

  • 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. Du kan till exempel ta bort onödiga JSON-egenskaper från en svarstext.

  • Validering av svarsinnehåll i API Management kan användas med ett XML- eller JSON-schema för att blockera svar med odokumenterade egenskaper eller felaktiga värden. Principen stöder också blockeringssvar som överskrider en angiven storlek.

  • Använd principen verifiera statuskod för att blockera svar med fel som är odefinierade i API-schemat.

  • Använd principen verifiera rubriker 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 den angivna huvudprincipen.

  • För GraphQL-scenarier använder du principen för att validera GraphQL-begäranden för att verifiera GraphQL-begäranden, auktorisera åtkomst till specifika frågesökvägar och begränsa svarsstorleken.

Brist på resurser och hastighetsbegränsning

Brist på hastighetsbegränsning kan leda till dataexfiltrering eller lyckade DDoS-attacker på serverdelstjänster, vilket orsakar avbrott för alla konsumenter.

Mer information om det här hotet: API4:2019 Brist på resurser och hastighetsbegränsning

Rekommendationer

  • Använd principer för hastighetsbegränsning (kortsiktig) och kvotgräns (långsiktig) för att styra det tillåtna antalet API-anrop eller bandbredd per konsument.

  • Definiera strikta definitioner för begärandeobjekt och deras egenskaper i OpenAPI-definitionen. Definiera till exempel maxvärdet för växlings heltal, maxLength och reguljärt uttryck (regex) för strängar. Framtvinga dessa scheman med verifiera innehåll och verifiera parametrar i API Management.

  • Framtvinga maximal storlek på begäran med principen verifiera innehåll .

  • Optimera prestanda med inbyggd cachelagring, vilket minskar förbrukningen av processor-, minnes- och nätverksresurser för vissa åtgärder.

  • Framtvinga autentisering för API-anrop (se Bruten användarautentisering). Återkalla åtkomst för missbrukande användare. Inaktivera till exempel prenumerationsnyckeln, blockera IP-adressen med principen begränsa anroparens IP-adresser eller avvisa begäranden för ett visst användaranspråk från en JWT-token.

  • Tillämpa en CORS-princip för att kontrollera de webbplatser som tillåts läsa in de resurser som hanteras via API:et. Använd inte jokerteckenvärden (*) i CORS-principen för att undvika alltför tillåtande konfigurationer.

  • Minimera den tid det tar för en serverdelstjänst att svara. Ju längre serverdelstjänsten tar att svara, desto längre tid används anslutningen i API Management, vilket minskar antalet begäranden som kan hanteras inom en viss tidsram.

  • API Management kan skydda serverdelstjänster från DDoS-attacker, men det kan vara sårbart för själva attackerna. Distribuera en robotskyddstjänst framför API Management (till exempel Azure Application Gateway, Azure Front Door eller Azure DDoS Protection) för att bättre skydda mot DDoS-attacker. När du använder en WAF med Azure Application Gateway eller Azure Front Door bör du överväga 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:2019 Auktorisering på bruten funktionsnivå

Rekommendationer

  • Som standard skyddar du alla API-slutpunkter i API Management med prenumerationsnycklar.

  • Definiera en validera JWT-princip och framtvinga nödvändiga tokenanspråk. Om vissa åtgärder kräver striktare anspråksframtvingande definierar du endast extra validate-jwt principer för dessa åtgärder.

  • 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 API-åtgärder med jokertecken (d.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.

Masstilldelning

Om ett API erbjuder fler fält än vad klienten kräver för en viss åtgärd kan en angripare mata in överdrivna egenskaper för att utföra obehöriga åtgärder på data. Angripare kan identifiera odokumenterade egenskaper genom att granska formatet för begäranden och svar eller andra API:er eller gissa dem. Den här sårbarheten är särskilt tillämplig om du inte använder starkt skrivna programmeringsspråk.

Mer information om det här hotet: API6:2019 Masstilldelning

Rekommendationer

  • Externa API-gränssnitt bör frikopplas från den interna dataimplementeringen. Undvik att binda API-kontrakt direkt till datakontrakt i serverdelstjänster. Granska API-designen ofta och inaktuell och ta bort äldre egenskaper med versionshantering i API Management.

  • Definiera XML- och JSON-kontrakt exakt i API-schemat och använd verifiera innehåll och verifiera parametrar för att blockera begäranden och svar med odokumenterade egenskaper. 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.

  • Om serverdelsgränssnittet inte kan ändras använder du transformeringsprinciper för att skriva om nyttolaster för begäran och svar och frikoppla API-kontrakten från serverdelskontrakt. Du kan till exempel maskera eller filtrera data eller ta bort onödiga JSON-egenskaper.

Felkonfiguration av säkerhet

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

  • Säkerhetshärdning saknas
  • Onödiga aktiverade funktioner
  • Nätverksanslutningar som är onödigt öppna för Internet
  • Användning av svaga protokoll eller chiffer
  • Andra inställningar eller slutpunkter som kan tillåta obehörig åtkomst till systemet

Mer information om det här hotet: API7:2019 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.

  • Ö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:

    • Ärver alltid överordnade principer via taggen <base> .

    • När du använder OAuth 2.0 konfigurerar och testar du JWT-principen för att kontrollera JWT-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.

    • 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 till prevent 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 verifiera klientcertifikat . 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:

        • Konfigurera autentiseringsuppgifter för auktorisering

        • Verifiera certifikatkedjan där det är tillämpligt

        • Verifiera certifikatnamnet där det är tillämpligt

  • För GraphQL-scenarier använder du principen verifiera GraphQL-begäran . Kontrollera att elementet och max-size attributen authorizationmax-depth har angetts.

  • Lagra inte hemligheter i principfiler eller i källkontrollen. Använd alltid API Management-namngivna värden eller hämta hemligheterna vid körning med hjälp av anpassade principuttryck.

    • Namngivna värden ska integreras med Key Vault eller krypteras i API Management genom att markera dem som "hemliga". Lagra aldrig hemligheter i oformaterade namngivna värden.

  • Publicera API:er via produkter som kräver prenumerationer. Använd inte öppna produkter som inte kräver en prenumeration.

  • Använd Key Vault-integrering för att hantera alla certifikat – detta centraliserar certifikathantering och kan underlätta åtgärder som förnyelse eller återkallande av certifikat.

  • När du använder den lokala gatewayen kontrollerar du att det finns en process för att uppdatera avbildningen till den senaste versionen med jämna mellanrum.

  • Representera serverdelstjänster som serverdelsentiteter. Konfigurera autentiseringsuppgifter för auktorisering, validering av certifikatkedja och validering av certifikatnamn i förekommande fall.

  • 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 Azure Active Directory B2C 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.

Injektion

Alla slutpunkter som accepterar användardata är potentiellt sårbara för en inmatningsexploatering. Exempel är, men är inte begränsade till:

  • Kommandoinmatning, där en felaktig aktör försöker ändra API-begäran för att köra kommandon på operativsystemet som är värd för API:et

  • SQL-inmatning, där en felaktig aktör försöker ändra API-begäran för att köra kommandon och frågor mot databasen som ett API är beroende av

Mer information om det här hotet: API8:2019-inmatning

Rekommendationer

  • Moderna WAF-principer (Web Application Firewall) omfattar många vanliga sårbarheter vid inmatning. ÄVEN om API Management inte har någon inbyggd WAF-komponent rekommenderar vi starkt att du distribuerar en WAF-överordnad (framför) API Management-instans. Du kan till exempel använda Azure Application Gateway eller Azure Front Door.

    Viktigt!

    Se till att en dålig aktör inte kan kringgå gatewayen som är värd för WAF och ansluta direkt till API Management-gatewayen eller själva serverdels-API:et. Möjliga åtgärder är: nätverks-ACL:er, användning av API Management-principer för att begränsa inkommande trafik efter klient-IP, borttagning av offentlig åtkomst där det inte behövs och klientcertifikatautentisering (kallas även ömsesidig TLS eller mTLS).

  • Använd i förekommande fall principer för schema- och parameterverifiering för att ytterligare begränsa och verifiera begäran innan den når serverdels-API-tjänsten.

    Schemat som medföljer API-definitionen bör ha en regex-mönsterbegränsning som tillämpas på sårbara fält. Varje regex bör testas för att säkerställa att det begränsar fältet tillräckligt för att minimera vanliga inmatningsförsök.

Felaktig hantering av tillgångar

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:2019 Felaktig hantering av tillgångar

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 styra och kontrollera API-slutpunkterna. Ha en stark strategi för serverdelsversioner och genomför ett maximalt antal API-versioner som stöds (till exempel 2 eller 3 tidigare versioner). Planera för att snabbt föråldrade och slutligen ta bort äldre, ofta mindre säkra, API-versioner.

  • Använd en API Management-instans per miljö (till exempel utveckling, test och produktion). Se till att varje API Management-instans ansluter till dess 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.

  • 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 den inbyggda utvecklarportalen. Kontrollera att API-dokumentationen är uppdaterad.

  • Identifiera odokumenterade eller ohanterade API:er och exponera dem via API Management för bättre kontroll.

Otillräcklig loggning och övervakning

Otillräcklig loggning och övervakning, tillsammans med saknad eller ineffektiv integrering med incidenthantering, gör det möjligt för angripare att ytterligare attackera system, upprätthålla beständighet, pivotera till fler system att manipulera och extrahera eller förstöra data. De flesta brottsstudier visar att tiden för att upptäcka ett intrång är över 200 dagar, vanligtvis identifierad av externa parter snarare än interna processer eller övervakning.

Mer information om det här hotet: API10:2019 Otillräcklig loggning och övervakning

Rekommendationer

Nästa steg

Läs mer om: