262-000177-001 OWASP Top 10 pro zabezpečení API
“
Informace o produktu
Specifikace
- Název produktu: Průvodce vývojáře k žebříčku OWASP Top 2023 pro API pro rok 10
Zabezpečení - Obsah: Tahák k zabezpečení API, Definice a podrobné informace
Průvodci pro OWASP Top 2023 pro zabezpečení API pro rok 10
Návod k použití produktu
Úvod do zabezpečení API
Průvodce pro vývojáře poskytuje komplexní informace o
OWASP Top 2023 pro zabezpečení API za rok 10, s důrazem na společné zabezpečení
rizika při vývoji aplikací s API.
Tahák zabezpečení API
Tahák uvádí následující kategorie zabezpečení API
rizika:
- Autorizace na úrovni poškozeného objektu
- Nefunkční ověřování
- Autorizace na úrovni vlastností poškozeného objektu
- Neomezená spotřeba zdrojů
- Autorizace na úrovni přerušené funkce
- Neomezený přístup k citlivým obchodním tokům
- Padělání požadavků na straně serveru
- Nesprávná konfigurace zabezpečení
- Nesprávné řízení zásob
- Nebezpečná konzumace API
Průvodce pro vývojářeview
Průvodce se ponoří do každé kategorie bezpečnostních rizik API a poskytne
podrobná vysvětlení a pokyny, jak řešit a zmírňovat
tato rizika efektivně.
Často kladené otázky (FAQ)
Otázka: Proč je zabezpečení API důležité?
A: Zabezpečení API je klíčové, protože API často zpřístupňují citlivá data.
a aplikační logiku, což z nich činí hlavní cíle útočníků.
Zabezpečení API je nezbytné pro prevenci úniků dat a
zajištění celkové bezpečnosti systému.
Otázka: Jak mohu implementovat zabezpečená API?
A: Pro implementaci zabezpečených API dodržujte osvědčené postupy, jako například
správné ověřování, autorizační mechanismy, validace vstupů,
šifrování citlivých dat a pravidelné bezpečnostní kontroly a
aktualizace.
“`
BÍLÁ KNIHA
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
Obsah
Tahák zabezpečení API
5
Definice
5
API1:2023 – Autorizace na úrovni poškozeného objektu
7
API2:2023 – Porušené ověřování
8
API3:2023–Autorizace na úrovni vlastností poškozeného objektu
9
API4:2023 – Neomezená spotřeba zdrojů
11
API5:2023 – Autorizace na úrovni nefunkční funkce
13
API6:2023 – Neomezený přístup k citlivým obchodním tokům
14
API7:2023–Padělání požadavků na straně serveru
16
API8:2023–Nesprávná konfigurace zabezpečení
18
API9:2023 – Nesprávné řízení zásob
19
API10:2023 – Nebezpečná konzumace API
21
Top 10 zabezpečení API nestačí!
23
Závěr
23
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
2/23
Vzhledem k tomu, že firmy zavedly cloudovou nativní infrastrukturu a metodiky ve stylu DevOp, web Rozhraní pro programování aplikací neboli API se rozšířila. Mezi nejoblíbenější veřejná API patří ta, která vývojářům umožňují přístup k Vyhledávání Google, získávání dat z TikToku, sledování vozidel, shromažďování sportovních výsledků a dat o stahování obrázků z populárních webů.1 V roce 2023 představoval provoz související s API 58 procent veškerého dynamického provozu – definovaného jako provoz neuložitelný do mezipaměti – oproti 54 procentům na konci roku 2021.2
API se stala způsobem, jakým mohou podnikové aplikace komunikovat a integrovat se navzájem. Společnosti používají přibližně dvě třetiny svých API (64 %) k propojení svých aplikací s partnery, zatímco zhruba polovina (51 %) tvoří přístupové body k mikroslužbám. Celkově více než tři čtvrtiny firem používají v průměru alespoň 25 API na aplikaci.3
Zavedení aplikační infrastruktury založené na API by nemělo být žádným překvapením: Společnosti, které zavádějí API, aby přilákaly vývojáře třetích stran a vytvořily ekosystémy, zaznamenávají zvýšený růst. Tyto „obrácené firmy“ – nazývané tak proto, že obracejí tradiční koncepty vytváření bariér kolem technologií a umožňují otevřený přístup k některým funkcím a datům – vzrostly za dva roky o téměř 13 procent a za 39 let o 16 procent ve srovnání s firmami, které API nezavedly, uvádí studie výzkumníků z Chapmanovy univerzity a Bostonské univerzity z roku 2022
S přijetím mikroslužeb, kontejnerizace a API však přichází řada rizik, jako jsou nezabezpečené softwarové komponenty, špatná obchodní logika a chybné zabezpečení dat. Devět z deseti organizací (92 %) utrpělo alespoň jeden bezpečnostní incident související s nezabezpečenými API.5 Velké společnosti obvykle mají tisíce API a útoky na tyto systémy představují přibližně 20 procent bezpečnostních incidentů, zatímco menší společnosti mají stovky API, jejichž menší oblast útoku představuje pět procent bezpečnostních incidentů.6 Roční ztráty v důsledku narušení bezpečnosti způsobených zranitelnostmi API přesahují celosvětově 40 miliard dolarů, uvádí odhad Marshe McLennana.7
1 Arellano, Kelly. 50 nejoblíbenějších API. Blog RapidAPI. RapidAPI. Web Strana. 16. března 2023.
2 Tremante, Michael a kol. Zpráva o zabezpečení aplikací: 2. čtvrtletí 2023. Blog Cloudflare. Cloudflare. Příspěvek na blogu. 21. srpna 2023.
3 body, Melinda. Zabezpečení povrchu pro útok API. Enterprise Strategy Group. Sponzorováno společností Palo Alto Networks. PDF Report, str. 10. 23. května 2023.
4 Benzell, Seth G. a kol. Jak API vytvářejí růst inverzí firmy. Social Science Research Network. Výzkumná práce. Revidováno: 30. prosince 2022.
5 Zabezpečení povrchu pro útoky na API. Enterprise Strategy Group, str. 14. 6 Lemos, Robert. Ztráty na zabezpečení API dosahují miliard, ale je to složité. Dark Reading.
Článek v tisku. 30. června 2022. 7 Marsh McLennan. Kvantifikace nákladů na nejistotu API. Sponzorováno společností Imperva.
Zpráva ve formátu PDF. 22. června 2022.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
3/23
Seznam 2023 nejbezpečnějších API pro rok 10 upozorňuje na deset nejčastějších a nejzávažnějších bezpečnostních rizik vznikajících při vývoji aplikací, které zpřístupňují nebo používají API.
Problém je tak vážný, že se Národní bezpečnostní agentura USA spojila s Australským centrem pro kybernetickou bezpečnost (ACSC) a Americkou agenturou pro kybernetickou bezpečnost a bezpečnost infrastruktury (CISA), aby poskytla poradenství ohledně bezpečnostních problémů API, zejména těch nejběžnějších, známých jako zranitelnosti typu nezabezpečené přímé odkazy na objekty (IDOR).8
Není divu, že na pozadí rostoucích bezpečnostních obav vydal projekt Open Worldwide Application Security Project (OWASP) aktualizaci svého seznamu 10 nejbezpečnějších aplikací v oblasti zabezpečení API. Seznam 2019 nejbezpečnějších aplikací v oblasti zabezpečení API pro rok 2023, který aktualizuje svůj první seznam z roku 10, zdůrazňuje deset nejčastějších a nejzávažnějších bezpečnostních rizik vznikajících při vývoji aplikací, které zpřístupňují nebo používají API. Problémy, jako je například „Broken Object-Level Authorization“ (neporušená autorizace na úrovni objektů), nadmnožina zahrnující zranitelnosti IDOR, zůstávají stejné jako v předchozím seznamu. Nové kategorie – nebo reorganizované kategorie – však nyní zdůrazňují problémy, které byly v minulosti přehlíženy, jako je například Server-Side Request Forgery (Padělání požadavků na straně serveru) (API7:2023) a Neomezený přístup k citlivým obchodním tokům (API6:2023).
„Rozhraní API ze své podstaty zpřístupňují logiku aplikací a citlivá data, jako jsou osobně identifikovatelné informace (PII), a proto se stále častěji stávají cílem útočníků,“ uvedla skupina OWASP ve svém oznámení.9 „Bez bezpečných rozhraní API by rychlé inovace nebyly možné.“
8 nových varování ohledně kybernetické bezpečnosti Web Zranitelnosti aplikací. Národní bezpečnostní agentura. Tisková zpráva. 27. července 2023.
9. Otevřený celosvětový projekt zabezpečení aplikací. OWASP API Security Top 10: Forward. OWASP.org. Web Strana. 3. července 2023.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
4/23
Tahák zabezpečení API
Kategorie OWASP Top 10 1. Porušená autorizace na úrovni objektu 2. Porušené ověřování 3. Porušená autorizace na úrovni vlastnosti objektu 4. Neomezená spotřeba zdrojů 5. Porušená autorizace na úrovni funkce 6. Neomezený přístup k citlivým obchodním tokům 7. Padělání požadavků na straně serveru 8. Nesprávná konfigurace zabezpečení 9. Nesprávná správa zásob 10. Nebezpečná spotřeba API
Řešení kybernetické bezpečnosti SAST SAST, DAST SAST, DAST SAST, DAST, Secure API Manager SAST DAST DAST SAST, DAST Secure API Manager SCA, SAST
Definice
Koncový bod API – Komunikační bod mezi dvěma systémy, obvykle URL kontejneru nebo serveru s mikroslužbou. Použití URL, aplikace nebo vývojář může vyžádat informace ze serveru nebo provést akci na serveru API nebo mikroslužbě.
Provoz související s API – internetový provoz, který se skládá z požadavku HTTP nebo HTTPS a má obsah odpovědi XML nebo JSON, což naznačuje, že data jsou předávána aplikaci, obvykle prostřednictvím protokolu SOAP, WSDL, REST API nebo gRPC (viz níže).
Dynamické testování zabezpečení aplikací (DAST) – Proces analýzy aplikace nebo API serveru pomocí rozhraní, ať už jde o uživatelské rozhraní pro aplikaci, web přední část pro web aplikace, nebo URLpro koncové body API. U testování typu black-box tento přístup vyhodnocuje aplikaci „zvenčí dovnitř“ útokem na aplikaci stejným způsobem jako útočník, obvykle bez znalosti interních procesů.
Statické testování zabezpečení aplikací (SAST) – přístup k zabezpečení aplikací, který prohledává zdrojový, binární nebo bajtový kód a hledá rozpoznané vzorce chyb nebo zranitelností. SAST, někdy označované jako testování bílé skříňky, používá přístup „zevnitř ven“, který identifikuje potenciální zranitelnosti a chyby, které mohou, ale nemusí být zneužitelné externím útočníkem. Lehké statické nástroje mohou poskytovat vývojářům zpětnou vazbu v reálném čase v jejich IDE.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
5/23
Autorizace na úrovni poškozených objektů je rozšířený a snadno zneužitelný problém v web aplikace, protože volání API nesou informace o stavu. Aplikace jsou zranitelné, pokud umožňují uživateli provádět akce zadáním identifikátoru v API, aniž by ověřovaly, zda má k provedení těchto akcí autorizaci.
SOAP/WSDL – protokol založený na XML pro vytváření Web API. SOAP je samotný protokol a WSDL (Web Service Definition Language) je formát používaný k formálnímu popisu služeb. Vzhledem k vysoké režijní zátěži se tento styl API stal nepopulárním pro nové vývoje.
REST–A Web Styl API, který zahrnuje výměnu zpráv přímo přes HTTP s využitím sémantiky HTTP URLa slovesa, bez použití další „obálky“. Obsah je obvykle kódován jako JSON, i když v některých případech se jedná o XML.
GraphQL – dotazovací jazyk určený pro použití v API (s požadavky a odpověďmi v JSON) a v běhových prostředích na straně serveru pro provádění těchto dotazů. Umožňuje klientům definovat strukturu dat, která potřebují, a poté je v tomto formátu přijímat ze serveru.
gRPC – API protokol, který je výkonnější než REST. Používá HTTP/2 a jeho výkonnostní výhody.tages, které nabízí přes HTTP/1.1. Formát jednotlivých zpráv je obvykle binární a založený na ProtoBuf, což opět vytváří výkonnostní výhody.tagpřes REST a SOAP.
Top 2023 zabezpečení API pro rok 10
Analogický záznam o zabezpečení API z roku 2019
API1:2023 – Autorizace na úrovni poškozeného objektu
API1:2019 – Autorizace na úrovni poškozeného objektu
API2:2023 – Porušené ověřování
API2:2019–Nefunkční ověřování uživatelů
API3:2023–Autorizace na úrovni vlastností poškozeného objektu
API3:2019 – Nadměrná expozice dat, API6:2019 – Hromadné přiřazení
API4:2023 – Neomezená spotřeba zdrojů
API4:2019 – Nedostatek zdrojů a omezení rychlosti
API5:2023 – Autorizace na úrovni nefunkční funkce
API5:2019 – Autorizace na úrovni nefunkční funkce
API6:2023 – Neomezený přístup k citlivým obchodním tokům
API7:2023–Padělání požadavků na straně serveru
API8:2023–Nesprávná konfigurace zabezpečení API7:2019–Nesprávná konfigurace zabezpečení
API9:2023 – Nesprávné řízení zásob
API9:2019 – Nesprávná správa aktiv
API10:2023 – Nebezpečná konzumace API
API8:2019 – Injekční systém, API10:2019 – Nedostatečné protokolování a monitorování
Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
6/23
Vývojáři a týmy pro zabezpečení aplikací musí také správně implementovat funkce pro kontrolu identity uživatelů prostřednictvím ověřování.
API1:2023 – Autorizace na úrovni poškozeného objektu
Co je to?
API umožňují přístup ke službám a datům pomocí standardizovaných web požadavky. Společnosti vystavují svou infrastrukturu a data nezabezpečenému přímému přístupu, pokud tato aktiva nejsou dobře chráněna nebo pokud jsou kontroly autorizace špatně implementovány nebo chybí. Autorizace na úrovni poškozených objektů – označovaná také jako nezabezpečený přímý odkaz na objekt (IDOR) – může vést k řadě rizik, od zveřejnění dat až po úplné převzetí kontroly nad účtem.
Co dělá aplikaci zranitelnou?
Toto je rozšířený a snadno zneužitelný problém v web aplikace. Aplikace jsou zranitelné, pokud umožňují uživateli provádět akce zadáním identifikátoru v API, aniž by ověřovaly, zda má k provedení těchto akcí oprávnění.
V exampLe podrobně popsaný společností OWASP, platforma pro online obchody by mohla umožnit přístup k datům obchodu pomocí jednoduchého volání:
/shops/{název_obchodu}/data_tržeb.json
Toto je nebezpečné, protože kterýkoli uživatel může nahradit název obchodu názvem obchodu jiného uživatele a získat tak přístup k datům, která by neměl mít.
Útok bývalýamples
V roce 2021 bezpečnostní výzkumník zjistil, že web-aplikační a back-endové servery, které poskytovaly data rotopedům Peloton, měly několik koncových bodů API, které umožňovaly neověřeným uživatelům přístup k soukromým datům. V únoru 2021 Peloton implementoval částečnou opravu problému, která omezila přístup k API na ověřené uživatele, ale těmto uživatelům stále umožnila přístup k jakýmkoli soukromým datům ostatních členů. Úplná oprava přišla v květnu 2021.10
Jak tomu jako vývojář zabránit?
Vývojáři zabraňují nezabezpečenému přístupu k objektům vynucováním přísných kontrol, přiřazováním nepředvídatelných identifikátorů uživatelů, aby se zabránilo výčtu účtů, a kontrolou autorizace na úrovni objektů pro každou funkci, která přistupuje ke zdroji dat. Vývojáři by měli takové kontroly zapouzdřit, zejména pokud jsou založeny na vstupu uživatele, aby se vyloučila možnost, že by neúmyslné chyby mohly ohrozit zabezpečení. Odborníci na zabezpečení aplikací a provoz by měli vyžadovat kontroly autorizace pro každý požadavek na backendová data.
Jak může OpenText pomoci?
Statické testování zabezpečení aplikací (SAST) a dynamické testování zabezpečení aplikací (DAST) metodou OpenText™ dokáže detekovat širokou škálu zranitelností v kategorii nezabezpečených přímých odkazů na objekty (IDOR). IDOR může zahrnovat zranitelnosti, jako je například procházení adresáře, File Nahrát a File Zahrnutí. Obecněji řečeno, IDOR zahrnuje také třídy zranitelností, kde identifikátory
10. ledna. Tour de Peloton: Zveřejněná uživatelská data. Blog partnerů Pen Test. Partners Pen Test. Web Strana. 5. května 2021.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
7/23
Vývojáři a týmy pro zabezpečení aplikací musí také správně implementovat funkce pro kontrolu identity uživatelů prostřednictvím ověřování.
lze upravit pomocí URLManipulace s , tělem nebo záhlavím. Systém upozorní vývojáře na případy, kdy si uživatel může přímo zvolit primární klíč v požadavku API pro databázi nebo úložný kontejner, což je problém, který často vede k této třídě zranitelností. Systém také upozorní, pokud chybí očekávaná kontrola autorizace.
API2:2023 – Porušené ověřování
Co je to?
Kontroly autorizace omezují přístup k datům na základě konkrétních rolí nebo uživatelů, ale tato omezení nejsou dostatečná k ochraně systémů, dat a služeb. Vývojáři a týmy pro zabezpečení aplikací musí také řádně implementovat funkce pro kontrolu identity uživatelů prostřednictvím ověřování. Navzdory kritické povaze ověřování jsou tyto komponenty často špatně implementovány nebo nesprávně používány – což jsou hlavní příčiny nefunkčního ověřování uživatelů. Nefunkční ověřování uživatelů umožňuje útočníkům dočasně nebo trvale převzít identitu jiných uživatelů zneužitím nezabezpečených ověřovacích tokenů nebo narušením implementačních chyb.
Co dělá aplikaci zranitelnou?
K tomuto běžnému a snadno zneužitelnému problému dochází, protože ověřování je složitý proces, který může být matoucí a je ze své podstaty veřejně dostupný. Chyby vývojářů a nesprávná konfigurace aplikací mohou vést k nedostatku potřebných kontrol, což útočníkům umožňuje vyhnout se ověřování. Vývojáři, kteří neimplementují ověřování pro konkrétní koncový bod nebo povolí slabý mechanismus ověřování, vystavují aplikace různým útokům, jako je například plnění přihlašovacích údajů, přehrávání tokenů nebo sniffing hesel.
Útok bývalýamples
Mezi únorem a červnem 2023 byly útoky s cílem vymáhat údaje o přihlašovacích údajích zaměřené na prodejce oblečení Hot Topic, který informoval své zákazníky o napadení neznámého počtu účtů. Útočníci – pomocí přihlašovacích údajů získaných z neznámých zdrojů – měli přístup k citlivým osobním údajům, jako jsou jména zákazníků, e-mailové adresy, historie objednávek, telefonní čísla a měsíce a dny narození.11
V únoru 2022 chybně nakonfigurované cloudové úložiště ponechalo 1 GB citlivých dat z e-mailové marketingové služby Beetle Eye bez ochrany heslem nebo šifrování. Data obsahovala kontaktní informace a informace týkající se cestovního ruchu shromážděné různými turistickými agenturami a státy USA.12 Nesprávně nakonfigurované mechanismy ověřování jsou považovány za variantu kategorie nefunkčního ověřování uživatelů.
Jak tomu jako vývojář zabránit?
11 Toulas, Bill. Obchodní řetězec Hot Topic odhaluje vlnu útoků zaměřených na vymáhání přihlašovacích údajů. BleepingComputer. Článek v tisku. 1. srpna 2023.
12 Nair, Prajeet. Data 7 milionů lidí vystavená rizikům prostřednictvím americké marketingové platformy. Únik dat dnes. ISMG Network. 11. února 2022.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
8/23
Standardizace je vaším přítelem pro ověřování. Týmy DevSecOps by měly vytvořit jednu – nebo omezený počet – ověřovacích metod pro aplikace a zajistit, aby vývojáři jednotně implementovali mechanismy napříč všemi mikroslužbami a API.
Standardizace je vaším přítelem pro ověřování. Týmy DevSecOps by měly vytvořit jednu – nebo omezený počet – ověřovacích metod pro aplikace a zajistit, aby vývojáři jednotně implementovali mechanismy napříč všemi mikroslužbami a API. Jakákoli implementace ověřování by měla být přepracována.viewv kontextu standardu OWASP Application Security Verification Standard (ASVS), aktuálně ve verzi 4,13, aby byla zajištěna správnost implementace a souvisejících bezpečnostních kontrol. Jakákoli odchylka od standardu – zejména jakékoli úmyslné vystavení neověřených koncových bodů – by měla být vyhodnocena bezpečnostním týmem a povolena pouze v případě splnění závažných obchodních požadavků.
Jak může OpenText pomoci?
OAuth a JWT jsou dva nejběžnější typy ověřování používané k implementaci API a OpenText Dynamic Application Security Testing kontroluje slabé implementace obou standardů v aplikacích, stejně jako nesprávné konfigurace a zranitelné vzorce, jako je CSRF a Session Fixation, které se objevují ve vlastních implementacích ověřování. Skenování pomocí Dynamic Application Security Tool (DAST) od OpenTextu je skvělý způsob, jak detekovat zranitelnosti ověřování, zejména v API.
Statické testování zabezpečení aplikací v OpenTextu umožňuje širokou škálu kontrol týkajících se také špatného ověřování. Nástroj pro statickou analýzu zahrnuje detekci obecných problémů – jako je únik přihlašovacích údajů – i problémů specifických pro API, jako jsou chybějící deklarace ochrany v tokenech JWT nebo deklarace vyskytující se v záhlavích JWT.
API3:2023–Autorizace na úrovni vlastností poškozeného objektu
Co je to?
Autorizace na úrovni vlastností objektu s porušeným oprávněním je nová kategorie v seznamu OWASP 2023, která kombinuje dvě kategorie z předchozího seznamu: Nadměrné vystavení dat (API3:2019) a Hromadné přiřazení (API6:2019). Problém je způsoben nedostatečným ověřením oprávnění uživatele – nebo nesprávným oprávněním uživatele – na úrovni vlastností objektu. Koncové body API by měly ověřit, zda má každý uživatel oprávnění pro každou vlastnost, ke které se pokouší přistupovat nebo ji změnit. Zneužití tohoto problému může vést k vystavení informacím nebo manipulaci s daty neoprávněnými stranami.
Co dělá aplikaci zranitelnou?
K tomuto běžnému a snadno zneužitelnému problému dochází, když je uživatel oprávněn k přístupu k některým vlastnostem konkrétního objektu, jako je například rezervace pokoje v cestovní aplikaci, ale nikoli k jiným, například k ceně pokoje. Když uživatel přistupuje k vlastnostem objektu prostřednictvím API, aplikace by měla ověřit, zda uživatel:
· Měl by mít možnost získat přístup ke specifické vlastnosti objektu
13 Standard pro ověřování bezpečnosti aplikací OWASP. OWASP. Stránka GitHub. Poslední přístup: 17. listopadu 2023.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
9/23
Autorizace na úrovni vlastností poškozeného objektu je nová kategorie v seznamu OWASP z roku 2023, která kombinuje dvě kategorie z předchozího seznamu: Nadměrné vystavení dat (API3:2019) a Hromadné přiřazení (API6:2019).
Statické testování zabezpečení aplikací OpenText™ pomáhá předcházet nadměrnému vystavení dat a hromadnému přiřazování prostřednictvím analýzy toku dat. Systém identifikuje mnoho zdrojů soukromých dat, například ty založené na názvech proměnných nebo konkrétních voláních API, a identifikuje objekty, které umožňují hromadné přiřazování.
(porušení byla dříve známá jako nadměrné vystavení dat) a/nebo
· Je povoleno měnit specifickou vlastnost objektu (některé aplikace tuto kontrolu nekontrolují, protože používají framework k automatickému mapování) web požadavek na parametry objektových polí, problém známý jako hromadné přiřazení).
V bývalém zaměstnanci OWASPampOnline video platforma umožňuje uživateli změnit popis videa, a to i u blokovaného videa, ale neměla by uživateli umožnit upravovat vlastnost „blokováno“.
PUT /api/video/update _ video
{
„popis“: „zábavné video o kočkách“,
„blokováno“: nepravdivé
}
Útok bývalýamples
V lednu 2022 objevil program odměn za nalezené chyby v Twitteru chybu, která umožňovala uživateli odeslat e-mailovou adresu nebo telefonní číslo do systému Twitteru, který následně vrátil název účtu, ke kterému informace patřila.14 Neznámý útočník využil této chyby k sestavení seznamu milionů uživatelských účtů propojených s telefonními čísly a e-mailovými adresami. Tím, že Twitter umožnil komukoli propojit dva weby, umožnil neúmyslně konkrétnější identifikaci pseudonymních uživatelů.
Jak tomu jako vývojář zabránit?
Vývojáři by měli vždy implementovat správné kontroly pro přístup ke konkrétním vlastnostem objektů nebo jejich změnu. Spíše než vracet obecnou datovou strukturu s každou vlastností – což se často stává u generických metod, jako jsou to_json() a to_string() – by programátoři měli být velmi specifičtí v tom, jaké informace vracejí. Jako dodatečné bezpečnostní opatření by aplikace měly implementovat validaci odpovědí založenou na schématu, která vynucuje bezpečnostní kontroly pro všechna data vrácená metodami API. Přístup by se měl řídit principy nejnižších oprávnění a měl by povolit přístup pouze v nezbytně nezbytných případech.
Jak může OpenText pomoci?
Statické testování zabezpečení aplikací OpenText™ pomáhá předcházet nadměrnému vystavení dat i hromadnému přiřazování prostřednictvím analýzy toku dat. Systém zvýrazní mnoho zdrojů soukromých dat, například ty založené na názvech proměnných nebo konkrétních voláních API, a identifikuje objekty, které umožňují hromadné přiřazování. Uživatelé si mohou definovat i vlastní zdroje, sledovat data v programu a pokud se dostanou na nevhodné místo, upozornit vývojáře nebo provozovatele na riziko.
14 Incident ovlivňující některé účty a soukromé informace na Twitteru. Centrum ochrany osobních údajů Twitteru. Twitter. Web Strana. 5. srpna 2022.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
10/23
Aplikace, které neomezují zdroje přidělené k uspokojení požadavku, mohou být zranitelné, včetně těch, které neomezují alokovatelnou paměť, počet files nebo procesy, ke kterým byl přistupováno, nebo povolená míra požadavků, mimo jiné atributy.
OpenText SAST má navíc znalosti nejdůležitějších mechanismů serializace a deserializace JSON a XML. Pomocí těchto mechanismů dokáže nástroj detekovat kód, který správně nedeserializuje objekty přenosu domény (DTO), což by mohlo umožnit hromadné přiřazení jeho atributů. Některé případy úniku informací a hromadného přiřazení lze také detekovat pomocí testování bezpečnosti dynamických aplikací OpenText. Nakonec lze implementovat některá protiopatření přidáním pravidel do web aplikační firewall (WAF).
API4:2023 – Neomezená spotřeba zdrojů
Co je to?
API zpřístupňují mnoho užitečných obchodních funkcí. K tomu využívají výpočetní zdroje, jako jsou databázové servery, nebo mohou mít přístup k fyzickým komponentám prostřednictvím operačních technologií. Protože systémy mají omezenou sadu zdrojů pro reakci na volání API, mohou útočníci speciálně vytvářet požadavky a vytvářet scénáře, které vedou k vyčerpání zdrojů, odmítnutí služby nebo zvýšeným obchodním nákladům. V mnoha případech mohou útočníci odesílat požadavky API, které vážou značné množství zdrojů, zahlcují počítač nebo zdroje šířky pásma a vedou k útoku typu odmítnutí služby. Opakovaným odesíláním požadavků z různých IP adres nebo cloudových instancí mohou útočníci obejít obranu určenou k detekci podezřelých nárůstů ve využívání.
Co dělá aplikaci zranitelnou?
Požadavky API spouštějí odpovědi. Ať už tyto odpovědi zahrnují přístup k databázi, provádění I/O operací, spouštění výpočtů nebo (stále častěji) generování výstupu z modelu strojového učení, API využívají výpočetní, síťové a paměťové zdroje. Útočník může odesílat požadavky API na koncový bod v rámci útoku typu denial-of-service (DoS), který místo přetížení šířky pásma – cíle volumetrického útoku DoS – vyčerpává zdroje CPU, paměti a cloudu. Aplikace, které neomezují zdroje přidělené k uspokojení požadavku, mohou být zranitelné, včetně těch, které neomezují alokovatelnou paměť, počet files nebo procesy, ke kterým byl přistupováno, nebo povolená míra požadavků, mimo jiné atributy.
Rozhraní API pro zpracování na serveru musí mít nastavená omezení, aby se zabránilo nadměrné alokaci paměti a pracovní zátěže, nadměrným požadavkům na operace spouštěné rozhraním API nebo nadměrným poplatkům za služby třetí strany bez omezení výdajů.
Běžným útokem je úprava argumentů předávaných koncovému bodu API, například zvětšení velikosti odpovědi a vyžádání milionů položek databáze, místo například prvních deseti:
/api/users?page=1&size=1000000
Kromě toho, pokud má útočník přístup k backendové službě, která si účtuje poplatky za používání, mohou útoky na spotřebu zdrojů využít k navýšení poplatků pro vlastníka aplikace. Další příklad OWASPuample poukazuje na funkci resetování hesla, která používá SMS zprávu k ověření identity a kterou lze vyvolat tisíckrát, což zvyšuje náklady pro oběť.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
11/23
Filtrování na okraji sítě pomocí sítí pro doručování obsahu (CDN) spárovaných s web Aplikační firewally (WAF) mohou snížit záplavy provozu a zároveň minimalizovat dopad na jednotlivé uživatele.
POST /sms/send _ reset _ heslo _ kód
Hostitel: willyo.net {
„telefonní číslo“: „6501113434“ }
Útok bývalýamples
Vzhledem k tomu, že útoky na spotřebu zdrojů jsou často spojovány s problémy s výkonem a dostupností, cílené společnosti k nim mají tendenci přistupovat jako k součásti nákladů na podnikání, spíše než k incidentům, které je třeba hlásit, což snižuje viditelnost hrozby. V roce 2022 se podíl útoků typu DDoS (distributed denialofservice) na aplikační vrstvě, které jsou nadmnožinou útoků na spotřebu zdrojů API, snížil jako podíl všech útoků, ale ve 4. čtvrtletí roku 2022 bylo stále zaznamenáno o 79 % více útoků než ve stejném čtvrtletí předchozího roku.15
V jednom z útoků popsaných v roce 2015 vývojář zjistil, že klient pro Android opakovaně kontaktoval jeho web. Web API s náhodně generovanými klíči API, což vedlo k útoku typu denial-of-service. Vývojář předpokládal, že se škodlivá aplikace nainstalovaná na zařízeních Android pokouší uhodnout 64bitový klíč API.16
Jak tomu jako vývojář zabránit?
Použitím limitů rychlosti a prahových hodnot lze většinu útoků zaměřených na spotřebu zdrojů zmírnit, ačkoli legitimní provoz může být také ovlivněn špatně postavenou obranou. Specifické limity by měly být stanoveny pro:
· Alokace paměti
· Procesy
· Cloudové instance
· Nahráno file deskriptory a file velikost
· Vrácené záznamy
· Počet placených transakcí službám třetích stran
· Všechny příchozí parametry (např. délky řetězců, délky polí atd.)
· Počet interakcí API na klienta v daném časovém okně
Filtrování na okraji sítě pomocí sítí pro doručování obsahu (CDN) spárovaných s web Aplikační firewally (WAF) mohou snížit záplavy datového provozu a zároveň minimalizovat dopad na jednotlivé uživatele. Platformy pro poskytování aplikací umožňují snadné filtrování, včetně omezení paměti, procesorů a procesů.
15 Yoachimik, Omer. Zpráva o hrozbách DDoS od Cloudflare za 2022. čtvrtletí roku 4. Blog Cloudflare. Web Strana. 10. ledna 2023.
16 Jak zastavit hackerský útok/útok DOS na web API. StackOverflow. Web Strana. 15. září 2015.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
12/23
Dynamické testování zabezpečení aplikací OpenText dokáže otestovat servery a funkce API na zranitelnost vůči útoku typu „denial of service“, aniž by to ovlivnilo samotnou službu. Samotný akt spuštění DAST skenování navíc může dostatečně zatěžovat prostředí, aby odhalil potenciální slabiny ve spotřebě zdrojů.
Jak může OpenText pomoci?
Díky OpenText SAST a OpenText Dynamic Application Security Testing mohou týmy DevSecOps testovat odolnost svého kódu a infrastruktury vůči útokům vyčerpání zdrojů. OpenText SAST dokáže odhalit mnoho oblastí, kde by útočník mohl zneužít logiku aplikace k vytvoření extrémní spotřeby zdrojů.
Zabezpečení na úrovni kódu není dostatečné k řešení tohoto problému v aplikaci. Vyčerpání zdrojů a omezení rychlosti jsou specifické podsegmenty útoků typu denial-of-service, které by měly být zmírněny za běhu. Testování zabezpečení aplikací OpenText Dynamic Application Security může testovat servery a funkce API na zranitelnost vůči útokům typu denial-of-service, aniž by to ovlivnilo službu. Kromě toho samotný akt spuštění DAST skenování může dostatečně zatěžovat prostředí, aby odhalil potenciální slabiny ve spotřebě zdrojů.
API5:2023 – Autorizace na úrovni nefunkční funkce
Co je to?
Moderní aplikace má mnoho různých funkcí, které přistupují k datům, vytvářejí je, manipulují s nimi, mažou je a spravují. Ne každý uživatel aplikace potřebuje přístup ke každé funkci nebo všem datům, ani by to nemělo být povoleno podle principu nejnižších oprávnění. Každý koncový bod API má své zamýšlené publikum, které může zahrnovat anonymní, běžné neprivilegované a privilegované uživatele. Administrativní a manažerské funkce by měly vyžadovat privilegovanou autorizaci, ale někdy jsou přístupné prostřednictvím legitimních volání API od neoprávněného uživatele – původ autorizace na úrovni přerušených funkcí (Broken Function Level Authorization). Vzhledem k tomu, že různé hierarchie, skupiny a role vytvářejí složitost v řízení přístupu, nemusí mít aplikační funkce odpovídající omezení ohledně toho, kdo je může volat.
Co dělá aplikaci zranitelnou?
Aplikace, které umožňují specifickým funkcím provádět administrativní úkoly, nesmí bezpečným způsobem omezovat přístup k těmto funkcím. API, která se přímo mapují na takové funkce, vystavují tyto slabiny zneužití. Funkce, které nepoužívají mechanismus ověřování a autorizace aplikace, by měly být považovány za potenciální bezpečnostní slabiny.
V exampPodle OWASP útočník získá přístup k požadavkům API pro přidání pozvaného uživatele do nové mobilní aplikace a upozorní, že pozvánka obsahuje informace o roli pozvaného uživatele. Útočník zneužije této slabiny a odešle novou pozvánku:
POST /api/invites/new
{
„e-mail“: „attacker@somehost.com“,
„role“: „admin“
} To jim umožňuje získat administrátorská oprávnění v systému.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
13/23
Týmy DevSecOps by měly navrhnout standardní přístup k autorizaci a ověřování, který ve výchozím nastavení zabrání přístupu k požadavkům a vynutí výchozí nastavení „odepřít vše“.
Řízení aplikací a logické toky jsou srdcem každého online podnikání a s tím, jak firmy přesouvají stále více svých operací do cloudu, mohou být tyto toky odhaleny a zneužity. Tento nadměrný přístup může podnikání poškodit.
Útok bývalýamples
V roce 2022 texaské ministerstvo pojišťovnictví informovalo veřejnost, že informace téměř dvou milionů Texanů byly odhaleny prostřednictvím části aplikace pro odškodnění pracovníků, která neúmyslně umožnila členům veřejnosti přístup k chráněným údajům.17 V druhém incidentu v roce 2022 australská telekomunikační firma Optus uznala, že osobní údaje a informace o účtech až 10 milionů Australanů byly odhaleny prostřednictvím API, které nevyžadovalo žádné ověřování ani autorizaci. Zatímco Optus útok označil za „sofistikovaný“, bezpečnostní výzkumník obeznámený s podrobnostmi útoku jej popsal jako „triviální“.18
Jak tomu jako vývojář zabránit?
Týmy DevSecOps by měly navrhnout standardní přístup k ověřování a autorizaci, který ve výchozím nastavení zabraňuje přístupu k požadavkům a vynucuje výchozí nastavení „odepřít všem“. Z tohoto výchozího nastavení by se při určování přístupu pro role/skupiny/uživatele měl vždy uplatňovat princip nejnižších oprávnění. Vývojáři by měli zajistit, aby ověřování a autorizace byly zavedeny pro všechny relevantní HTTP slovesa/metody (např. POST, GET, PUT, PATCH, DELETE) související s každým koncovým bodem API. Irelevantní slovesa by měla být zakázána. Vývojáři by navíc měli implementovat základní třídu pro administrativní přístup a správu pomocí dědičnosti tříd, aby se zajistilo, že ovládací prvky autorizace před udělením přístupu zkontrolují roli uživatele. Všechny kritické administrativní funkce by měly používat mechanismus autorizace, aby se zabránilo eskalaci oprávnění.
Jak může OpenText pomoci?
Kombinací funkcí analýzy statického kódu a API v rámci OpenText™ Static Application Security Testing s běhovými kontrolami sady OpenText Dynamic Application Security Testing (DAST) mohou týmy DevSecOps vyhodnotit své aplikace, zda neobsahují problémy s autorizací na úrovni funkcí, a před nasazením průběžně testovat produkční kód na bezpečnostní slabiny. Pro detekci problémů s autorizací funkcí objektů používá OpenText™ Static Application Security Testing pravidla, která určují, kdy se v určitých programovacích jazycích a frameworkech očekává kontrola autorizace, a absence takové kontroly je hlášena.
API6:2023 – Neomezený přístup k citlivým obchodním tokům
Co je to?
Od sneakerbotů až po ticketboty se útoky na inventář online prodejců prostřednictvím jejich API staly pro e-commerce weby významným problémem. Pochopením obchodního modelu a logiky aplikace může útočník vytvořit řadu volání API, která dokáží automaticky rezervovat nebo zakoupit zboží.
17 Beeferman, Jason. Osobní údaje 1.8 milionu Texanů s nároky na pojistné plnění u Ministerstva pojištění byly po léta odhalovány, uvádí audit. The Texas Tribune. 17. května 2022.
18 Taylor, Josh. Únik dat z Optusu: vše, co zatím víme o tom, co se stalo. The Guardian. 28. září 2022.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
14/23
Zabránění neomezenému přístupu k citlivým obchodním tokům je spíše o holistickém přístupu k zabezpečení aplikací a méně o nalezení konkrétní technologie.
inventář, čímž se brání jiným legitimním spotřebitelům v přístupu k produktům nebo službám daných podniků. Jakékoli API, které umožňuje přístup k obchodnímu procesu, může útočník použít k ovlivnění podniku a spadá pod definici neomezeného přístupu k citlivým obchodním tokům.
Co dělá aplikaci zranitelnou?
Řízení aplikací a logické toky jsou srdcem každého online podnikání a s tím, jak firmy přesouvají stále více svých operací do cloudu, mohou být tyto toky odhaleny a zneužity. Tento nadměrný přístup může podnikání poškodit, když útočníci automatizují nákup produktů, vytvářejí boty pro zanechávání komentářů a…viewnebo automatizovat rezervaci zboží či služeb.
Pokud aplikace nabízí koncový bod s přístupem k obchodním procesům společnosti, aniž by omezovala přístup k obchodním operacím za tímto koncovým bodem, bude aplikace zranitelná. Mezi ochrany patří omezení počtu pokusů o přístup z jednoho zařízení pomocí otisků prstů, detekce, zda aktivita pochází od lidského aktéra, a detekce, zda se jedná o automatizaci.
Útok bývalýamples
Když se v listopadu 2022 začaly prodávat vstupenky na koncert Taylor Swift na Ticketmasteru, předem se zaregistrovalo 1.5 milionu zákazníků, ale více než 14 milionů požadavků – včetně třikrát většího počtu botů – bylo zaznamenáno.ampzrušil nákupní odkazy a API, jakmile byl zahájen prodej vstupenek. Stránka se zhroutila, což mnoha zákazníkům zabránilo v nákupu vstupenek.19
Nápor reseller botů se podobal těm, které zničily uvedení PlayStationu 5 na trh v listopadu 2020. Problémy s dodavatelským řetězcem omezovaly dodávky již před uvedením nejnovější herní konzole Sony na trh, ale automatizovaní boti ještě více ztížili hledání dostupných jednotek a vedli k astronomickým prodejním cenám. V případě jednoho e-shopu vzrostl počet transakcí „přidat do košíku“ z průměrných 15,000 27 požadavků za hodinu na více než 20 milionů, přičemž API obchodu bylo použito k přímému vyžádání produktů podle čísla SKU.XNUMX
Jak tomu jako vývojář zabránit?
Vývojáři by měli spolupracovat s provozním i technickým týmem na řešení problémů s potenciálním škodlivým přístupem k obchodním tokům. Obchodní týmy mohou identifikovat, které toky jsou vystaveny riziku prostřednictvím API, a provádět analýzy hrozeb, aby zjistily, jak by útočníci mohli tyto koncové body zneužít. Vývojáři by zároveň měli spolupracovat s technickým oddělením jako součást DevOps týmu na zavedení dalších technických obranných opatření, jako je používání otisků prstů zařízení, aby se zabránilo zahlcení automatizovaných instancí prohlížeče, a identifikace vzorců v chování, které rozlišují mezi lidskými a strojovými aktéry.
19 Steele, Billy. Ticketmaster ví, že má problém s boty, ale chce, aby ho Kongres vyřešil. Engadget. Novinový článek. 24. ledna 2023.
20 Muwandi, Tafara a Warburton, David. Jak boti zničili spuštění PlayStationu 5 milionům hráčů. Blog F5 Labs. F5. Web Strana. 18. března 2023.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
15/23
Nejznámější bývalý/áampJeden z útoků SSRF se týkal bývalého člena Amazonu Web Inženýr služeb (AWS), který zneužil špatně nakonfigurovanou web aplikační firewall (WAF) následně využil chybu SSRF ke shromažďování dat ze serverové instance patřící finančnímu gigantu Capital One.
Operační týmy by měly také znovuview veškerá API určená pro použití jinými počítači, například pro případy použití B2B, a zajistit, aby byla zavedena určitá obranná opatření, která útočníkům zabrání ve zneužívání interakcí mezi počítači.
Jak může OpenText pomoci?
Zachycení zranitelných a citlivých obchodních toků často závisí na základních postupech. Společnosti potřebují dokumentovat a sledovat všechna svá funkční API a určit, která z nich vystavují citlivé procesy a data potenciálním útočníkům. Aplikační logiku je také třeba analyzovat, zda neobsahuje logické chyby, které by útočníci mohli zneužít.
Celkově vzato, zamezení neomezeného přístupu k citlivým obchodním tokům spočívá spíše v holistickém přístupu k zabezpečení aplikací a méně v hledání konkrétní technologie.
API7:2023–Padělání požadavků na straně serveru
Co je to?
Backendové servery zpracovávají požadavky provedené prostřednictvím koncových bodů API. Server-Side Request Forgery (SSRF) je zranitelnost, která útočníkovi umožňuje přimět server, aby odesílal požadavky jeho jménem a s úrovní oprávnění serveru. Útok často využívá server k překlenutí mezery mezi externím útočníkem a interní sítí. Základní útoky SSRF vedou k odpovědi vrácené útočníkovi, což je mnohem jednodušší scénář než útoky Blind SSRF, kde se nevrací žádná odpověď, takže útočník nemá žádné potvrzení, zda byl útok úspěšný.
Co dělá aplikaci zranitelnou?
Chyby typu Server-Side Request Forgery (SSRF) jsou v podstatě důsledkem nedostatečného ověření vstupu zadaného uživatelem. Útočníci jsou schopni vytvářet požadavky a zahrnovat URI, které poskytuje přístup k cílové aplikaci.
Moderní koncepty ve vývoji aplikací, jako například webPodle OWASP háčky a standardizované aplikační frameworky činí SSRF běžnějším a nebezpečnějším.
V exampcitováno OWASP, sociální sítí, která uživatelům umožňuje nahrávat profesionálnífile Obrázky by mohly být zranitelné vůči SSRF, pokud server neověřuje argumenty odeslané do aplikace. Spíše než URL ukazování na obrázek, například:
POST /api/profile/nahrát _ obrázek
{
„obrázek _ url„: „http://example.com/profile _ obr.jpg”
}
Útočník by mohl odeslat URI, které by určilo, zda je konkrétní port otevřený, pomocí následujícího volání API:
{ „obrázek _ url„localhost:8080“
}
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
16/23
Mezi nesprávnou konfiguraci zabezpečení patří nastavení aplikací se zranitelnými výchozími konfiguracemi, umožnění příliš volného přístupu k citlivým funkcím a datům a veřejné zveřejňování informací o aplikacích prostřednictvím podrobných chybových zpráv.
I v případě slepého SSRF by útočník mohl zjistit, zda je port otevřený, měřením doby potřebné k získání odpovědi.
Útok bývalýamples
Nejznámější bývalý/áampJeden z útoků SSRF se týkal bývalého člena Amazonu Web Inženýr služeb (AWS), který zneužil špatně nakonfigurovanou web aplikační firewall (WAF) následně použil chybu SSRF ke shromažďování dat ze serverové instance patřící finančnímu gigantu Capital One. Incident, k němuž došlo v červenci 2019, vedl ke krádeži dat přibližně 100 milionů občanů USA a šesti milionů občanů Kanady.21 Amazon považuje za zdroj kompromitace spíše chybu v konfiguraci než chybu SSRF.22
V říjnu 2022 informovala firma zabývající se cloudovou bezpečností společnost Microsoft o čtyřech zranitelnostech SSRF v její vlajkové platformě Azure. Každá zranitelnost ovlivňovala jinou službu Azure, včetně služby Azure Machine Learning a služby Azure API Management.23
Jak tomu jako vývojář zabránit?
Vývojáři by měli zapouzdřit mechanismy pro načítání zdrojů do svého kódu, izolovat danou funkci a vrstvit ochrany proti přidávání, aby ověřovali veškeré požadavky. Protože se takové funkce obvykle používají k načítání vzdálených zdrojů, nikoli interních, měli by vývojáři nakonfigurovat zapouzdřené funkce tak, aby používaly seznam povolených vzdálených zdrojů a blokovaly pokusy o přístup k interním zdrojům. Pro funkce načítání zdrojů by mělo být zakázáno přesměrování HTTP a všechny požadavky by měly být analyzovány na přítomnost škodlivého kódu.
Riziko slabin SSRF nelze vždy zcela vyloučit, proto by společnosti měly pečlivě zvážit riziko využití volání k externím zdrojům.
Jak může OpenText pomoci?
Dynamické testování zabezpečení aplikací OpenText umožňuje týmům DevSecOps pravidelně testovat padělání požadavků na straně serveru (Server-Side Request Forgery). Dynamické testování zabezpečení aplikací OpenText™ prohledává aplikační server v nakonfigurovaném prostředí tak, aby bylo možné otestovat všechny komponenty – aplikaci, server a síť, což platformě dynamické analýzy poskytuje komplexní přehled. view dopadu požadavků serveru.
OpenText SAST dokáže detekovat mnoho případů SSRF pomocí analýzy kontaminace – napříkladamptj. pokud aplikace používá neověřený uživatelský vstup k vytvoření URL které budou následně načteny. Nástroj označí použití neomezeného uživatelského vstupu.
21 Informace o kybernetickém incidentu Capital One. Informační bulletin Capitol One. Web Stránka. Aktualizováno 22. dubna 2022.
22 Ng, Alfred. Amazon říká senátorům, že nenese vinu za únik dat z Capital One. CNET News. com. Článek v tisku. 21. listopadu 2019.
23 Shitrit, Lidor Ben. Jak Orca objevila zranitelnosti typu Server-Side Request Forgery (SSRF) ve čtyřech různých službách Azure. Blog zabezpečení Orca. Web Strana. 17. ledna 2023.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
17/23
Zabezpečení jako kód může pomoci tím, že umožní opakovatelné konfigurace a umožní týmům zabývajícím se zabezpečením aplikací nastavit standardní konfigurační sady pro konkrétní komponenty aplikace.
API8:2023–Nesprávná konfigurace zabezpečení
Co je to?
Vývojáři často špatně konfigurují své aplikace, nedokážou oddělit vývojová aktiva od produkčních a exportují citlivá data. files – taková konfigurace files–do jejich veřejných repozitářů a neměna výchozích konfigurací. Mezi nesprávné konfigurace zabezpečení patří nastavení aplikací se zranitelnými výchozími konfiguracemi, umožnění příliš volného přístupu k citlivým funkcím a datům a veřejné zveřejňování informací o aplikacích prostřednictvím podrobných chybových zpráv.
Co dělá aplikaci zranitelnou?
Výchozí konfigurace aplikací jsou často příliš tolerantní, postrádají posílení zabezpečení a ponechávají instance cloudového úložiště přístupné veřejnosti. Často web Frameworky, na kterých jsou aplikace založeny, obsahují řadu funkcí aplikace, které nejsou potřeba a jejichž zahrnutí snižuje bezpečnost.
V exampPodrobný popis od OWASP, sociální sítě, která nabízí funkci přímého zasílání zpráv, by měl chránit soukromí uživatelů, ale nabízí požadavek API pro načtení konkrétní konverzace pomocí následujícího příkladuamppožadavek API:
GET /dm/user _ updates.json?conversation _ id=1234567&cursor=GRlFp7LCUAAAA
Koncový bod API neomezuje data uložená v mezipaměti, což má za následek ukládání soukromých konverzací do mezipaměti. web prohlížeč. Útočníci by mohli získat informace z prohlížeče a odhalit soukromé zprávy oběti.
Útok bývalýamples
V květnu 2021 firma zabývající se cloudovou bezpečností oznámila společnosti Microsoft, že nejméně 47 různých zákazníků nezměnilo výchozí konfiguraci svých instancí Microsoft Power Apps. Mezi postižené organizace patřily společnosti jako American Airlines a Microsoft a státní správy, například v Indianě a Marylandu, a vystavily 38 milionů záznamů potenciálnímu ohrožení napříč portály Power Apps.24
V roce 2022 firma zabývající se správou zranitelností zjistila, že 12,000 XNUMX cloudových instancí hostovaných na Amazonu Web Služby a 10,500 2022 hostovaných na Azure nadále vystavovaly Telnet, protokol vzdáleného přístupu, který je podle zprávy z roku 25 považován za „nevhodný pro jakékoli internetové použití“.XNUMX Zahrnutí zbytečných a nezabezpečených funkcí podkopává bezpečnost těchto API a aplikací.
24 Upguard Research. Záměrně: Jak výchozí oprávnění v Microsoft Power Apps odhalila miliony. Blog Upgard Research. Web Strana. 23. srpna 2021.
25 Beardsley, Todd. Zpráva o chybných konfiguracích cloudu za rok 2022. Rapid7. Zpráva ve formátu PDF. s. 12. 20. dubna 2022.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
18/23
Slepé místo v dokumentaci nastává, když jsou podrobnosti o účelu, fungování a verzování API nejasné kvůli nedostatku dokumentace, která by tyto důležité atributy podrobně popisovala.
Jak tomu vývojář zabránit?
Týmy DevSecOps musí rozumět krokům nezbytným k vytvoření bezpečných konfigurací pro své aplikace a používat automatizovaný vývojový kanál ke kontrole konfigurace. filepřed nasazením, včetně pravidelných jednotkových testů a kontrol za běhu, aby se software průběžně kontroloval na chyby v konfiguraci nebo bezpečnostní problémy. Zabezpečení jako kód může pomoci tím, že umožňuje opakovat konfigurace a dává týmům pro zabezpečení aplikací možnost nastavit standardní konfigurační sady pro konkrétní komponenty aplikace.
V rámci svého bezpečného vývojového cyklu by vývojáři a provozní týmy měli:
· Zavést proces posílení, který zjednodušuje opakované vytváření a údržbu bezpečného aplikačního prostředí,
· Review a aktualizovat všechny konfigurace v rámci API stacku tak, aby konzistentně zahrnovaly nový standard, a
· Automatizujte hodnocení efektivity nastavení konfigurace ve všech prostředích.
Jak může OpenText pomoci?
Statické testování zabezpečení aplikací OpenText dokáže kontrolovat konfigurace během vývojového procesu a odhalit mnoho typů slabin. Protože k chybným konfiguracím zabezpečení dochází jak na úrovni aplikačního kódu, tak na úrovni infrastruktury, lze k jejich odhalení použít různé produkty OpenText.
Statické testování zabezpečení aplikací v OpenTextu dokáže zkontrolovat kód aplikace, zda neobsahuje problémy s nesprávnou konfigurací. Během statické analýzy může OpenText SAST vyhodnotit konfiguraci. filepro bezpečnostní chyby, včetně chyb v Dockeru, Kubernetes, Ansible a Amazonu Web Šablony pro služby, CloudFormation, Terraform a Azure Resource Manager.
Chyby konfigurace lze zachytit i za běhu. OpenText Dynamic Application Security Testing umožňuje týmům DevSecOps pravidelně testovat běžné chyby v konfiguraci zabezpečení. Jednou z největších silných stránek skenování DAST je, že běží na aplikačním serveru v nakonfigurovaném prostředí, což znamená, že celé prostředí – aplikace, server a síť – je testováno najednou, což platformě dynamické analýzy poskytuje komplexní přehled. view produkčního prostředí je nakonfigurováno.
API9:2023 – Nesprávné řízení zásob
Co je to?
Stejně jako většina softwarových aktiv mají i API svůj životní cyklus, kdy jsou starší verze nahrazovány bezpečnějšími a efektivnějšími API nebo se stále častěji používají API propojená se službami třetích stran. Týmy DevSecOps, které neudržují verze a dokumentaci svých API, mohou při pokračujícím používání starších, chybných verzí API zavádět zranitelnosti – tato slabina je známá jako nesprávná správa zásob. Osvědčené postupy pro správu zásob vyžadují sledování
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
19/23
verze API, pravidelné hodnocení a inventarizace integrovaných služeb a pravidelné zastarávání starších verzí, aby se zabránilo šíření bezpečnostních zranitelností.
Co dělá aplikaci zranitelnou?
Softwarové architektury závislé na API – zejména ty, které používají architektury mikroslužeb – mají tendenci zpřístupňovat více koncových bodů než tradiční web aplikace. Množství koncových bodů API spolu s pravděpodobností existence více verzí API současně vyžaduje od poskytovatele API dodatečné zdroje pro správu, aby se zabránilo rozšiřující se ploše pro útok. OWASP identifikuje dvě hlavní slepá místa, která mohou mít týmy DevSecOps v souvislosti s jejich infrastrukturou API.
Zaprvé, slepé místo v dokumentaci nastává, když jsou podrobnosti o účelu, fungování a verzování API nejasné kvůli nedostatku dokumentace, která by tyto důležité atributy podrobně popisovala.
Za druhé, slepá místa v toku dat vznikají, když jsou API používána nejasným způsobem, což vede k funkcím, které by neměly být nutně povoleny bez silného obchodního odůvodnění. Sdílení citlivých dat s třetí stranou bez bezpečnostních záruk, nedostatečná viditelnost konečného výsledku toku dat a nenamapování všech toků dat v zřetězených API jsou slepá místa.
Jako exampZpráva OWASP zmiňuje fiktivní sociální síť, která umožňuje integraci s nezávislými aplikacemi třetích stran. I když je od koncového uživatele vyžadován souhlas, sociální síť si neudržuje dostatečný přehled o toku dat, aby zabránila navazujícím stranám v přístupu k datům, například sledováním aktivity nejen uživatele, ale i jeho přátel.
Útok bývalýamples
V letech 2013 a 2014 se až 300,000 87 lidí zúčastnilo online psychologického kvízu na platformě Facebook. Společnost Cambridge Analytica, která kvíz vytvořila, shromažďovala nejen informace o těchto uživatelích, ale i o jejich propojených přátelích – populaci, která celkem čítala až XNUMX milionů lidí, z nichž drtivá většina nedala souhlas se shromažďováním svých informací. Společnost poté tyto informace použila k přizpůsobení reklam a sdělení těmto lidem jménem svých klientů, včetně zasílání politických reklam na podporu Trumpovy prezidentky.ampve volbách v roce 2016 Nedostatečná transparentnost Facebooku ohledně toho, jak třetí strany používaly informace shromážděné z jeho platformy, je exemplářemampnesprávného řízení zásob.
Jak tomu jako vývojář zabránit?
Týmy DevSecOps by měly dokumentovat všechny hostitele API a zaměřit se na udržování přehledu o datových tocích mezi API a službami třetích stran. Hlavním způsobem, jak zabránit nesprávné správě inventáře, je podrobná dokumentace kritických aspektů všech služeb API a hostitelů, včetně informací o tom, jaká data zpracovávají, kdo má přístup k hostitelům a datům,
26 Rosenberg, Matthew a Dance, Gabriel. „Vy jste produkt“: Cílem útoků Cambridge Analytica na Facebooku. The New York Times. Článek v tisku. 8. dubna 2018.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
20/23
Organizace mohou spravovat, monitorovat, zabezpečovat a dokumentovat používání svých API pomocí nástroje OpenText Secure API Manager od společnosti OpenText, který umožňuje týmům pro zabezpečení aplikací udržovat aktuální inventář aktiv API.
a specifické verze API každého hostitele. Mezi technické detaily, které by měly být zdokumentovány, patří implementace ověřování, zpracování chyb, obrana proti omezení rychlosti, politika sdílení zdrojů napříč zdroji (CORS) a podrobnosti o každém koncovém bodu.
Značný objem dokumentace je obtížné spravovat manuálně, proto se doporučuje generování dokumentace prostřednictvím procesu průběžné integrace a používání otevřených standardů. Přístup k dokumentaci k API by měl být také omezen na ty vývojáře, kteří jsou oprávněni API používat.
Během fází tvorby a testování aplikací by se vývojáři měli vyvarovat používání produkčních dat ve vývojových nebotagverze aplikace, aby se zabránilo únikům dat. Když jsou vydány nové verze API, tým DevSecOps by měl provést analýzu rizik, aby určil nejlepší přístup k upgradu aplikací a využil tak výhodtage zvýšené bezpečnosti.
Jak může OpenText pomoci?
Organizace mohou spravovat, monitorovat, zabezpečovat a dokumentovat používání svých API pomocí nástroje OpenText™ Secure API Manager, který umožňuje týmům pro zabezpečení aplikací udržovat aktuální inventář aktiv API. OpenText Secure API Manager poskytuje autoritativní úložiště, kde může váš tým DevSecOps ukládat a spravovat všechna API používaná organizací, což umožňuje snadno spravovatelný životní cyklus od vývoje API až po jeho vyřazení. Software pomáhá zlepšit dodržování předpisů a licencí tím, že umožňuje podrobnou analýzu.
API10:2023 – Nebezpečná konzumace API
Co je to?
S rostoucím využíváním nativní cloudové infrastruktury k vytváření aplikací se API stala bodem integrace mezi komponentami aplikace. Bezpečnostní situace služeb třetích stran, ke kterým se přistupuje prostřednictvím API, je však zřídka jasná, což útočníkům umožňuje určit, na které služby se aplikace spoléhá a zda některá z těchto služeb má bezpečnostní slabiny. Vývojáři mají tendenci důvěřovat koncovým bodům, se kterými jejich aplikace interaguje, aniž by ověřovali externí API nebo API třetích stran. Toto nebezpečné využívání API často vede k tomu, že se aplikace spoléhá na služby, které mají slabší bezpečnostní požadavky nebo jim chybí základní posílení zabezpečení, jako je ověřování vstupu.
Co dělá aplikaci zranitelnou?
Vývojáři mají tendenci důvěřovat datům přijatým z API třetích stran více než uživatelským vstupům, ačkoliv jsou oba zdroje pro motivovaného útočníka v podstatě rovnocenné. Kvůli této nesprávné důvěře se vývojáři v podstatě spoléhají na slabší bezpečnostní standardy kvůli nedostatečnému ověření a sanitizaci vstupů.
K nebezpečnému užívání API může dojít, pokud aplikace:
· Používá nebo spotřebovává jiná API s využitím nešifrované komunikace,
· Nedokáže ověřit a sanitizovat data z jiných API nebo služeb,
· Umožňuje přesměrování bez jakýchkoli bezpečnostních kontrol, nebo
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
21/23
Pokud vývojář do své aplikace nenaprogramuje bezpečnostní kontroly, které by ověřily data vrácená koncovým bodem API, jeho aplikace se bude řídit přesměrováním a útočníkovi odešle citlivé lékařské informace.
OWASP API Security Top-10 je klíčová pro cloudově nativní vývojáře, kteří vytvářejí API. Řešení běžných zranitelností aplikací, jako je SQL injection, únik dat a chybná konfigurace zabezpečení, by však mělo mít prioritu, protože jsou často zneužívány kybernetickými hrozbami. API Security Top-10 je nezbytnou součástí bezpečného vývoje softwaru, ale mělo by být druhořadé oproti řešení obecných zranitelností aplikací.
· Nedokáže omezit spotřebu zdrojů pomocí prahových hodnot a časových limitů.
V exampPodle zprávy OWASP by API, které se integruje s poskytovatelem služeb třetí strany za účelem ukládání citlivých zdravotních informací uživatelů, mohlo odesílat soukromá data prostřednictvím koncového bodu API. Útočníci by mohli ohrozit hostitele API třetí strany a reagovat na budoucí požadavky trvalým přesměrováním 308: HTTP/1.1 308 Permanent Redirect
Místo: https://attacker.com/
Pokud vývojář do své aplikace nenaprogramuje bezpečnostní kontroly, které by ověřily data vrácená koncovým bodem API, jeho aplikace se bude řídit přesměrováním a útočníkovi odešle citlivé lékařské informace.
Útok bývalýamples
V prosinci 2021 umožnila sada zranitelností v běžně používané komponentě open-source softwaru Log4J útočníkovi poskytnout neošetřený vstup, například kódovaný skript, a použít zranitelné verze Log4J ke spuštění skriptu na serveru. Problém s touto zranitelností Log4J pramenil z nedostatečného ověření vstupu, konkrétně z neprovedení bezpečnostních kontrol deserializovaných dat dodaných uživatelem. Odesláním serializovaného škodlivého kódu mohli útočníci tuto zranitelnost zneužít a provést útok na server s touto zranitelností. Vývojáři by měli kontrolovat veškerý vstup poskytovaný API třetích stran a dalšími externími zdroji.27
Jak tomu vývojář zabránit?
Vývojáři by měli provádět due diligence při hodnocení poskytovatelů služeb, posuzování jejich zabezpečení API a implementaci přísných bezpečnostních kontrol. Vývojáři by navíc měli potvrdit, že veškerá komunikace s API třetích stran a od třetích stran k API organizace používá zabezpečený komunikační kanál, aby se zabránilo útokům typu snooping a replay.
Při přijímání dat od externích uživatelů a počítačů by měly být vstupy vždy „sanitizovány“, aby se zabránilo neúmyslnému spuštění kódu. A konečně, u cloudových služeb integrovaných prostřednictvím API by se měly používat seznamy povolených adres k uzamčení adresy integrovaného řešení, spíše než slepě povolovat volání API aplikace jakékoli IP adrese.
Jak může OpenText pomoci?
Kombinací funkcí analýzy statického kódu a API v nástroji OpenText Static Application Security Testing s běhovými kontrolami sady OpenText Dynamic Application Security Testing (DAST) mohou týmy DevSecOps kontrolovat používání API třetích stran ve svých aplikacích a testovat běžné typy útoků. Pro nalezení nebezpečných API může OpenText Secure API Manager vytvořit repozitář všech API volaných systémem a také to, které externí aplikace mohou používat API vaší aplikace.
27 Microsoft Threat Intelligence. Pokyny pro prevenci, detekci a vyhledávání zneužití zranitelnosti Log4j 2. Microsoft. Web stránka. Aktualizováno: 10. ledna 2022.
Průvodce vývojáře k žebříčku OWASP Top 2023 pro zabezpečení API pro rok 10
22/23
Kam dál
Zde jsou produkty zmíněné v tomto dokumentu: Zabezpečení aplikací OpenText >
Testování zabezpečení statických aplikací OpenText >
Testování zabezpečení dynamických aplikací OpenText >
Správce zabezpečeného API OpenTextu >
Další zdroje OWASP Top 10 bezpečnostních rizik API – 2023 >
Gartnerův magický kvadrant pro testování bezpečnosti aplikací >
Zabezpečení aplikací OpenText WebSérie inar >
Top 10 zabezpečení API nestačí!
Pro cloudové vývojáře, kteří se konkrétně zaměřují na vytváření API pro nabízení služeb jiným částem aplikace, interním uživatelům nebo pro globální spotřebu, je seznam OWASP API Security Top 10 důležitým dokumentem k přečtení a pochopení.
Dokument OWASP API Security Top 10 však není samostatným dokumentem. Vývojáři se také musí ujistit, že využívají další zdroje osvědčených postupů, jako je OWASP Top 10, které jsou relevantní pro jejich aktuální aplikaci a architekturu. Běžné zranitelnosti aplikací – SQL injection, únik dat a nesprávná konfigurace zabezpečení – jsou i nadále běžnými způsoby, jakými mohou skupiny kybernetických hrozeb ohrozit podnikovou infrastrukturu, a měly by být rychle odstraněny. Kromě toho některé aplikace založené na API, jako jsou mobilní aplikace, vyžadují jiné kroky zabezpečení aplikací než samostatný dokument. web-aplikace a liší se od toho, co může být vyžadováno pro zařízení Connect a IoT. Celkově je seznam 10 nejlepších bezpečnostních prvků API důležitý, ale zůstává pouze aspektem celkového životního cyklu vývoje bezpečného softwaru. Tento seznam a seznam 10 nejlepších prvků OWASP by měly být používány ve spojení s veškerými dalšími relevantními standardy a osvědčenými postupy, které jsou pro analyzované řešení vyžadovány.
Závěr
Vzhledem k tomu, že aplikace se stále více spoléhají na cloudovou infrastrukturu, web Rozhraní pro programování aplikací (API) se stala základem internetu. Společnosti mají ve svém prostředí obvykle stovky, ne-li tisíce koncových bodů API, což dramaticky zvyšuje jejich oblast útoku a vystavuje aplikace řadě slabin.
Zveřejnění seznamu OWASP API Security Top 2023 pro rok 10 je dobrým výchozím bodem pro firmy a vývojáře, aby se vzdělávali o rizicích infrastruktury založené na API a posoudili své vlastní aplikace. Spolu se známějším seznamem Application Security Top 10 může tato dvojice žebříčků pomoci týmům DevSecOps vyvinout holistický přístup k celkové bezpečnosti jejich aplikací.
Týmy DevSecOps si musí být vědomy bezpečnostních důsledků API, toho, jak snížit zranitelnosti a bezpečnostní slabiny implementace a jak posílit svůj vývojový proces a výsledný API server, aby útočníkům ztížily kompromitaci aplikace prostřednictvím jejích API.
Copyright © 2025 Otevřený text · 04.25 | 262-000177-001
Dokumenty / zdroje
 |
OpenText 262-000177-001 OWASP Top 10 pro zabezpečení API [pdfUživatelská příručka 262-000177-001, 262-000177-001 OWASP Top 10 pro zabezpečení API, 262-000177-001, OWASP Top 10 pro zabezpečení API, Pro zabezpečení API, Zabezpečení API, Zabezpečení |