Legnépszerűbb OATH API biztonsági rések
Legfőbb OATH API biztonsági rések: Bevezetés
Ha a kizsákmányolásról van szó, az API-k jelentik a legjobb kiindulópontot. API a hozzáférés általában három részből áll. A kliensek tokenjeit egy engedélyezési kiszolgáló bocsátja ki, amely az API-k mellett fut. Az API hozzáférési tokeneket kap az ügyféltől, és ezek alapján tartományspecifikus engedélyezési szabályokat alkalmaz.
A modern szoftveralkalmazások számos veszélynek vannak kitéve. Legyen naprakész a legújabb kizsákmányolásokkal és biztonsági hibákkal kapcsolatban; A sérülékenységek referenciaértékei elengedhetetlenek az alkalmazások biztonságának biztosításához, mielőtt támadás történik. A harmadik féltől származó alkalmazások egyre inkább az OAuth protokollra támaszkodnak. Ennek a technológiának köszönhetően a felhasználók jobb általános felhasználói élményben, valamint gyorsabb bejelentkezésben és hitelesítésben részesülnek. Biztonságosabb lehet, mint a hagyományos engedélyezés, mivel a felhasználóknak nem kell felfedniük hitelesítési adataikat a harmadik féltől származó alkalmazásban, hogy hozzáférjenek egy adott erőforráshoz. Noha maga a protokoll biztonságos, a megvalósítás módja nyitva hagyhatja a támadásokat.
Az API-k tervezése és üzemeltetése során ez a cikk a tipikus OAuth-sebezhetőségekre, valamint a különféle biztonsági intézkedésekre összpontosít.
Törött objektumszintű jogosultság
Hatalmas támadási felület áll rendelkezésre, ha a jogosultságot megsértik, mivel az API-k hozzáférést biztosítanak az objektumokhoz. Mivel az API-hoz elérhető elemeket hitelesíteni kell, ez szükséges. Végezzen objektumszintű engedélyezési ellenőrzéseket API-átjáró segítségével. Csak azok férhetnek hozzá, akik rendelkeznek a megfelelő jogosultságokkal.
Törött felhasználói hitelesítés
A jogosulatlan tokenek egy másik gyakori módja annak, hogy a támadók hozzáférjenek az API-khoz. Előfordulhat, hogy a hitelesítési rendszereket feltörték, vagy tévedésből egy API-kulcs kerül nyilvánosságra. A hitelesítési tokenek lehetnek hackerek használják hozzáférést szerezni. Csak akkor hitelesítsen személyeket, ha megbízhatnak bennük, és használjon erős jelszavakat. Az OAuth segítségével túlléphet az API-kulcsokon, és hozzáférhet adataihoz. Mindig gondolkodnia kell azon, hogyan fog ki- és bejutni egy helyre. Az OAuth MTLS Sender Constrained Tokenek a Mutual TLS-szel együtt használhatók annak biztosítására, hogy az ügyfelek ne viselkedjenek helytelenül, és ne adjanak át tokeneket a helytelen félnek, miközben más gépekhez hozzáférnek.
API promóció:
Túlzott adatexpozíció
A közzétehető végpontok számára nincs korlátozás. A legtöbb esetben nem minden funkció érhető el minden felhasználó számára. Ha a feltétlenül szükségesnél több adatot tesz közzé, veszélybe sodorja magát és másokat. Kerülje az érzékeny felfedését információ amíg feltétlenül szükséges. A fejlesztők az OAuth-hatókörök és követelések használatával meghatározhatják, hogy kinek mihez van hozzáférése. A követelések meghatározhatják, hogy a felhasználó az adatok mely részeihez férhet hozzá. A hozzáférés-vezérlés egyszerűbbé és könnyebben kezelhetővé tehető, ha szabványos struktúrát használ az összes API-n.
Erőforrások hiánya és díjkorlátozás
A fekete kalapok gyakran használnak szolgáltatásmegtagadási (DoS) támadásokat, mint brutális erejű módot arra, hogy túlterheljék a szervert, és így nullára csökkentsék annak üzemidejét. A hívható erőforrásokra vonatkozó korlátozások nélkül az API sebezhető egy legyengítő támadással szemben. „API-átjáró vagy felügyeleti eszköz használatával díjkorlátozásokat állíthat be az API-kra. A szűrést és az oldalszámozást tartalmaznia kell, valamint a válaszokat korlátozni kell.
A biztonsági rendszer hibás beállítása
A különböző biztonsági konfigurációs irányelvek meglehetősen átfogóak a biztonsági hibás konfiguráció jelentős valószínűsége miatt. Számos apró dolog veszélyeztetheti a platform biztonságát. Lehetséges, hogy a fekete kalapok hátsó céllal például hibás lekérdezésekre válaszul küldött érzékeny információkat fedezhetnek fel.
Tömegfeladat
Csak azért, mert egy végpont nincs nyilvánosan definiálva, nem jelenti azt, hogy a fejlesztők nem férhetnek hozzá. A titkos API-t könnyen elfoghatják és visszafordíthatják a hackerek. Vessen egy pillantást erre az alappéldára, amely egy nyitott Bearer Tokent használ egy „privát” API-ban. Másrészt nyilvános dokumentáció létezhet olyan dologhoz, amelyet kizárólag személyes használatra szánnak. A kitett információkat a fekete kalap felhasználhatja nemcsak olvasásra, hanem az objektum jellemzőinek manipulálására is. Tekintsd magad hackernek, miközben potenciális gyenge pontokat keresel a védelmedben. Csak a megfelelő jogosultsággal rendelkezőknek engedjen hozzáférést a visszaküldöttekhez. A sebezhetőség minimalizálása érdekében korlátozza az API válaszcsomagot. A válaszadók ne adjanak hozzá olyan linkeket, amelyek nem feltétlenül szükségesek.
Promoted API:
Helytelen vagyonkezelés
A fejlesztői termelékenység fokozása mellett a jelenlegi verziók és a dokumentáció elengedhetetlenek az Ön biztonsága érdekében. Készüljön fel az új verziók bevezetésére és a régi API-k elavultságára. Használjon újabb API-kat ahelyett, hogy engedélyezné a régebbiek használatban maradását. Az API-specifikáció elsődleges igazságforrásként használható a dokumentációhoz.
Injekció
Az API-k sebezhetőek az injekcióval szemben, de a harmadik féltől származó fejlesztői alkalmazások is. A rosszindulatú kód felhasználható adatok törlésére vagy bizalmas információk, például jelszavak és hitelkártyaszámok ellopására. A legfontosabb tanulság ebből az, hogy ne függjön az alapértelmezett beállításoktól. Az Ön menedzsmentjének vagy átjáró-szállítójának képesnek kell lennie az Ön egyedi alkalmazási igényeinek kielégítésére. A hibaüzenetek nem tartalmazhatnak bizalmas információkat. Annak elkerülése érdekében, hogy a személyazonossági adatok kiszivárogjanak a rendszeren kívül, a tokenekben páros álneveket kell használni. Ez biztosítja, hogy egyetlen kliens se működhessen együtt a felhasználó azonosításában.
Nem megfelelő naplózás és felügyelet
Ha támadás történik, a csapatoknak jól átgondolt reakcióstratégiára van szükségük. A fejlesztők továbbra is kihasználják a sebezhetőségeket anélkül, hogy elkapnák őket, ha nem működik megbízható naplózó és megfigyelő rendszer, ami növeli a veszteségeket és rontja a közvélemény vállalatról alkotott képét. Szigorú API-felügyeleti és termelési végpont-tesztelési stratégiát kell alkalmazni. A sebezhetőséget korán felfedező fehérkalap-tesztelőket jutalomdíjjal kell jutalmazni. A naplókövetés javítható a felhasználó identitásának az API-tranzakciókba való felvételével. Győződjön meg arról, hogy az API architektúrája minden rétegét az Access Token adatok használatával auditálja.
Következtetés
A platformtervezők felszerelhetik rendszereiket, hogy egy lépéssel a támadók előtt járjanak a megállapított sebezhetőségi kritériumok betartásával. Mivel az API-k hozzáférést biztosíthatnak a személyazonosításra alkalmas adatokhoz (PII), az ilyen szolgáltatások biztonságának fenntartása kritikus fontosságú mind a vállalat stabilitása, mind a jogszabályok, például a GDPR betartása szempontjából. Soha ne küldjön OAuth-tokeneket közvetlenül API-n keresztül API-átjáró és a Phantom Token Approach használata nélkül.
Promoted API:
