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

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 doporučení pro použití služby Azure API Management ke zmírnění 10 hlavních hrozeb rozhraní API identifikovaných OWASP.

Poznámka:

Kromě doporučení v tomto článku můžete povolit Defender for API, funkci Microsoft Defenderu pro cloud, přehledy zabezpečení rozhraní API, doporučení a detekci hrozeb. Další informace o používání defenderu pro rozhraní API se službou API Management

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:2019

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 žádosti o odeslání.

  • Ve scénářích GraphQL pomocí elementu vynucujte autorizaci na úrovni objektu authorize prostřednictvím zásad ověření požadavku GraphQL.

Nefunkční ověřování uživatelů

Mechanismy ověřování se často implementují nesprávně nebo chybí, což útočníkům umožňuje zneužít chyby implementace pro přístup k datům.

Další informace o této hrozbě: Rozhraní API2:2019 Poškozené ověřování uživatelů

Doporučení

Použití služby API Management pro ověřování a autorizaci uživatelů:

  • Ověřování – API Management podporuje následující metody ověřování:

    • Základní zásady ověřování – přihlašovací údaje pro uživatelské jméno a heslo

    • Klíč předplatného – Klíč předplatného poskytuje podobnou úroveň zabezpečení jako základní ověřování a nemusí být dostačující. Pokud dojde k ohrožení klíče předplatného, může útočník získat neomezený přístup k systému.

    • Zásady klientského certifikátu – Použití klientských certifikátů je bezpečnější než základní přihlašovací údaje nebo klíč předplatného, ale neumožňuje flexibilitu poskytovanou autorizačními protokoly založenými na tokenech, jako je OAuth 2.0.

  • Autorizace – API Management podporuje ověřenou zásadu JWT , která kontroluje platnost příchozího přístupového tokenu OAuth 2.0 JWT na základě informací získaných z koncového bodu metadat zprostředkovatele identity OAuth. Nakonfigurujte zásadu tak, aby kontrolovali relevantní deklarace identity tokenů, cílovou skupinu a čas vypršení platnosti. Přečtěte si další informace o ochraně rozhraní API pomocí autorizace OAuth 2.0 a ID Microsoft Entra.

Další doporučení:

  • Pomocí zásad ve službě API Management zvyšte zabezpečení. Omezování rychlosti volání například zpomalí chybné aktéry pomocí útoků hrubou silou k ohrožení přihlašovacích údajů.

  • Rozhraní API by měla k ochraně přihlašovacích údajů nebo tokenů používat protokol TLS/SSL (zabezpečení přenosu). Přihlašovací údaje a tokeny by se měly odesílat v hlavičkách požadavků, a ne jako parametry dotazu.

  • Na portálu pro vývojáře služby API Management nakonfigurujte Id Microsoft Entra nebo Azure Active Directory B2C jako zprostředkovatele identity, abyste zvýšili zabezpečení účtu. Portál pro vývojáře používá CAPTCHA ke zmírnění útoků hrubou silou.

Nadměrné vystavení dat

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íjela, rozhraní požadavků a odpovědí obsahují více datových polí, než vyžadují náročné aplikace.

Chybný objekt actor by se mohl pokusit o přímý přístup k rozhraní API (třeba přehráním platného požadavku) nebo zašifrovat provoz mezi serverem a rozhraním API. Analýzaakcíchm technologiím (API) a dostupných dat by mohla útočníkovi přinést citlivá data, která se nenachází ani nepoužívá.

Další informace o této hrozbě: ROZHRANÍ API3:2019 Nadměrné vystavení dat

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žijte:

    • Revize pro řádné řízení nerušených změn, například přidání pole do rozhraní. Revize můžete použít společně s implementací správy verzí v back-endu.

    • Verze zásadních změn, například odebrání pole z rozhraní.

  • 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. Odeberte například nepotřebné vlastnosti JSON z textu odpovědi.

  • Ověření obsahu odpovědi ve službě API Management lze použít se schématem XML nebo JSON k blokování odpovědí s nezdokumentovanými vlastnostmi nebo nesprávnými hodnotami. Zásady také podporují blokování odpovědí překračujících zadanou velikost.

  • Pomocí zásady ověření stavového kódu zablokujte odpovědi s chybami nedefinovanými ve schématu rozhraní API.

  • Pomocí zásad ověření hlaviček 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 sady.

  • Ve scénářích GraphQL použijte zásadu ověření požadavku GraphQL k ověření požadavků GraphQL, autorizaci přístupu ke konkrétním cestám dotazů a omezení velikosti odpovědi.

Nedostatek zdrojů a omezování rychlosti

Nedostatek omezování rychlosti může vést k exfiltraci dat nebo úspěšným útokům DDoS na back-endové služby, což způsobí výpadek pro všechny uživatele.

Další informace o této hrozbě: ROZHRANÍ API4:2019 Nedostatek prostředků a omezování rychlosti

Doporučení

  • K řízení povoleného počtu volání rozhraní API nebo šířky pásma na uživatele použijte zásady omezení rychlosti (krátkodobé) a kvóty (dlouhodobé).

  • Definujte přísné definice objektu požadavku a jejich vlastnosti v definici OpenAPI. Například definujte maximální hodnotu pro stránkování celých čísel, maxLength a regulární výraz (regex) pro řetězce. Vynucujte tato schémata pomocí zásad ověření obsahu a ověření parametrů ve službě API Management.

  • Vynucujte maximální velikost požadavku pomocí zásad ověření obsahu .

  • 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.

  • Vynucujte ověřování pro volání rozhraní API (viz Přerušené ověřování uživatelů). Odvolá přístup pro zneužívající uživatele. Například deaktivujte klíč předplatného, zablokujte IP adresu pomocí zásad omezení IP adres volajícího nebo odmítněte žádosti o určitou deklaraci identity uživatele z tokenu JWT.

  • 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 (*).

  • 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 sníží počet požadavků, které je možné obsložovat v daném časovém rámci.

    • Definujte timeout v zásadách předávací žádosti .

    • Použijte zásadu ověření požadavků GraphQL pro rozhraní GraphQL API a nakonfigurujte max-depth a max-size parametry.

    • Omezte počet paralelních back-endových připojení pomocí zásad souběžnosti limitu.

  • I když služba API Management dokáže chránit back-endové služby před útoky DDoS, může být zranitelná vůči samotným útokům. Nasaďte službu ochrany robota před službou API Management (například Aplikace Azure Gateway, Azure Front Door nebo Azure DDoS Protection), abyste lépe chránili před útoky DDoS. Při použití WAF se službou Aplikace Azure 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:2019

Doporučení

  • Ve výchozím nastavení chraňte všechny koncové body rozhraní API ve službě API Management pomocí klíčů předplatného.

  • Definujte ověřené zásady JWT a vynucujte požadované deklarace identity tokenů. Pokud některé operace vyžadují přísnější vynucování deklarací identity, definujte pro tyto operace jenom další validate-jwt zásady.

  • 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é.

Hromadné přiřazení

Pokud rozhraní API nabízí více polí, než klient vyžaduje pro danou akci, může útočník vložit nadměrné vlastnosti k provádění neautorizovaných operací s daty. Útočníci mohou zjišťovat nezdokumentované vlastnosti kontrolou formátu požadavků a odpovědí nebo jiných rozhraní API nebo jejich odhadem. Toto ohrožení zabezpečení je zvlášť použitelné, pokud nepoužíváte programovací jazyky silného typu.

Další informace o této hrozbě: Rozhraní API6:2019 Hromadné přiřazení

Doporučení

  • Rozhraní externího rozhraní API by měla být oddělená od interní implementace dat. Vyhněte se vazbám kontraktů rozhraní API přímo na datové kontrakty v back-endových službách. Projděte si často návrh rozhraní API a zastaráte a odeberte starší vlastnosti pomocí správy verzí ve službě API Management.

  • Přesně definujte kontrakty XML a JSON ve schématu rozhraní API a použijte zásady ověření obsahu a ověření parametrů k blokování požadavků a odpovědí s nezdokumentovanými vlastnostmi. 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.

  • Pokud back-endové rozhraní nejde změnit, použijte zásady transformace k přepsání datových částí požadavků a odpovědí a oddělení kontraktů rozhraní API od back-endových kontraktů. Můžete například maskovat nebo filtrovat data nebo odebrat nepotřebné vlastnosti JSON.

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í
  • Nepotřebné povolené funkce
  • Síťová připojení se zbytečně otevírají k internetu
  • Použití slabých protokolů nebo šifer
  • Jiná nastavení nebo koncové body, které můžou povolit neoprávněný přístup k systému

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

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.

  • 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> .

    • Při použití OAuth 2.0 nakonfigurujte a otestujte ověřené zásady JWT , abyste před dosažením back-endu zkontrolovali existenci a platnost tokenu JWT. 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.

    • 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í tak, aby prevent v produkčních prostředích 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 ověření klientského certifikátu . 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é.

  • Ve scénářích GraphQL použijte zásadu ověření požadavku GraphQL. Ujistěte se, že authorization jsou nastavené elementy a max-sizemax-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 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é.

  • Integrace služby Key Vault slouží ke správě všech certifikátů – to centralizuje správu certifikátů a může pomoct usnadnit úlohy správy operací, jako je obnovení certifikátu nebo odvolání.

  • 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.

  • 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.

Injekce

Jakýkoli koncový bod, který přijímá uživatelská data, je potenciálně ohrožený zneužitím injektáže. Mezi příklady patří:

  • Injektáž příkazů, kdy se chybný objekt actor pokusí změnit požadavek rozhraní API na spouštění příkazů v operačním systému, který je hostitelem rozhraní API

  • Injektáž SQL, kdy se chybný objekt actor pokusí změnit požadavek rozhraní API na spouštění příkazů a dotazů v databázi, na které rozhraní API závisí

Další informace o této hrozbě: Injektáž rozhraní API8:2019

Doporučení

  • Moderní zásady firewallu webových aplikací (WAF) pokrývají řadu běžných ohrožení zabezpečení injektáže. I když služba API Management nemá integrovanou komponentu WAF, důrazně doporučujeme nasadit upstreamovou instanci SLUŽBY API Management (frontu). Použijte například Aplikace Azure Gateway nebo Azure Front Door.

    Důležité

    Ujistěte se, že chybný objekt actor nemůže obejít bránu hostující WAF a připojit se přímo k bráně služby API Management nebo samotnému back-endovému rozhraní API. Mezi možná omezení rizik patří seznamy ACL sítě, použití zásad služby API Management k omezení příchozího provozu podle IP adresy klienta, odebrání veřejného přístupu, pokud není vyžadováno, a ověřování klientských certifikátů (označované také jako vzájemné tls nebo mTLS).

  • Pokud je to možné, použijte zásady ověřování schématu a parametrů k dalšímu omezení a ověření požadavku před tím, než dosáhne služby back-endového rozhraní API.

    Schéma dodané s definicí rozhraní API by mělo mít omezení vzoru regex použité u ohrožených polí. Každý regulární výraz by měl být testován, aby se zajistilo, že pole dostatečně omezuje, aby se zmírnit běžné pokusy o injektáž.

Nesprávná správa prostředků

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:2019 – Nesprávná správa prostředků

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.

  • Pomocí revizí a verzí ve službě API Management můžete řídit a řídit koncové body rozhraní API. 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.

  • Použijte instanci služby API Management pro každé prostředí (například vývoj, testování a produkční prostředí). Zajistěte, aby se každá instance služby 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.

  • Pomocí značek uspořádejte rozhraní API a produkty a seskupte je pro publikování.

  • Publikujte rozhraní API pro spotřebu prostřednictvím integrovaného portálu pro vývojáře. Ujistěte se, že dokumentace k rozhraní API je 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í.

Nedostatečné protokolování a monitorování

Nedostatečné protokolování a monitorování, které je spojeno s chybějící nebo neefektivní integrací s reakcí na incidenty, umožňuje útočníkům další systémy útoku, udržovat trvalost, přecháhat na více systémů, které se mají manipulovat, a extrahovat nebo zničit data. Většinastudiích studií ukazuje, že doba zjištění porušení zabezpečení je přes 200 dnů, obvykle je zjištěná externími stranami, nikoli interními procesy nebo monitorováním.

Další informace o této hrozbě: ROZHRANÍ API10:2019 – Nedostatečné protokolování a monitorování

Doporučení

Další kroky

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