Dela via

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

Kommentar

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 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 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 kan andra Microsoft-tjänster tillhandahålla kompletterande funktioner för att identifiera eller skydda mot OWASP API-hot:

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

  • 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

Auktorisering på egenskapsnivå för brutna 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 korrekt kontrollera icke-inbrytningsändringar, till exempel tillägg av ett fält i ett gränssnitt och versioner för att implementera icke-bakåtkompatibla ändringar. Du bör också version serverdelsgrä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.
  • För generativa AI-API:er:
    • Använd semantisk cachelagring för att minska belastningen på serverdelarna.
    • Använd tokenbegränsning för att kontrollera förbrukning och kostnader.
    • Generera mått för tokenförbrukning för att övervaka tokenanvändning och konfigurera aviseringar.
  • 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.
  • 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.
  • Ä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 brandväggsprincip för webbprogram (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: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 program.
    • 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 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.
  • 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 principen return-response med välj-principen för att blockera trafik från huvudlösa webbläsare baserat på användaragentens huvud eller konsekvens för andra rubriker.
  • 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ärandenyttolasten för affärslogik definierar och framtvingar du en begränsad lista över värdnamn, portar, medietyper eller andra attribut med principer i API Management, till exempel välja princip- och principuttryck.
  • 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:

  • Säkerhetshärdning saknas
  • 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:
    • Ärver alltid överordnade principer via 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:
    • 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 policyn validate-graphQL-request . Kontrollera att elementet och max-size attributen authorization max-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 Azure 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.
  • 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 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.
  • 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 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.

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 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. 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 underordnade beroenden som serverdels-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 set-body-principen, 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: