Denne artikkelen vil håndtere de kjente OAuth-sårbarhetene. Leserne vil også lære å implementere sikker og sikker autorisasjon i webapplikasjonen.
OAuth er en pålitelig protokoll, men dens grad av sikkerhet avhenger i stor grad av bevisstheten om webutviklere når man implementerer autorisasjon. Dette gjør dette emnet ekstremt viktig for informasjonssikkerhetspersonell. De trenger å gi et høyt nivå av beskyttelse av kontoene til brukerne. Det er på tide å bli kjent med effektive utøvere som vil bidra til å redusere faren for dårlig salg av OAuth.
IntroduksjonOAuth 2.0-protokollen er for tiden mye brukt i ulike applikasjoner. Ved hjelp av det blir et praktisk brukergrensesnitt tilgjengelig, enklere autentisering og autorisasjon i forhold til tradisjonelle metoder for å skrive inn brukernavn og passord. Med riktig og gjennomtenkt implementering vil OAuth-protokollen være tryggere enn tradisjonell autorisasjon, siden brukerne ikke trenger å dele sine regnskapsdata med et tredjepartsapplikasjon for å få tilgang til en bestemt ressurs. Brukere foretrekker ofte å logge på med sine Google-kontoer, Facebook eller LinkedIn, i stedet for å opprette en ny konto hver gang du trenger å registrere deg på et nettsted. Dermed forenker OAuth-protokollen sterkt våre liv.
Generelt er populære OAuth-tjenesteleverandører svært pålitelige. Logg inn med Google eller Facebook-konto inspirerer en viss følelse av sikkerhet, og den er riktig. Protokollen er nøye testet av eksperter. Alle tilgjengelige sårbarheter korrigeres alltid raskt av utviklerlaget. Det er imidlertid verdt å merke seg at følelsen av fullstendig sikkerhet kan være feil.
Oauth-tjenesteleverandører forlot applikasjonsutviklere mange grunner til å hevde sikkerheten til deres programmer. Faktisk kan den opprinnelig beskyttede OAuth-tjenesten, feil implementert i prosessen med installasjonen, bli et enkelt mål for inntrengere. Slike preoccupacy vil føre til tyveri av personopplysninger av brukere.
Deretter bør du vurdere de vanligste sårbarhetene som oppstår i tredjeparts applikasjoner som implementerer Oauth-protokollen for å godkjenne sine brukere. Det må huskes at protokollen selv er trygg og pålitelig. Først etter feil implementering blir det sårbar for hackerangrep.
OAUTH TOCKEY THEFT BRUKE THE CERENTER HEEVERNår programmet ber om autorisasjon på vegne av brukeren på OAuth-serveren, mottar en person koden for å komme inn og sende tilbake til serveren for den påfølgende sjekken. Hvis brukeren blir omdirigert til en annen side, vil koden bli sett i "Referer" overskriften til HTTP-forespørselen. Dermed vil koden falle på det eksterne nettstedet, som vil true brukerdataene som er registrert på OAuth-serveren.
Merk: Referertoverskriften er en HTTP-spørringshode, den overfører nettadressen som er sendt inn.
For å myke konsekvensene av dette sikkerhetsproblemet må utvikleren sørge for at nettprogrammet ikke inneholder html-injeksjoner. Hvis injeksjonene ble oppdaget, kan angriperen enkelt sette bildekoden til sin webserver og finne en måte å omdirigere brukeren på den. Dermed vil han få muligheten til å stjele koden fra "Referer" overskriften til HTTP-forespørselen.
OAuth Tockey Theft Bruke Redirect_uri-parameterenSøknaden starter autorisasjonsprosessen ved å sende en forespørsel til OAuth-serveren:
https://www.example.com/signin/Authorize ?[uri=https://demo.example.com/loginsuccessful.
Spørringen inneholder alltid parameteren "Redirect_uri" som brukes av OAuth-serveren til å sende tokens tilbake til programmet etter at brukeren ga sitt samtykke. Hvis verdien av denne parameteren ikke er kontrollert eller ikke merket, kan angriperen enkelt endre den og omdirigere forespørselen til nettsiden, der den bruker et spesielt program for behandling av token og få tilgang til en begrenset ressurs.
https://www.example.com/signin/authorize ?[uri=https://localhost.evil.com.
Noen ganger er lignende nettadresser blokkert. Angriperen kan omdirigere de mottatte dataene på den åpne nettadressen, slik:
https://www.example.com/oauth20_Authorize.srf ?[..._&redirect_uri=https://accounts.google.com/backtouthsubtarget?next=httpset://evil.com.
Eller dette:
https://www.example.com/oauth2/Authorize? [...]% ict_uri = https% 3A% 2f% 2fapps.facebook.com% 2fattacker% 2f.
Når du implementerer OAuth, kan du aldri inkludere hele domener i den hvite listen. Bare noen få nettadresser bør legges til "Redirect_uri", ikke omdirigert en forespørsel om å åpne omdirigering.
Forfalskning av krysslinjeforespørslerForfalskning av en kryssforespørsel kan oppstå når en angriper lykkes med å gjøre offeret til å klikke på hans lenke og dermed for å generere en forespørsel om at han ikke skulle generere. Forfalskning av krysslinjeforespørsler er vanligvis myknet med CSRF-token, som er knyttet til brukerens økt. Det hjelper søknaden til å sjekke personen til en person som sendte forespørselen. "Statens" parameter i OAuth-protokollen fungerer som CSRF-token.
Det er verdt å se hvordan CSRF-angrepet utføres på OAuth, og som "State" -parameteren kan brukes til å redusere virkningen av sårbarhet.
Hacker åpner et webapplikasjon og lanserer autorisasjonsprosessen for å få tilgang til tjenesteleverandøren ved hjelp av OAuth. Søknaden ber om en tjenesteleverandør for å få tilgang til som må leveres. Hacker vil bli omdirigert til tjenesteleverandøren, hvor du vanligvis må angi brukernavn og passord for å godkjenne tilgangen. I stedet fanger hackeren og forhindrer denne forespørselen og sparer nettadressen. Hacker forårsaker på en eller annen måte at offeret åpner denne nettadressen. Hvis offeret kom inn i tjenesteleverandørens system ved hjelp av sin konto, vil legitimasjonene bli brukt til å utstede en autorisasjonskode. Autorisasjonskoden utveksler tilgang til tilgangstoken. Nå er Hacker-kontoen i søknaden autorisert. Det kan få tilgang til offerets konto.
Så, hvordan kan jeg forhindre denne situasjonen å bruke "State" -parameteren?
Programmet må opprette en verdi som på en eller annen måte er basert på kildekontoen (for eksempel bruker brukerens økt hash-tast). Det er ikke så viktig hva det er, det viktigste er at verdien er unik og generert ved hjelp av privat informasjon om den opprinnelige brukeren. Den er tildelt "State" -parameteren.
Denne verdien overføres til tjenesteleverandøren når de omdirigeres. Nå inviterer hackeren offeret til å åpne nettadressen, som han beholdt.
Autorisasjonskoden er utstedt og sendt tilbake til klienten i økten sammen med "State" -parameteren.
Klienten genererer en parameterverdi basert på en øktinformasjon og sammenligner den med "State" -verdien, som ble sendt tilbake fra autorisasjonsforespørselen til tjenesteleverandøren. Denne verdien samsvarer ikke med "State" -parameteren i spørringen, siden den bare er generert på grunnlag av informasjon om den nåværende økten. Som et resultat er den oppnådde verdien ikke akseptert av systemet.
Andre sårbarheter oppdaget når implementering av OAuth inkluderer muligheten til å utføre XSS (tverrstedsskripting) ved hjelp av "Redirect_uri" -parameteren, kan OAuth Private Key-innstillingen (nøkkelen noen ganger oppnås når du dekompilerer et mobilapplikasjon) og autorisasjonskode regel brudd (når Autorisasjonskoden kan brukes mer enn en gang for å utstede flere tilgangstokener). Disse sårbarhetene er mindre vanlige enn de som er beskrevet ovenfor, men det gjør dem ikke mindre farlige. Utvikleren bør vite all nødvendig praksis for å sikre pålitelig drift av sin webapplikasjon.
Forfatteren av den oversatte artikkelen: Simon Saliba.
Viktig! Informasjon utelukkende for akademiske formål. Vennligst følg lovgivningen og ikke bruk denne informasjonen for ulovlige formål.
Mer interessant materiale på cisoclub.ru. Abonner på oss: Facebook | VK |. Twitter | Instagram |. Telegram | Zen | Messenger | ICQ Ny | YouTube | Puls.