De bästa OATH API-sårbarheterna
Bästa OATH API-sårbarheter: Intro
När det kommer till exploateringar är API:er det bästa stället att börja. API åtkomst består vanligtvis av tre delar. Klienter utfärdas tokens av en auktoriseringsserver, som körs tillsammans med API:er. API:et tar emot åtkomsttokens från klienten och tillämpar domänspecifika auktoriseringsregler baserat på dem.
Moderna mjukvaruapplikationer är sårbara för en mängd olika faror. Håll dig uppdaterad om de senaste bedrifterna och säkerhetsbristerna; att ha riktmärken för dessa sårbarheter är viktigt för att säkerställa applikationssäkerhet innan en attack inträffar. Tredjepartsapplikationer förlitar sig alltmer på OAuth-protokollet. Användare kommer att få en bättre övergripande användarupplevelse, samt snabbare inloggning och auktorisering, tack vare denna teknik. Det kan vara säkrare än konventionell auktorisering eftersom användare inte behöver avslöja sina referenser med tredjepartsapplikationen för att få åtkomst till en given resurs. Även om själva protokollet är säkert och säkert, kan sättet det implementeras på lämna dig öppen för attacker.
När du designar och är värd för API:er fokuserar den här artikeln på typiska OAuth-sårbarheter, såväl som olika säkerhetsåtgärder.
Broken Object Level Authorization
Det finns en enorm attackyta om auktorisationen kränks eftersom API:er ger tillgång till objekt. Eftersom API-tillgängliga objekt måste autentiseras är detta nödvändigt. Implementera auktoriseringskontroller på objektnivå med en API-gateway. Endast de med rätt behörighetsuppgifter bör tillåtas åtkomst.
Trasig användarautentisering
Obehöriga tokens är ett annat vanligt sätt för angripare att få tillgång till API:er. Autentiseringssystem kan ha hackats eller så kan en API-nyckel avslöjas av misstag. Autentiseringstoken kan vara används av hackare att få tillgång. Autentisera personer endast om de kan lita på och använd starka lösenord. Med OAuth kan du gå längre än bara API-nycklar och få tillgång till dina data. Du bör alltid tänka på hur du kommer in och ut från en plats. OAuth MTLS-avsändarbegränsade tokens kan användas tillsammans med Mutual TLS för att garantera att klienter inte missköter sig och skickar tokens till den felaktiga parten när de kommer åt andra maskiner.
API-kampanj:
Överdriven dataexponering
Det finns inga begränsningar för antalet slutpunkter som kan publiceras. För det mesta är inte alla funktioner tillgängliga för alla användare. Genom att exponera mer data än vad som är absolut nödvändigt utsätter du dig själv och andra för fara. Undvik att avslöja känsliga informationen tills det är absolut nödvändigt. Utvecklare kan ange vem som har tillgång till vad genom att använda OAuth-omfattningar och anspråk. Anspråk kan specificera vilka delar av data en användare har tillgång till. Åtkomstkontroll kan göras enklare och lättare att hantera genom att använda en standardstruktur över alla API:er.
Brist på resurser och prisbegränsning
Svarta hattar använder ofta denial-of-service (DoS)-angrepp som ett brutalt sätt att överväldiga en server och på så sätt minska dess drifttid till noll. Utan några begränsningar för de resurser som kan anropas är ett API sårbart för ett försvagande angrepp. "Med hjälp av en API-gateway eller ett hanteringsverktyg kan du ställa in hastighetsbegränsningar för API:er. Filtrering och sidnumrering bör inkluderas, liksom att svar begränsas.
Felkonfiguration av säkerhetssystemet
Olika riktlinjer för säkerhetskonfiguration är ganska omfattande, på grund av den stora sannolikheten för felkonfiguration av säkerheten. Ett antal små saker kan äventyra din plattforms säkerhet. Det är möjligt att svarta hattar med bakomliggande syften kan upptäcka känslig information som skickas som svar på felaktiga frågor, som ett exempel.
Massuppdrag
Bara för att en slutpunkt inte är offentligt definierad betyder det inte att den inte kan nås av utvecklare. Ett hemligt API kan lätt fångas upp och omvändas av hackare. Ta en titt på detta grundläggande exempel, som använder ett öppet bärartoken i ett "privat" API. Å andra sidan kan det finnas offentlig dokumentation för något som uteslutande är avsett för personligt bruk. Exponerad information kan användas av svarta hattar för att inte bara läsa utan också manipulera objektegenskaper. Se dig själv som en hacker när du söker efter potentiella svaga punkter i ditt försvar. Tillåt endast de med korrekta rättigheter tillgång till det som returnerades. För att minimera sårbarheten, begränsa API-svarspaketet. Respondenter ska inte lägga till några länkar som inte är absolut nödvändiga.
Marknadsfört API:
Felaktig tillgångshantering
Förutom att förbättra utvecklarens produktivitet är aktuella versioner och dokumentation väsentliga för din egen säkerhet. Förbered dig på introduktionen av nya versioner och utfasningen av gamla API:er långt i förväg. Använd nyare API:er istället för att tillåta äldre att fortsätta använda. En API-specifikation skulle kunna användas som en primär sanningskälla för dokumentation.
Injektion
API:er är sårbara för injektion, men det är även tredjepartsappar för utvecklare. Skadlig kod kan användas för att radera data eller stjäla konfidentiell information, såsom lösenord och kreditkortsnummer. Den viktigaste lärdomen att ta med sig från detta är att inte vara beroende av standardinställningarna. Din hanterings- eller gatewayleverantör bör kunna tillgodose dina unika applikationsbehov. Felmeddelanden ska inte innehålla känslig information. För att förhindra att identitetsdata läcker utanför systemet bör parvisa pseudonymer användas i tokens. Detta säkerställer att ingen klient får arbeta tillsammans för att identifiera en användare.
Otillräcklig loggning och övervakning
När en attack äger rum kräver lag en genomtänkt reaktionsstrategi. Utvecklare kommer att fortsätta att utnyttja sårbarheter utan att fångas om ett tillförlitligt loggnings- och övervakningssystem inte finns på plats, vilket kommer att öka förlusterna och skada allmänhetens uppfattning om företaget. Anta en strikt strategi för API-övervakning och produktionsslutpunktstestning. Testare av vita hattar som tidigt upptäcker sårbarheter bör belönas med ett bounty-system. Loggspåret kan förbättras genom att inkludera användarens identitet i API-transaktioner. Se till att alla lager i din API-arkitektur granskas med hjälp av Access Token-data.
Slutsats
Plattformsarkitekter kan utrusta sina system för att ligga steget före angripare genom att följa etablerade sårbarhetskriterier. Eftersom API:er kan ge tillgång till personligt identifierbar information (PII), är upprätthållande av säkerheten för sådana tjänster avgörande för både företagets stabilitet och efterlevnad av lagstiftning som GDPR. Skicka aldrig OAuth-tokens direkt över ett API utan att använda en API-gateway och Phantom Token Approach.
Marknadsfört API:
