NEJLEPŠÍ POSTUPY ZABEZPEČENÍ API
Úvod
API jsou zásadní pro obchodní úspěch. Je třeba se zaměřit na zajištění jejich spolehlivosti a bezpečnosti. Většina respondentů průzkumu Salt Security z roku 2021 uvedla, že zpozdili spuštění aplikace kvůli Zabezpečení API obavy.
Top 10 bezpečnostních rizik API
1. Nedostatečné protokolování a monitorování
Když se útočník pokusí dostat do systému, generuje nepravidelný provoz. Používají metodu hrubého vynucení vaší autentizace proti vašim vstupům.
2. Nesprávná správa aktiv
Rozhraní API mívají více koncových bodů než tradiční webové aplikace. Rozhodující je řádná a aktuální dokumentace. Aby nedošlo k zastaralosti API verzí a vystavených hostitelů byste měli spravovat hostitele a dané verze API. Měli byste se pokusit snížit koncové body ladicího programu.
3. Injekce
K chybám zabezpečení, jako je SQL nebo vkládání příkazů, dochází, když jsou nedůvěryhodná data odeslána přímo interpretu jako součást dotazu nebo příkazu. V důsledku toho mohou útočníci oklamat tlumočníka, aby provedl nezamýšlené příkazy nebo získal přístup k datům bez příslušného oprávnění.
4. Chybná konfigurace zabezpečení
Špatné konfigurace zabezpečení jsou často způsobeny nezabezpečenými výchozími konfiguracemi.
- Neúplné konfigurace ad hoc
- Otevřete cloudové úložiště
- Špatně nakonfigurované hlavičky HTTP
- Zbytečně povolené metody HTTP
- Sdílení zdrojů z různých zdrojů
- Výstup podrobných chybových zpráv obsahujících bezpečnostní informace informace
5. Hromadné zadání
Hromadné přiřazení nastává, když vazba klienta na datové modely bez řádného filtrování vlastností vede k hromadnému mapování. Útočníci mohou měnit vlastnosti objektů jejich uhodnutím.
6. Oprávnění na úrovni poškozené funkce
Poškozená autorizace na úrovni funkcí může nastat, pokud existují složité zásady řízení přístupu s různými hierarchiemi, skupinami a rolemi. Nejasné oddělení mezi administrátorskými a uživatelskými funkcemi vede k nedostatkům v autorizaci. Útočníci mohou získat přístup ke zdrojům jiných uživatelů nebo k funkcím správy.
7. Přerušené ověření uživatele
Autentizační mechanismy často umožňují útočníkům kompromitovat ověřovací tokeny nebo zneužít chyby implementace k dočasnému nebo trvalému vydávání se za jiné uživatele.
8. Nadměrné vystavení údajům
Pokud jde o obecné použití API, vývojáři mají tendenci zveřejňovat všechny atributy objektů. Vývojáři mohou odhalit atributy objektů, pokud neberou v úvahu důvěrnost. Nadměrné vystavení údajům může být způsobeno tím, že se na straně klienta spoléháte na filtrování údajů, než se zobrazí uživateli.
9. Nedostatek zdrojů a omezení sazeb
Klient nebo uživatel může být požádán. Nejen, že nedostatek zdrojů a omezení rychlosti může ovlivnit výkon serveru API a vést k útokům typu odmítnutí služby, ale také ponechává možnost slabých stránek ověřování.
10. Oprávnění na úrovni poškozeného objektu
Rozhraní API mají tendenci odhalovat koncové body, které zpracovávají identifikátory objektů, a vytvářejí tak velký útočný prostor v řízení přístupu. Kontroly autorizace na úrovni objektu by měly zahrnovat funkce, které přistupují ke zdroji dat prostřednictvím vstupu od uživatele.
Jak zabezpečit SOAP API
SOAP je specifikace protokolu, který komunikuje s webovými stránkami. Jedná se o průmyslový standard W3C, formát XML. SOAP implementuje předávání stavových zpráv. SOAP se integruje s protokoly WS-Security. SOAP může zaručit integritu a důvěrnost zpracovávaných transakcí s větším šifrováním. Díky použití XML je SOAP nejpodrobnějším stylem API.
SOAP je specifikace protokolu, který komunikuje s webovými stránkami. Jedná se o průmyslový standard W3C, formát XML. SOAP implementuje předávání stavových zpráv. SOAP se integruje s protokoly WS-Security. SOAP může zaručit integritu a důvěrnost zpracovávaných transakcí s větším šifrováním. Díky použití XML je SOAP nejpodrobnějším stylem API.
Jak zabezpečit Rest API
REST je styl architektury API. REST je jednoduché rozhraní pro přenos informací. Při odesílání dat nedochází k žádné fázi konverze. Informace zasílané v originální podobě mají příznivý vliv na vytížení klienta. Data jsou ve formátu JSON nebo XML.
RESTful architektonické požadavky:
- Neobsahuje stav (bezstátní)
- Ukládání do mezipaměti.
- Společné rozhraní: Umožňuje konzistentní interakci s webovým serverem nezávislou na aplikaci.
V REST používá veškerá komunikace metody HTTP: GET, POST, PUT, PATCH a DELETE. REST se používá jako rozhraní API pro správu pro CRUD (Create, Read, Update, and Delete). Nainstalujte interakci se zdroji v odlehčených škálovatelných službách. Zdroj je obvykle objekt datového modelu.
Vytvoření bezpečných RESTful API také ukládá určité standardní požadavky:
- Použití protokolu HTTPS: kryptografický provoz zajišťuje integritu přenášených dat.
- Rate-limits: Je nutné zkontrolovat vytížení API. Zahození požadavků v případě přetížení
- Autentizace: Identifikace uživatele / aplikace / zařízení.
- Protokol auditu: Záznam akcí vytvořením záznamu v souboru protokolu.
- Řízení přístupových práv: Stanovení přístupových práv pro práci se zdroji.
- Přístup k obchodní logice aplikace.
Je záměrné, že REST API neuchovává žádné záznamy. Existuje omezení přístupu přes místní koncové body. Při práci s architekturou REST. Je obvyklé rozlišovat dvě úrovně zabezpečení:
- První úroveň – získání přístupu k API
- Druhá úroveň – získání přístupu k aplikaci
Jak zabezpečit API
Pro zajištění bezpečnosti API by organizace měly věnovat velkou pozornost následujícím oblastem.
- Řízení přístupu
- API ochrana
- Ochrana proti ohrožení
Vzor brány API
Nejlepším bezpečnostním postupem je přesunout odpovědnost za zabezpečení na bránu API. Brána API se nachází mezi backendem API a spotřebiteli. Zachytí všechny požadavky spotřebitelů a bude spravovat bezpečnostní aspekty.
Vývojáři API se mohou zaměřit na funkce API obchodní logiky. Brána API spravuje zabezpečení a řízení přístupu.
API řízení přístupu
Řízení přístupu k API se týká procesu určování, kdo má přístup ke kterým rozhraním API. Jaké funkce těchto rozhraní API používají jiné aplikace.
Ověřování jde o identifikaci entity požadující přístup k API. Identifikace je buď ověření, zda uživatel zná heslo.
Základní ověřování
Tato metoda používá proces ověřování HTTP. Pověření uživatele jsou kódována pomocí algoritmu base64. HTTP hlavička se připojí při odesílání požadavku.
Základní autentizace nestačí k ochraně API proti všem komplexním bezpečnostním útokům. Alespoň dva lidé musí sdílet uživatelské jméno a heslo. Třetí strana má přístup k zabezpečené službě přístupem k přihlašovacím údajům. OAuth řeší tyto chyby zabezpečení.
Token OAuth
OAuth používá přístupový token. Pověření nejsou sdílena přímým způsobem. Tento token má životnost. To znamená, že ani tento token není věčný. Tím se snižuje riziko krádeže. Token používá obory. Přístup ke zdrojům na základě rolí přiřazených uživateli. Proto je OAuth pro zabezpečení API mnohem bezpečnější než heslo.
Autentizace založená na OIDC
OIDC – OpenID Connect. Toto ověření slouží k ověření identity koncového uživatele. Je založeno na autentizaci prováděné autorizačním serverem. Získává podrobnosti o profilu uživatele pomocí mechanismu podobného REST.
Autentizace založená na klíči API
Klíč API je řetězcová hodnota předaná klientskou aplikací bráně APIM. Klíč klienta ukládá informace do databáze aplikace. Server ověří identitu klienta. Když se uživatel zaregistruje, program vygeneruje klíč.
Tato strategie brání nežádoucímu přístupu. Chcete-li omezit počet požadavků API. Klíč API má několik způsobů, mimo jiné jako parametr dotazu, v záhlaví dotazu a jako hodnotu souboru cookie.
Autentizace na základě souborů cookie
Metoda kontroly obsahu cookies uchovává všechny informace o relaci. Uživatel zahájí požadavek na přihlášení. Odešle odpověď po přihlášení uživatele. V záhlaví této odpovědi je pole Set-Cookies. Toto pole obsahuje informace o:
- název pole cookie
- hodnotu pole cookie
- jak dlouho cookie vydrží
Až bude příště uživatel potřebovat přístup k API. Předá hodnotu uloženého pole cookie JSESSIONID s klíčem „Cookie“ v hlavičce požadavku.
Token-Based Authentication
Tento token je poté odeslán na server v záhlaví autorizačního dotazu. Po obdržení tokenu jej server ověří. Server sám generuje tokeny pro nové uživatele. Klíč, na rozdíl od tokenů, může umožnit přístup pouze k voláním API bez možnosti získat data uživatele.
Webové tokeny JSON (JWT)
Mechanismus ověřování založený na použití speciálního typu tokenu. Jedná se o datovou strukturu JSON. Token tohoto typu má hlavičku obsahující obecné informace. Tělo obsahuje užitečné zatížení (ID uživatele, skupina, data) a kryptografický podpis.
Tento přístup je optimálním způsobem, jak omezit přístup k REST API. Je to jeden z nejbezpečnějších mechanismů pro odesílání dat mezi dvěma stranami.
JWT je primární technika řízení přístupu pro vytvořenou aplikaci. Služba se nespoléhá na zdroje třetích stran. Tokeny se snadno používají, mají pohodlný formát popisu dat.
Použití protokolu HTTPS v kombinaci s kryptografickým podpisem poskytuje vysokou úroveň zabezpečení.
Při zabezpečení webové služby si zvláštní pozornost zaslouží kontrola vstupu. Musíte zajistit, aby veškerá data, na kterých bude aplikace fungovat, splňovala standard API.
Komunita vývojářů vytvořila několik doporučení při ověřování vstupních dat:
- Provádět ověřování dat jak na straně klienta, tak na straně serveru
- Chcete-li zavést seznam povolených serverů, měli byste používat vestavěné funkce
- Vždy je nutné zkontrolovat typ obsahu, velikost a délku dotazu
- Místo ručních dotazů do databáze na backendu používejte parametrizované dotazy
- Chcete-li využít seznam povolených serverů
- Chcete-li vést záznamy o chybách a sledovat pokusy o fuzz datových vstupů
Povolení
Účelem autorizace je určit úrovně přístupu.
Řízení přístupu založené na XACML
XACML je deklarativní jazyk politiky řízení přístupu založený na XML, založený na XML. Může poskytnout standardizovaný způsob ověřování žádostí o autorizaci. Definuje zásady řízení přístupu.
Otevřete Policy Agent OPA
OPA je open source, univerzální nástroj politiky. OPA bude specifikovat politiku jako kód a jednoduchá rozhraní API pro odlehčení rozhodování o politice. Rozhodnutí o politice jsou generována vyhodnocením vstupu dotazu a oproti datům. Tato rozhodnutí o zásadách určí, kteří uživatelé budou mít přístup ke zdrojům.
Speedle+
Speedle+ je projekt s otevřeným zdrojovým kódem, který řeší požadavky na řízení přístupu. Externalizujte logiku řízení přístupu do modulu zásad pomocí mechanismu řízení přístupu.
Omezení rychlosti
Povolení neomezeného přístupu k rozhraním API není dobrou praxí. Nejlepším řešením je mít mechanismus omezující sazby.
Omezení rychlosti pro ochranu rozhraní API bude užitečné následujícími způsoby:
- Zabránit útokům DDoS – Zabránění útočníkům zahltit síť tak velkým provozem.
- Zaveďte plány využití API – to bude výhodné při monetizaci API.
- Prosazovat zásady spravedlivého využití – Nikdo nemůže spotřebovat všechny přidělené zdroje nebo šířku pásma.
- Zabraňte nadměrnému používání systému – se správným omezením rychlosti. Je možné chránit API a backend před náhlým nadměrným používáním a špičkami požadavků.
Proč investovat do čističky vzduchu?
Rozhraní API jsou nyní nezbytná při vývoji moderního internetu a digitálních aplikací. Aplikace, služby a softwarové platformy je mohou používat k uspořádání interakcí. RESTinterfaces tvoří více než 80 % všech veřejných a proprietárních API. Přečtěte si náš článek o tom, CO JE API, abyste lépe porozuměli významným rozdílům mezi REST a SOAP API.
