Sdílet prostřednictvím

Doporučení ke zmírnění 10 hrozeb zabezpečení rozhraní API OWASP s využitím služby API Management

  • Článek

PLATÍ PRO: Všechny úrovně služby API Management

Poznámka:

Tento článek byl aktualizován tak, aby odrážel nejnovější seznam OWASP API Security Top 10 pro 2023.

Nadace OWASP (Open Web Application Security Project) pracuje na zlepšení zabezpečení softwaru prostřednictvím svých opensourcových softwarových projektů, stovek kapitol po celém světě, desítek tisíc členů a hostování místních a globálních konferencí.

Projekt zabezpečení rozhraní API OWASP se zaměřuje na strategie a řešení pro pochopení a zmírnění jedinečných ohrožení zabezpečení a rizik zabezpečení rozhraní API. V tomto článku probereme nejnovější doporučení ke zmírnění 10 hlavních hrozeb rozhraní API identifikovaných OWASP v seznamu 2023 pomocí služby Azure API Management.

I když služba API Management poskytuje komplexní ovládací prvky zabezpečení rozhraní API, další služby Microsoft poskytují doplňkové funkce pro detekci nebo ochranu před hrozbami rozhraní API OWASP:

Autorizace na úrovni poškozených objektů

Objekty rozhraní API, které nejsou chráněné odpovídající úrovní autorizace, můžou být ohroženy únikem dat a neoprávněnou manipulací s daty prostřednictvím slabých identifikátorů přístupu k objektům. Útočník může například zneužít celočíselný identifikátor objektu, který se dá itestrovat.

Další informace o této hrozbě: Autorizace na úrovni poškozených objektů API1:2023

Doporučení

  • Nejlepším místem pro implementaci autorizace na úrovni objektu je samotné back-endové rozhraní API. V back-endu je možné provést správná rozhodnutí o autorizaci na úrovni požadavku (nebo objektu), pokud je to možné, pomocí logiky použitelné pro doménu a rozhraní API. Zvažte scénáře, kdy daný požadavek může v odpovědi přinést různé úrovně podrobností v závislosti na oprávněních a autorizaci žadatele.

  • Pokud se v back-endu nedá změnit aktuální zranitelné rozhraní API, může být služba API Management použita jako záložní. Příklad:

    • K implementaci autorizace na úrovni objektu použijte vlastní zásadu, pokud není implementována v back-endu.

    • Implementujte vlastní zásadu, která mapuje identifikátory z požadavku na back-end a z back-endu do klienta, aby interní identifikátory nezůrazovaly.

      V těchto případech může být vlastní zásada výrazem zásad s vyhledáváním (například slovníkem) nebo integrací s jinou službou prostřednictvím zásad pro odeslání žádosti .

  • Ve scénářích GraphQL pomocí elementu vynucujte autorizaci na úrovni objektu authorize prostřednictvím zásad validate-graphql-request.

Přerušené ověřování

Mechanismus ověřování pro web nebo rozhraní API je zvlášť ohrožený, protože je otevřený anonymním uživatelům. Prostředky a koncové body vyžadované pro ověřování, včetně zapomenutého hesla nebo resetování toků hesel, by měly být chráněné, aby se zabránilo zneužití.

Další informace o této hrozbě: Přerušené ověřování rozhraní API2:2023

Doporučení

  • K implementaci ověřování rozhraní API použijte Microsoft Entra. Microsoft Entra automaticky poskytuje chráněné, odolné a geograficky distribuované koncové body přihlášení. Pomocí zásad validate-azure-ad-token ověřte tokeny Microsoft Entra v příchozích požadavcích rozhraní API.
  • Pokud se vyžaduje ověřování, služba API Management podporuje ověřování tokenů OAuth 2, základní ověřování, klientských certifikátů a klíčů rozhraní API.
    • Zajistěte správnou konfiguraci metod ověřování. Například nastavte a require-signed-tokens nastavte true require-expiration-time při ověřování tokenů OAuth2 pomocí zásad validate-jwt.
  • Omezení rychlosti je možné využít ke snížení účinnosti útoků hrubou silou.
  • Filtrování IP adres klienta se dá použít ke snížení prostoru útoku. Skupiny zabezpečení sítě je možné použít u virtuálních sítí integrovaných se službou API Management.
  • Pokud je to možné, ověřte se u back-endů ze služby API Management prostřednictvím zabezpečených protokolů a spravované identity nebo správce přihlašovacích údajů pro ověřování v back-endech.
  • Ujistěte se, že se tokeny nebo klíče předávají v hlavicích a ne v adresách URL příchozích požadavků do služby API Management a odchozích požadavků na back-endy.
  • K zabezpečení přístupu k portálu pro vývojáře služby API Management použijte Microsoft Entra.

Autorizace na úrovni poškozených vlastností objektu

Dobrý návrh rozhraní API je velmi náročný. Často, zejména u starších rozhraní API, která se v průběhu času vyvíjejí, rozhraní požadavků a odpovědí obsahují více datových polí, než vyžadují aplikace využívající, což umožňuje útoky prostřednictvím injektáže dat. Útočníci můžou také zjistit nezdokumentovaná rozhraní. Tato ohrožení zabezpečení by mohla útočníkovi přinést citlivá data.

Další informace o této hrozbě: Autorizace na úrovni vlastnosti poškozeného objektu API3:2023

Doporučení

  • Nejlepším přístupem k zmírnění tohoto ohrožení zabezpečení je zajistit, aby byla externí rozhraní definovaná v back-endovém rozhraní API navržena pečlivě a ideálně nezávisle na trvalosti dat. Měly by obsahovat pouze pole požadovaná uživateli rozhraní API. Rozhraní API by se měla často kontrolovat a starší pole jsou zastaralá a pak se odeberou.
  • Ve službě API Management používejte revize k řádnému řízení neprolomných změn, například přidání pole do rozhraní a verzí k implementaci zásadních změn. Měli byste také verze back-endových rozhraní, která mají obvykle jiný životní cyklus než rozhraní API určená pro spotřebitele.
  • Oddělení externích rozhraní API od implementace interních dat Vyhněte se vazbám kontraktů rozhraní API přímo na datové kontrakty v back-endových službách.
  • Pokud není možné změnit návrh back-endového rozhraní a nadměrné množství dat, použijte zásady transformace služby API Management k přepsání datových částí odpovědí a maskování nebo filtrování dat. Ověření obsahu ve službě API Management je možné použít se schématem XML nebo JSON k blokování odpovědí s nezdokumentovanými vlastnostmi nebo nesprávnými hodnotami. Odeberte například nepotřebné vlastnosti JSON z textu odpovědi. Blokování požadavků s nezdokumentovanými vlastnostmi snižuje riziko útoků a blokování odpovědí s nezdokumentovanými vlastnostmi znesnadňuje zpětné analýzy potenciálních vektorů útoku. Zásady ověření obsahu také podporují blokování odpovědí překračujících zadanou velikost.
  • Pomocí zásad ověření stavu kódu můžete blokovat odpovědi s chybami nedefinovanými ve schématu rozhraní API.
  • Pomocí zásad validate-headers můžete blokovat odpovědi s hlavičkami, které nejsou definovány ve schématu nebo nevyhovují jejich definici ve schématu. Odeberte nežádoucí hlavičky pomocí zásad hlavičky set.
  • Ve scénářích GraphQL použijte zásadu validate-graphql-request k ověření požadavků GraphQL, autorizaci přístupu ke konkrétním cestám dotazů a omezení velikosti odpovědi.

Neomezená spotřeba prostředků

Rozhraní API vyžadují, aby běžely prostředky, jako je paměť nebo procesor, a můžou zahrnovat podřízené integrace, které představují provozní náklady (například služby s průběžnými platbami za žádosti). Použití limitů může pomoct chránit rozhraní API před nadměrnou spotřebou prostředků.

Další informace o této hrozbě: ROZHRANÍ API4:2023 – Neomezená spotřeba prostředků

Doporučení

  • Pomocí zásad omezení rychlosti podle klíče nebo omezení rychlosti můžete použít omezování v kratších časových oknech. Na citlivých koncových bodech použijte přísnější zásady omezování rychlosti, jako je resetování hesla, přihlášení nebo operace registrace nebo koncové body, které spotřebovávají významné prostředky.
  • Pomocí zásad kvót podle klíče nebo omezení kvóty můžete řídit povolený počet volání rozhraní API nebo šířku pásma pro delší časové rámce.
  • Optimalizujte výkon pomocí integrovaného ukládání do mezipaměti, čímž se snižuje spotřeba procesoru, paměti a síťových prostředků pro určité operace.
  • Použijte zásady ověřování.
  • Pro rozhraní API pro generování AI:
  • Minimalizujte dobu, po které back-endová služba reaguje. Čím déle back-endová služba reaguje, tím déle je připojení obsazené ve službě API Management, čímž se snižuje počet požadavků, které je možné obsložovat v daném časovém rámci.
    • Definujte timeout v zásadách forward-request a snažte se o nejkratší přijatelnou hodnotu.
    • Omezte počet paralelních back-endových připojení pomocí zásad souběžnosti omezení.
  • Použijte zásadu CORS pro řízení webů, které mají povoleno načítat prostředky obsluhované prostřednictvím rozhraní API. Abyste se vyhnuli příliš permisivním konfiguracím, nepoužívejte v zásadách CORS zástupné kóty (*).
  • I když Má Azure ochranu na úrovni platformy i rozšířenou ochranu před útoky DDoS (Distributed Denial of Service), ochranu aplikací (vrstvy 7) pro rozhraní API je možné vylepšit nasazením služby ochrany robota před službou API Management – například brány Aplikace Azure lication Gateway, Azure Front Door nebo Azure DDoS Protection. Při použití zásad firewallu webových aplikací (WAF) se službou Aplikace Azure lication Gateway nebo Azure Front Door zvažte použití Microsoft_BotManagerRuleSet_1.0.

Autorizace na úrovni nefunkční funkce

Složité zásady řízení přístupu s různými hierarchiemi, skupinami a rolemi a nejasné oddělení mezi správou a běžnými funkcemi vedou k chybám autorizace. Když tyto problémy zneužijete, útočníci získají přístup k prostředkům jiných uživatelů nebo funkcím správy.

Další informace o této hrozbě: Autorizace na úrovni nefunkční funkce API5:2023

Doporučení

  • Ve výchozím nastavení můžete chránit všechny koncové body rozhraní API ve službě API Management pomocí klíčů předplatného nebo zásad autorizace na úrovni všech rozhraní API. Pokud je to možné, definujte další zásady autorizace pro konkrétní rozhraní API nebo operace rozhraní API.
  • Ověřte tokeny OAuth pomocí zásad.
    • K ověření tokenů Microsoft Entra použijte zásady validate-azure-ad-token . Zadejte všechny požadované deklarace identity a v případě potřeby zadejte autorizované aplikace.
    • Pro ověřování tokenů nevydávaných společností Microsoft Entra definujte zásadu validate-jwt a vynucujte požadované deklarace identity tokenů. Pokud je to možné, vyžadovat čas vypršení platnosti.
    • Pokud je to možné, použijte pro přístup šifrované tokeny nebo vypsat konkrétní aplikace.
    • Monitorujte a kontrolujte žádosti zamítnuté kvůli nedostatečné autorizaci.
  • Ke skrytí koncových bodů rozhraní API z internetu použijte virtuální síť Azure nebo Private Link. Přečtěte si další informace o možnostech virtuální sítě pomocí služby API Management.
  • Nedefinujte operace s rozhraním API se zástupnými cardy (to znamená "catch-all" API s * cestou). Zajistěte, aby služba API Management obsluhovala pouze požadavky na explicitně definované koncové body a požadavky na nedefinované koncové body byly odmítnuty.
  • Nepublikujte rozhraní API s otevřenými produkty , které nevyžadují předplatné.
  • Pokud jsou IP adresy klientů známé, použijte zásadu filtru IP, která povoluje provoz jenom z autorizovaných IP adres.
  • Pomocí zásad validate-client-certificate vynucujte, aby certifikát předaný klientem instanci služby API Management odpovídal zadaným ověřovacím pravidlům a deklaracím identity.

Neomezený přístup k citlivým obchodním tokům

Rozhraní API můžou uživatelům zpřístupnit širokou škálu funkcí. Je důležité, aby autoři rozhraní API porozuměli obchodním tokům, které rozhraní API poskytuje, a související citlivost. Existuje větší riziko pro firmu, pokud rozhraní API, která zveřejňují citlivé toky, neimplementují odpovídající ochranu.

Další informace o této hrozbě: API6:2023 Neomezený přístup k citlivým obchodním tokům

Doporučení

  • Omezte nebo zablokujte přístup na základě otisků prstů klienta. Použijte například zásadu návratové odpovědi s zvolenou zásadou k blokování provozu z bezobrazových prohlížečů na základě hlavičky User-Agent nebo konzistence jiných hlaviček.
  • Pomocí zásad validate-parameters vynucujte, aby hlavičky požadavků odpovídaly specifikaci rozhraní API.
  • Pomocí zásad filtru IP můžete povolit žádosti pouze ze známých IP adres nebo odepřít přístup z konkrétních IP adres.
  • Pomocí funkcí privátní sítě omezte externí připojení k interním rozhraním API.
  • Pomocí zásad omezování rychlosti podle klíče omezte špičky ve spotřebě rozhraní API na základě identity uživatele, IP adresy nebo jiné hodnoty.
  • Front API Management s Aplikace Azure lication Gateway nebo službou Azure DDoS Protection za účelem zjišťování a blokování provozu robota

Padělání požadavků na straně serveru

K ohrožení zabezpečení požadavku na straně serveru může dojít, když rozhraní API načte podřízený prostředek na základě hodnoty adresy URL, kterou volající rozhraní API předal bez odpovídajících kontrol ověření.

Další informace o této hrozbě: Padělání požadavků na straně serveru API7:2023

Doporučení

  • Pokud je to možné, nepoužívejte adresy URL zadané v datových částech klienta, například jako parametry pro back-endové adresy URL, zásady odesílání požadavků nebo zásady přepisování adresy URL .
  • Pokud služba API Management nebo back-endové služby používají adresy URL poskytované v datové části požadavku pro obchodní logiku, definujte a vynucujte omezený seznam názvů hostitelů, portů, typů médií nebo jiných atributů se zásadami ve službě API Management, jako jsou například volba zásad a výrazy zásad.
  • timeout Definujte atribut v zásadách forward-request a send-request.
  • Ověření a sanitizace dat požadavků a odpovědí pomocí zásad ověřování V případě potřeby použijte zásadu set-body ke zpracování odpovědi a vyhněte se vrácení nezpracovaných dat.
  • K omezení připojení použijte privátní sítě. Pokud například rozhraní API nemusí být veřejné, omezte připojení z internetu, abyste snížili prostor pro útok.

Chybná konfigurace zabezpečení

Útočníci se mohou pokusit zneužít chyby zabezpečení při chybné konfiguraci, například:

  • Chybějící posílení zabezpečení
  • Zbytečně povolené funkce
  • Síťová připojení se zbytečně otevírají k internetu
  • Použití slabých protokolů nebo šifer

Další informace o této hrozbě: Chybná konfigurace zabezpečení rozhraní API8:2023

Doporučení

  • Správně nakonfigurujte protokol TLS brány. Nepoužívejte zranitelné protokoly (například TLS 1.0, 1.1) nebo šifry.
  • Nakonfigurujte rozhraní API tak, aby přijímala šifrovaný provoz jenom prostřednictvím protokolů HTTPS nebo WSS. Toto nastavení můžete auditovat a vynutit pomocí služby Azure Policy.
  • Zvažte nasazení služby API Management za privátním koncovým bodem nebo připojeného k virtuální síti nasazené v interním režimu. V interních sítích lze přístup řídit z privátní sítě (prostřednictvím brány firewall nebo skupin zabezpečení sítě) a z internetu (přes reverzní proxy server).
  • Použití zásad služby Azure API Management:
    • Vždy dědit nadřazené zásady prostřednictvím značky <base> .
    • Pokud používáte OAuth 2.0, nakonfigurujte a otestujte zásadu validate-jwt , abyste před dosažením back-endu zkontrolovali existenci a platnost tokenu. Automaticky zkontrolujte čas vypršení platnosti tokenu, podpis tokenu a vystavitele. Vynucujte deklarace identity, cílové skupiny, vypršení platnosti tokenu a podpis tokenu prostřednictvím nastavení zásad. Pokud používáte Microsoft Entra, zásady validate-azure-ad-token poskytují komplexnější a jednodušší způsob ověřování tokenů zabezpečení.
    • Nakonfigurujte zásady CORS a nepoužívejte zástupný znak * pro žádnou možnost konfigurace. Místo toho explicitně vypisovat povolené hodnoty.
    • Nastavte zásady ověřování v produkčních prostředích tak, aby ověřily schémata JSON a XML, hlavičky, parametry dotazu a stavové kódy a vynutily maximální velikost požadavku nebo odpovědi.
    • Pokud je služba API Management mimo hranici sítě, je ověření IP adresy klienta stále možné pomocí zásad omezení IP adres volajícího. Ujistěte se, že používá seznam povolených, ne seznam blokovaných.
    • Pokud se mezi volajícím a službou API Management používají klientské certifikáty, použijte zásadu validate-client-certificate . Ujistěte se, že validate-revocationjsou všechny atributy , validate-trustvalidate-not-before, a validate-not-after atributy nastaveny na true.
  • Mezi službou API Management a back-endem je možné použít také klientské certifikáty (vzájemné tls). Back-end by měl:
    • Konfigurace přihlašovacích údajů pro autorizaci
    • Ověřte řetěz certifikátů tam, kde je to možné.
    • Ověřte název certifikátu, pokud je to možné.
    • Pro scénáře GraphQL použijte zásadu validate-graphQL-request . Ujistěte se, že authorization jsou nastavené elementy a max-size max-depth atributy.
  • Neukládejte tajné kódy do souborů zásad ani do správy zdrojového kódu. Vždy používejte pojmenované hodnoty služby API Management nebo načtěte tajné kódy za běhu pomocí výrazů vlastních zásad. Pojmenované hodnoty by měly být integrované se službou Azure Key Vault nebo šifrované ve službě API Management tím, že je označíte jako tajné. Tajné kódy nikdy neukládejte do pojmenovaných hodnot ve formátu prostého textu.
  • Publikujte rozhraní API prostřednictvím produktů, které vyžadují předplatná. Nepoužívejte otevřené produkty , které nevyžadují předplatné.
  • Ujistěte se, že vaše rozhraní API vyžadují klíče předplatného, i když jsou všechny produkty nakonfigurované tak, aby vyžadovaly klíče předplatného. Další informace
  • Vyžaduje schválení předplatného pro všechny produkty a pečlivě zkontrolujte všechny žádosti o předplatné.
  • Ke správě všech certifikátů použijte integraci služby Key Vault. To centralizuje správu certifikátů a může pomoct usnadnit úlohy správy operací, jako je obnovení certifikátu nebo odvolání. Použijte spravovanou identitu k ověření v trezorech klíčů.
  • Pokud používáte bránu v místním prostředí, ujistěte se, že existuje proces, který pravidelně aktualizuje image na nejnovější verzi.
  • Představují back-endové služby jako entity back-endu. Pokud je to možné, nakonfigurujte autorizační přihlašovací údaje, ověřování řetězu certifikátů a ověření názvu certifikátu.
  • Pokud je to možné, použijte správce přihlašovacích údajů nebo spravovanou identitu k ověření v back-endových službách.
  • Při použití portálu pro vývojáře:
    • Pokud se rozhodnete samoobslužně hostovat portál pro vývojáře, ujistěte se, že existuje proces, který pravidelně aktualizuje místní portál na nejnovější verzi. Aktualizace výchozí spravované verze jsou automatické.
    • Pro registraci a přihlášení uživatele použijte Microsoft Entra ID nebo Azure Active Directory B2C . Zakažte výchozí ověřování pomocí uživatelského jména a hesla, což je méně bezpečné.
    • Přiřaďte skupiny uživatelů k produktům, abyste mohli řídit viditelnost rozhraní API na portálu.
  • Azure Policy slouží k vynucení konfigurace na úrovni prostředků služby API Management a oprávnění řízení přístupu na základě role (RBAC) k řízení přístupu k prostředkům. Udělte každému uživateli minimální požadovaná oprávnění.
  • Použijte proces DevOps a přístup typu infrastruktura jako kód mimo vývojové prostředí, abyste zajistili konzistenci obsahu a změn konfigurace služby API Management a minimalizovali lidské chyby.
  • Nepoužívejte žádné zastaralé funkce.

Nesprávná správa inventáře

Mezi ohrožení zabezpečení související s nesprávnou správou prostředků patří:

  • Nedostatek správné dokumentace k rozhraní API nebo informací o vlastnictví
  • Nadměrný počet starších verzí rozhraní API, u kterých můžou chybět opravy zabezpečení

Další informace o této hrozbě: Rozhraní API9:2023 – Nesprávná správa inventáře

Doporučení

  • Jako zdroj pro import rozhraní REST API použijte dobře definovanou specifikaci OpenAPI. Specifikace umožňuje zapouzdření definice rozhraní API, včetně metadat samodokumentování.
  • Rozhraní API můžete používat s přesnými cestami, schématy dat, hlavičkami, parametry dotazu a stavovými kódy. Vyhněte se operacím se zástupnými cardy. Zadejte popis jednotlivých rozhraní API a operací a uveďte kontaktní a licenční informace.
  • Vyhněte se koncovým bodům, které přímo nepřispívají k obchodnímu cíli. Zbytečně zvětšují prostor pro útok a znesnadní vývoj rozhraní API.
  • Ke správě změn rozhraní API použijte revize a verze ve službě API Management. Mít silnou strategii správy verzí back-endu a potvrdit maximální počet podporovaných verzí rozhraní API (například 2 nebo 3 předchozí verze). Naplánujte si rychlé vyřazení a nakonec odebrání starších, často méně zabezpečených verzí rozhraní API. Ujistěte se, že jsou implementované kontrolní mechanismy zabezpečení napříč všemi dostupnými verzemi rozhraní API.
  • Samostatná prostředí (například vývoj, testování a produkční prostředí) s různými službami API Management. Zajistěte, aby se každá služba API Management připojovala ke svým závislostem ve stejném prostředí. Například v testovacím prostředí by se testovací prostředek služby API Management měl připojit k testovacímu prostředku služby Azure Key Vault a testovacím verzím back-endových služeb. Používejte automatizaci DevOps a postupy infrastruktury jako kódu, které pomáhají udržovat konzistenci a přesnost mezi prostředími a snižovat lidské chyby.
  • Izolujte oprávnění správce k rozhraním API a souvisejícím prostředkům pomocí pracovních prostorů.
  • Pomocí značek uspořádejte rozhraní API a produkty a seskupte je pro publikování.
  • Publikujte rozhraní API ke spotřebě prostřednictvím portálu pro vývojáře. Ujistěte se, že je dokumentace k rozhraní API aktuální.
  • Seznamte se s nespravovanými nebo nespravovanými rozhraními API a zpřístupněte je prostřednictvím služby API Management, aby bylo lepší řízení.
  • Azure API Center umožňuje udržovat komplexní centralizovaný inventář rozhraní API, verzí a nasazení, i když se rozhraní API nespravují ve službě Azure API Management.

Nebezpečná spotřeba rozhraní API

Prostředky získané prostřednictvím podřízených integrací mají tendenci být více důvěryhodné než vstup rozhraní API od volajícího nebo koncového uživatele. Pokud nejsou použity vhodné sanitizace a standardy zabezpečení, rozhraní API může být zranitelné, i když je integrace poskytována prostřednictvím důvěryhodné služby.

Další informace o této hrozbě: Rozhraní API10:2023 Nebezpečné využití rozhraní API

Doporučení

  • Zvažte použití služby API Management k tomu, aby fungovalo jako fasáda pro podřízené závislosti, se kterými se back-endová rozhraní API integrují.
  • Pokud jsou podřízené závislosti fronty se službou API Management nebo pokud se podřízené závislosti využívají se zásadami odesílání žádostí ve službě API Management, využijte doporučení z jiných částí této dokumentace k zajištění jejich bezpečné a řízené spotřeby, včetně:
    • Ujistěte se, že je povolený zabezpečený přenos, a vynucujte konfiguraci protokolu TLS/SSL.
    • Pokud je to možné, ověřte se pomocí správce přihlašovacích údajů nebo spravované identity.
    • Řízení spotřeby pomocí zásad rate-limit-by-key a kvót-limit-by-key
    • Protokolování nebo blokování odpovědí, které nedodržují specifikaci rozhraní API, s využitím zásad ověření obsahu a hlavičky validate
    • Transformace odpovědí pomocí zásad těla sady, například odebrání nepotřebných nebo citlivých informací
    • Konfigurace časových limitů a omezení souběžnosti

Související obsah

Přečtěte si další informace: