Hlavné chyby zabezpečenia rozhrania OATH API
Hlavné chyby zabezpečenia rozhrania OATH API: Úvod
Pokiaľ ide o exploity, API sú najlepším miestom, kde začať. API prístup zvyčajne pozostáva z troch častí. Klientom vydáva tokeny autorizačný server, ktorý beží spolu s rozhraniami API. Rozhranie API prijíma prístupové tokeny od klienta a na základe nich aplikuje pravidlá autorizácie špecifické pre doménu.
Moderné softvérové aplikácie sú náchylné na rôzne nebezpečenstvá. Udržujte si prehľad o najnovších exploitoch a bezpečnostných chybách; mať referenčné hodnoty pre tieto zraniteľnosti je nevyhnutné na zaistenie bezpečnosti aplikácie predtým, ako dôjde k útoku. Aplikácie tretích strán sa čoraz viac spoliehajú na protokol OAuth. Používatelia budú mať vďaka tejto technológii celkovo lepšiu používateľskú skúsenosť, ako aj rýchlejšie prihlasovanie a autorizáciu. Môže byť bezpečnejšia ako konvenčná autorizácia, pretože používatelia nemusia zverejňovať svoje poverenia v aplikácii tretej strany, aby mali prístup k danému zdroju. Aj keď je samotný protokol bezpečný a bezpečný, spôsob jeho implementácie vás môže nechať otvoreným útoku.
Pri navrhovaní a hosťovaní rozhraní API sa tento článok zameriava na typické chyby zabezpečenia protokolu OAuth, ako aj na rôzne bezpečnostné opatrenia.
Autorizácia na úrovni poškodeného objektu
Ak dôjde k porušeniu autorizácie, existuje veľká plocha útoku, pretože rozhrania API poskytujú prístup k objektom. Keďže položky prístupné cez rozhranie API musia byť overené, je to nevyhnutné. Implementujte kontroly autorizácie na úrovni objektu pomocou brány API. Prístup by mal mať povolený iba ten, kto má príslušné oprávnenia.
Zlomené overenie používateľa
Neautorizované tokeny sú ďalším častým spôsobom, ako môžu útočníci získať prístup k rozhraniam API. Autentifikačné systémy môžu byť napadnuté alebo môže byť omylom odhalený kľúč API. Autentifikačné tokeny môžu byť používané hackermi získať prístup. Overujte ľudí iba vtedy, ak im možno dôverovať, a používajte silné heslá. S OAuth môžete ísť nad rámec obyčajných kľúčov API a získať prístup k svojim údajom. Vždy by ste mali premýšľať o tom, ako sa dostanete na miesto a z neho. Tokeny OAuth MTLS Sender Constrained Tokens možno použiť v spojení s vzájomným TLS, aby sa zaručilo, že sa klienti nebudú správať zle a neodovzdajú tokeny nesprávnej strane pri pristupovaní k iným počítačom.
Propagácia rozhrania API:
Nadmerné vystavenie údajom
Neexistujú žiadne obmedzenia týkajúce sa počtu koncových bodov, ktoré možno zverejniť. Vo väčšine prípadov nie sú všetky funkcie dostupné všetkým používateľom. Odhalením väčšieho množstva údajov, ako je absolútne nevyhnutné, vystavujete seba aj ostatných nebezpečenstvu. Vyhnite sa prezradeniu citlivých informácie kým to nebude absolútne nevyhnutné. Vývojári môžu určiť, kto má k čomu prístup, pomocou rozsahov a nárokov OAuth. Nároky môžu špecifikovať, ku ktorým častiam údajov má používateľ prístup. Riadenie prístupu môže byť jednoduchšie a ľahšie spravovateľné použitím štandardnej štruktúry naprieč všetkými API.
Nedostatok zdrojov a obmedzovanie sadzieb
Black hats často používajú útoky odmietnutia služby (DoS) ako spôsob hrubej sily, ako zahltiť server a tak znížiť jeho prevádzkyschopnosť na nulu. Bez obmedzenia zdrojov, ktoré možno volať, je API zraniteľné voči oslabujúcemu útoku. „Pomocou brány API alebo nástroja na správu môžete nastaviť obmedzenia rýchlosti pre rozhrania API. Malo by byť zahrnuté filtrovanie a stránkovanie, ako aj obmedzenie odpovedí.
Nesprávna konfigurácia bezpečnostného systému
Rôzne usmernenia pre konfiguráciu zabezpečenia sú pomerne obsiahle z dôvodu značnej pravdepodobnosti nesprávnej konfigurácie zabezpečenia. Bezpečnosť vašej platformy môže ohroziť množstvo maličkostí. Je možné, že čierne klobúky s postrannými účelmi môžu napríklad objaviť citlivé informácie odoslané v odpovedi na nesprávne formátované dopyty.
Hromadné pridelenie
To, že koncový bod nie je verejne definovaný, neznamená, že k nemu vývojári nemôžu pristupovať. Tajné API môžu hackeri ľahko zachytiť a spätne skonštruovať. Pozrite sa na tento základný príklad, ktorý používa otvorený token nositeľa v „súkromnom“ rozhraní API. Na druhej strane môže existovať verejná dokumentácia pre niečo, čo je určené výlučne na osobné použitie. Exponované informácie môžu čierne klobúky použiť nielen na čítanie, ale aj na manipuláciu s charakteristikami objektu. Považujte sa za hackera, keď hľadáte potenciálne slabé miesta vo svojej obrane. Povoliť prístup k tomu, čo bolo vrátené, iba tým, ktorí majú príslušné práva. Ak chcete minimalizovať zraniteľnosť, obmedzte balík odpovedí API. Respondenti by nemali pridávať žiadne odkazy, ktoré nie sú absolútne povinné.
Propagované API:
Nesprávna správa aktív
Okrem zvyšovania produktivity vývojárov sú aktuálne verzie a dokumentácia nevyhnutné pre vašu vlastnú bezpečnosť. Pripravte sa na predstavenie nových verzií a ukončenie podpory starých API s veľkým predstihom. Použite novšie rozhrania API namiesto toho, aby ste umožnili, aby sa tie staršie naďalej používali. Špecifikácia API by sa mohla použiť ako primárny zdroj pravdy pre dokumentáciu.
Injekcia
Rozhrania API sú zraniteľné voči vstrekovaniu, ale aj aplikácie pre vývojárov tretích strán. Škodlivý kód môže byť použitý na odstránenie údajov alebo odcudzenie dôverných informácií, ako sú heslá a čísla kreditných kariet. Najdôležitejšou lekciou, ktorú si z toho treba odniesť, je nezávisieť od predvolených nastavení. Váš manažment alebo dodávateľ brány by mal byť schopný vyhovieť vašim jedinečným potrebám aplikácií. Chybové hlásenia by nemali obsahovať citlivé informácie. Aby sa predišlo úniku údajov o identite mimo systému, mali by sa v tokenoch používať Pseudonymy. To zaisťuje, že žiadny klient nemôže spolupracovať pri identifikácii používateľa.
Nedostatočné zaznamenávanie a monitorovanie
Keď dôjde k útoku, tímy vyžadujú dobre premyslenú stratégiu reakcie. Vývojári budú pokračovať vo využívaní zraniteľných miest bez toho, aby boli prichytení, ak nebude zavedený spoľahlivý systém zaznamenávania a monitorovania, čo zvýši straty a poškodí vnímanie spoločnosti verejnosťou. Prijmite prísnu stratégiu monitorovania API a testovania koncových bodov produkcie. Testeri bieleho klobúka, ktorí včas zistia zraniteľnosť, by mali byť odmenení schémou odmien. Záznamovú stopu možno zlepšiť zahrnutím identity používateľa do transakcií API. Zaistite, aby boli všetky vrstvy vašej architektúry API auditované pomocou údajov prístupového tokenu.
záver
Architekti platforiem môžu vybaviť svoje systémy tak, aby boli o krok vpred pred útočníkmi dodržiavaním stanovených kritérií zraniteľnosti. Keďže API môžu poskytovať prístup k Osobne identifikovateľným informáciám (PII), udržiavanie bezpečnosti takýchto služieb je rozhodujúce pre stabilitu spoločnosti a súlad s legislatívou, ako je GDPR. Nikdy neposielajte tokeny OAuth priamo cez rozhranie API bez použitia brány API a prístupu Phantom Token Approach.
Propagované API:
