Topp OATH API-sårbarheter
Topp OATH API-sårbarheter: Introduksjon
Når det gjelder utnyttelser, er APIer det beste stedet å starte. API tilgang består vanligvis av tre deler. Klienter utstedes tokens av en autorisasjonsserver, som kjører sammen med APIer. API-en mottar tilgangstokener fra klienten og bruker domenespesifikke autorisasjonsregler basert på dem.
Moderne programvareapplikasjoner er sårbare for en rekke farer. Hold deg oppdatert på de siste utnyttelsene og sikkerhetsfeilene; å ha benchmarks for disse sårbarhetene er avgjørende for å sikre applikasjonssikkerhet før et angrep skjer. Tredjepartsapplikasjoner er i økende grad avhengig av OAuth-protokollen. Brukere vil få en bedre generell brukeropplevelse, samt raskere pålogging og autorisasjon, takket være denne teknologien. Det kan være sikrere enn konvensjonell autorisasjon siden brukere ikke trenger å oppgi påloggingsinformasjonen med tredjepartsapplikasjonen for å få tilgang til en gitt ressurs. Selv om protokollen i seg selv er trygg og sikker, kan måten den implementeres på gjøre deg åpen for angrep.
Når du designer og er vert for APIer, fokuserer denne artikkelen på typiske OAuth-sårbarheter, samt ulike sikkerhetsreduksjoner.
Autorisasjon på brutt objektnivå
Det er en enorm angrepsoverflate hvis autorisasjonen brytes siden APIer gir tilgang til objekter. Siden API-tilgjengelige elementer må autentiseres, er dette nødvendig. Implementer autorisasjonssjekker på objektnivå ved hjelp av en API-gateway. Bare de med riktig tillatelseslegitimasjon skal få tilgang.
Ødelagt brukerautentisering
Uautoriserte tokens er en annen hyppig måte for angripere å få tilgang til APIer. Autentiseringssystemer kan bli hacket, eller en API-nøkkel kan bli avslørt ved en feiltakelse. Autentiseringstokener kan være brukt av hackere å få tilgang. Autentiser folk bare hvis de kan stole på, og bruk sterke passord. Med OAuth kan du gå lenger enn bare API-nøkler og få tilgang til dataene dine. Du bør alltid tenke på hvordan du kommer deg inn og ut av et sted. OAuth MTLS Sender Begrensede Tokens kan brukes sammen med Mutual TLS for å garantere at klienter ikke oppfører seg feil og sender tokens til feil part mens de får tilgang til andre maskiner.
API-kampanje:
Overdreven dataeksponering
Det er ingen begrensninger på antall endepunkter som kan publiseres. Det meste av tiden er ikke alle funksjoner tilgjengelige for alle brukere. Ved å eksponere mer data enn høyst nødvendig setter du deg selv og andre i fare. Unngå å avsløre sensitive informasjon til det er absolutt nødvendig. Utviklere kan spesifisere hvem som har tilgang til hva ved å bruke OAuth-omfang og krav. Krav kan spesifisere hvilke deler av dataene en bruker har tilgang til. Tilgangskontroll kan gjøres enklere og enklere å administrere ved å bruke en standardstruktur på tvers av alle APIer.
Mangel på ressurser og satsbegrensning
Svarte hatter bruker ofte tjenestenekt-angrep (DoS) som en brutal måte å overvelde en server og dermed redusere oppetiden til null. Uten restriksjoner på ressursene som kan kalles, er en API sårbar for et ødeleggende angrep. «Ved å bruke en API-gateway eller et administrasjonsverktøy kan du angi hastighetsbegrensninger for APIer. Filtrering og paginering bør inkluderes, i tillegg til at svar begrenses.
Feilkonfigurering av sikkerhetssystemet
Ulike retningslinjer for sikkerhetskonfigurasjon er ganske omfattende, på grunn av den betydelige sannsynligheten for feilkonfigurasjon av sikkerheten. En rekke små ting kan sette plattformens sikkerhet i fare. Det er mulig at svarte hatter med skjulte formål kan oppdage sensitiv informasjon sendt som svar på feilaktige forespørsler, for eksempel.
Massetildeling
Bare fordi et endepunkt ikke er offentlig definert, betyr det ikke at det ikke er tilgjengelig for utviklere. En hemmelig API kan lett bli fanget opp og reversert av hackere. Ta en titt på dette grunnleggende eksempelet, som bruker et åpent bærertoken i en "privat" API. På den annen side kan det finnes offentlig dokumentasjon for noe som utelukkende er ment for personlig bruk. Eksponert informasjon kan brukes av svarte hatter til ikke bare å lese, men også manipulere objektegenskaper. Betrakt deg selv som en hacker når du søker etter potensielle svake punkter i forsvaret ditt. Gi bare de med riktige rettigheter tilgang til det som ble returnert. For å minimere sårbarheten, begrense API-svarpakken. Respondenter bør ikke legge til lenker som ikke er absolutt nødvendige.
Markedsført API:
Feil aktivaforvaltning
Bortsett fra å forbedre utviklerproduktiviteten, er gjeldende versjoner og dokumentasjon avgjørende for din egen sikkerhet. Forbered deg på introduksjonen av nye versjoner og avviklingen av gamle API-er langt i forveien. Bruk nyere API-er i stedet for å la eldre være i bruk. En API-spesifikasjon kan brukes som en primær kilde til sannhet for dokumentasjon.
Injeksjon
API-er er sårbare for injeksjon, men det er også tredjeparts utviklerapper. Skadelig kode kan brukes til å slette data eller stjele konfidensiell informasjon, for eksempel passord og kredittkortnumre. Den viktigste lærdommen å ta med seg fra dette er å ikke være avhengig av standardinnstillingene. Din administrasjons- eller gateway-leverandør bør være i stand til å imøtekomme dine unike applikasjonsbehov. Feilmeldinger skal ikke inneholde sensitiv informasjon. For å forhindre at identitetsdata lekker utenfor systemet, bør parvise pseudonymer brukes i tokens. Dette sikrer at ingen klient kan jobbe sammen for å identifisere en bruker.
Utilstrekkelig logging og overvåking
Når et angrep finner sted, krever lagene en gjennomtenkt reaksjonsstrategi. Utviklere vil fortsette å utnytte sårbarheter uten å bli fanget hvis et pålitelig logg- og overvåkingssystem ikke er på plass, noe som vil øke tapene og skade publikums oppfatning av selskapet. Vedta en streng strategi for API-overvåking og produksjonsendepunktstesting. Testere av hvit lue som tidlig finner sårbarheter bør belønnes med en dusørordning. Loggsporet kan forbedres ved å inkludere brukerens identitet i API-transaksjoner. Sørg for at alle lagene i API-arkitekturen din blir revidert ved å bruke Access Token-data.
konklusjonen
Plattformarkitekter kan utstyre systemene sine til å holde et skritt foran angripere ved å følge etablerte sårbarhetskriterier. Fordi API-er kan gi tilgang til personlig identifiserbar informasjon (PII), er å opprettholde sikkerheten til slike tjenester avgjørende for både selskapets stabilitet og overholdelse av lovverk som GDPR. Send aldri OAuth-tokens direkte over et API uten å bruke en API-gateway og Phantom Token-tilnærmingen.
Markedsført API:
