Top OATH API sårbarheder
Top OATH API sårbarheder: Intro
Når det kommer til udnyttelser, er API'er det bedste sted at starte. API adgang består normalt af tre dele. Klienter får udstedt tokens af en autorisationsserver, som kører sammen med API'er. API'en modtager adgangstokens fra klienten og anvender domænespecifikke godkendelsesregler baseret på dem.
Moderne softwareapplikationer er sårbare over for en række farer. Hold dig opdateret om de seneste udnyttelser og sikkerhedsfejl; at have benchmarks for disse sårbarheder er afgørende for at sikre applikationssikkerhed, før et angreb sker. Tredjepartsapplikationer er i stigende grad afhængige af OAuth-protokollen. Brugere vil få en bedre samlet brugeroplevelse samt hurtigere login og autorisation takket være denne teknologi. Det kan være mere sikkert end konventionel godkendelse, da brugere ikke behøver at afsløre deres legitimationsoplysninger med tredjepartsapplikationen for at få adgang til en given ressource. Selvom selve protokollen er sikker, kan den måde, den implementeres på, gøre dig åben for angreb.
Når du designer og hoster API'er, fokuserer denne artikel på typiske OAuth-sårbarheder såvel som forskellige sikkerhedsbegrænsninger.
Autorisation på brudt objektniveau
Der er en enorm angrebsflade, hvis autorisation overtrædes, da API'er giver adgang til objekter. Da API-tilgængelige elementer skal godkendes, er dette nødvendigt. Implementer autorisationstjek på objektniveau ved hjælp af en API-gateway. Kun personer med de relevante tilladelsesoplysninger bør have adgang.
Ødelagt brugergodkendelse
Uautoriserede tokens er en anden hyppig måde for angribere at få adgang til API'er. Godkendelsessystemer kan blive hacket, eller en API-nøgle kan blive afsløret ved en fejl. Godkendelsestokens kan være brugt af hackere at få adgang. Godkend kun personer, hvis de kan stole på, og brug stærke adgangskoder. Med OAuth kan du gå videre end blot API-nøgler og få adgang til dine data. Du bør altid tænke over, hvordan du kommer ind og ud af et sted. OAuth MTLS Sender Constrained Tokens kan bruges sammen med Mutual TLS for at garantere, at klienter ikke opfører sig forkert og videregiver tokens til den forkerte part, mens de får adgang til andre maskiner.
API-promovering:
Overdreven dataeksponering
Der er ingen begrænsninger på antallet af endepunkter, der må offentliggøres. Det meste af tiden er ikke alle funktioner tilgængelige for alle brugere. Ved at eksponere flere data end højst nødvendigt bringer du dig selv og andre i fare. Undgå at afsløre følsomme oplysninger indtil det er absolut nødvendigt. Udviklere kan angive, hvem der har adgang til hvad ved at bruge OAuth-omfang og -krav. Krav kan angive, hvilke dele af data en bruger har adgang til. Adgangskontrol kan gøres enklere og nemmere at administrere ved at bruge en standardstruktur på tværs af alle API'er.
Mangel på ressourcer og satsbegrænsning
Sorte hatte bruger ofte denial-of-service (DoS)-angreb som en brutal-force måde at overvælde en server og dermed reducere dens oppetid til nul. Uden begrænsninger på de ressourcer, der kan kaldes, er en API sårbar over for et invaliderende overfald. 'Ved at bruge en API-gateway eller et administrationsværktøj kan du indstille hastighedsbegrænsninger for API'er. Filtrering og paginering bør inkluderes, ligesom svar begrænses.
Fejlkonfiguration af sikkerhedssystemet
Forskellige retningslinjer for sikkerhedskonfiguration er ret omfattende på grund af den betydelige sandsynlighed for fejlkonfiguration af sikkerheden. En række små ting kan bringe din platforms sikkerhed i fare. Det er muligt, at sorte hatte med skjulte formål kan opdage følsomme oplysninger sendt som svar på forkerte forespørgsler, som et eksempel.
Masseopgave
Bare fordi et slutpunkt ikke er offentligt defineret, betyder det ikke, at det ikke kan tilgås af udviklere. En hemmelig API kan let opsnappes og omvendt udvikles af hackere. Tag et kig på dette grundlæggende eksempel, som bruger et åbent bærertoken i en "privat" API. På den anden side kan der eksistere offentlig dokumentation for noget, der udelukkende er beregnet til personlig brug. Eksponeret information kan bruges af sorte hatte til ikke kun at læse, men også manipulere objektkarakteristika. Betragt dig selv som en hacker, når du leder efter potentielle svage punkter i dit forsvar. Tillad kun dem med de rette rettigheder adgang til det, der blev returneret. For at minimere sårbarheden skal du begrænse API-svarpakken. Respondenter bør ikke tilføje links, der ikke er absolut nødvendige.
Promoveret API:
Forkert Asset Management
Udover at forbedre udviklerproduktiviteten er aktuelle versioner og dokumentation afgørende for din egen sikkerhed. Forbered dig på introduktionen af nye versioner og udfasningen af gamle API'er langt i forvejen. Brug nyere API'er i stedet for at tillade ældre at forblive i brug. En API-specifikation kunne bruges som en primær kilde til sandhed til dokumentation.
Injektion
API'er er sårbare over for injektion, men det er tredjeparts udvikler-apps også. Ondsindet kode kan blive brugt til at slette data eller stjæle fortrolige oplysninger, såsom adgangskoder og kreditkortnumre. Den vigtigste lektie at tage væk fra dette er ikke at være afhængig af standardindstillingerne. Din administrations- eller gateway-leverandør bør være i stand til at imødekomme dine unikke applikationsbehov. Fejlmeddelelser bør ikke indeholde følsomme oplysninger. For at forhindre identitetsdata i at lække uden for systemet, bør parvise pseudonymer bruges i tokens. Dette sikrer, at ingen klient må arbejde sammen om at identificere en bruger.
Utilstrækkelig logning og overvågning
Når et angreb finder sted, kræver hold en gennemtænkt reaktionsstrategi. Udviklere vil fortsætte med at udnytte sårbarheder uden at blive fanget, hvis et pålideligt log- og overvågningssystem ikke er på plads, hvilket vil øge tab og skade offentlighedens opfattelse af virksomheden. Vedtag en streng API-overvågning og produktionsendepunktsteststrategi. White hat testere, der finder sårbarheder tidligt, bør belønnes med en dusørordning. Logsporet kan forbedres ved at inkludere brugerens identitet i API-transaktioner. Sørg for, at alle lag i din API-arkitektur er revideret ved at bruge Access Token-data.
Konklusion
Platformarkitekter kan udstyre deres systemer til at være et skridt foran angribere ved at følge etablerede sårbarhedskriterier. Fordi API'er kan give adgang til personligt identificerbare oplysninger (PII), er opretholdelse af sikkerheden af sådanne tjenester afgørende for både virksomhedens stabilitet og overholdelse af lovgivning såsom GDPR. Send aldrig OAuth-tokens direkte over en API uden at bruge en API-gateway og Phantom Token-tilgangen.
Promoveret API:
