Denne artikel vil beskæftige sig med de velkendte OAuth sårbarheder. Læsere vil også lære at implementere sikker og sikker godkendelse i webapplikationen.
OAuth er en pålidelig protokol, men dens grad af sikkerhed afhænger stort set af bevidstheden om webudviklere, når de gennemfører tilladelse. Dette gør dette emne ekstremt vigtigt for informationssikkerhedspersonale. De skal give et højt beskyttelsesniveau for deres brugere. Det er på tide at kende bekendt med effektive praktiserende læger, der vil bidrage til at reducere faren for dårlig salg af oauth.
IntroduktionOAuth 2.0-protokollen anvendes i øjeblikket i vid udstrækning i forskellige applikationer. Ved hjælp af det bliver en praktisk brugergrænseflade tilgængelig, lettere godkendelse og autorisation i forhold til traditionelle metoder til indtastning af brugernavnet og adgangskoden. Med korrekt og tankevækkende implementering vil oauth-protokollen være sikrere end traditionel tilladelse, da brugerne ikke behøver at dele deres regnskabsdata med en tredjepartsansøgning for at få adgang til en bestemt ressource. Brugere foretrækker ofte at logge ind ved hjælp af deres Google-konti, Facebook eller LinkedIn, i stedet for at oprette en ny konto hver gang du skal registrere dig på nogle websted. OAuth-protokollen forenkler således vores liv i høj grad.
Generelt er populære OAuth-tjenesteudbydere meget pålidelige. Log ind med Google eller Facebook-konto inspirerer en vis følelse af sikkerhed, og det er korrekt. Protokollen testes omhyggeligt af eksperter. Alle tilgængelige sårbarheder korrigeres altid hurtigt af udviklerholdet. Det er dog værd at bemærke, at følelsen af fuldstændig sikkerhed kan være falsk.
OAuth tjenesteudbydere efterladt applikationsudviklere mange grunde til at bekæmpe sikkerheden af deres programmer. Faktisk kan den oprindeligt beskyttede oauth-tjeneste, der fejlagtigt gennemføres i processen med dens installation, blive et nemt mål for indtrengere. En sådan bekymring vil føre til tyveri af personoplysninger hos brugerne.
Dernæst bør du overveje de mest almindelige sårbarheder, der opstår i tredjeparts applikationer, der implementerer OAuth-protokollen til at godkende deres brugere. Det skal huskes, at selve protokollen er sikker og pålidelig. Først efter forkert implementering bliver det sårbart over for hackerangreb.
OAuth TOCKEY THEFT Brug af referreroverskriftenNår applikationen anmoder om tilladelse på vegne af brugeren på OAuth-serveren, modtager en person koden til at indtaste og sende tilbage til serveren for den efterfølgende check. Hvis brugeren under arbejdet bliver omdirigeret til en anden side, ses koden i "Referencer" header af HTTP-anmodningen. Koden falder således på den eksterne hjemmeside, som truer brugerdataene registreret på OAuth-serveren.
Bemærk: Referencehovedet er en HTTP-forespørgselshoved, den sender den URL-vært, hvorfra anmodningen sendes.
For at blødgøre konsekvenserne af denne sårbarhed skal udvikleren sørge for, at dets webapplikation ikke indeholder nogen HTML-injektioner. Hvis injektionerne blev detekteret, kan angriberen nemt indstille billedet mærket til sin webserver og finde en måde at omdirigere brugeren på den. Således får han mulighed for at stjæle koden fra "Referencer" header af HTTP-anmodningen.
OAuth TOCKEY THEFT ved hjælp af Redirect_URI parameterenAnsøgningen initierer godkendelsesprocessen ved at sende en anmodning til OAuth-serveren:
https://www.example.com/signin/Authorize ?[...]&redirect_uri=httpps://demo.example.com/loginsuccessful.
Forespørgslen indeholder altid "Redirect_uri" -parameteren, der bruges af OAuth-serveren til at sende tokens tilbage til applikationen, efter at brugeren gav sit samtykke. Hvis værdien af denne parameter ikke styres eller ikke er markeret, kan angriberen nemt ændre den og omdirigere anmodningen til sin hjemmeside, hvor den bruger et særligt program til behandling af token og få adgang til en begrænset ressource.
https://www.example.com/signin/Authorize ?[...]&redirect_uri=httpps://localhost.evil.com.
Nogle gange er lignende webadresser blokeret. Angriberen kan omdirigere de modtagne data på den åbne webadresse, som denne:
https://www.example.com/oauth20_authorize.Srf?[...[edirect_uri=httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
Eller dette:
https://www.example.com/oauth2/Authorize? [...]% irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2fattacker% 2f.
Når du implementerer OAuth, kan du aldrig inkludere hele domæner i den hvide liste. Kun få webadresser skal tilføjes til "Redirect_uri" ikke omdirigeret en anmodning om at åbne omdirigering.
Forfalskning af tværgående anmodningerForfalskning af en skæringsanmodning kan opstå, når en angriber lykkes at gøre offeret til at klikke på hans link og dermed skabe en anmodning om, at han ikke ville generere. Forfalskning af tværgående anmodninger er normalt blødgjort med CSRF-token, som er forbundet med brugersessionen. Det hjælper applikationen til at kontrollere personen af en person, der sendte anmodningen. Parameteren "State" i OAuth-protokollen tjener som CSRF-token.
Det er værd at se, hvordan CSRF-angrebet udføres på OAuth, og som "State" -parameteren kan bruges til at afbøde virkningerne af sårbarhed.
Hacker åbner en webapplikation og lancerer godkendelsesprocessen for at få adgang til tjenesteudbyderen ved hjælp af OAuth. Ansøgningen anmoder om en tjenesteudbyder at få adgang til, der skal leveres. Hacker vil blive omdirigeret til tjenesteudbyderens hjemmeside, hvor du normalt skal indtaste dit brugernavn og adgangskode for at godkende adgang. I stedet fanger hackeren og forhindrer denne anmodning og sparer sin webadresse. Hacker forårsager på en eller anden måde, at offeret åbner denne webadresse. Hvis offeret indtastet tjenesteudbyderens system ved hjælp af sin konto, vil dets legitimationsoplysninger blive brugt til at udstede en autorisationskode. Autorisationskoden udveksler adgang til adgangstoken. Nu er Hacker-kontoen i ansøgningen godkendt. Det kan få adgang til offerets konto.
Så hvordan kan jeg forhindre denne situation ved hjælp af parameteren "State"?
Ansøgningen skal oprette en værdi, der på en eller anden måde er baseret på kildekontoen (for eksempel bruger brugersession hash-tasten). Det er ikke så vigtigt, hvad det er, det vigtigste er, at værdien er unik og genereret ved hjælp af privat information om den oprindelige bruger. Den er tildelt "State" parameteren.
Denne værdi overføres til tjenesteudbyderen, når den omdirigeres. Nu inviterer hacker offeret til at åbne webadressen, som han bevarede.
Autorisationskoden udstedes og sendt tilbage til klienten i sessionen sammen med parameteren "State".
Klienten genererer en parameterværdi baseret på en sessionsinformation og sammenligner den med "statens" værdi, som blev sendt tilbage fra godkendelsesforespørgslen til tjenesteudbyderen. Denne værdi svarer ikke til parameteren "State" i forespørgslen, da den kun er genereret på grundlag af oplysninger om den aktuelle session. Som følge heraf accepteres den opnåede værdi ikke af systemet.
Andre sårbarheder opdaget ved implementering af OAuth inkluderer evnen til at udføre XSS (Cross-Site Scripting) ved hjælp af parameteren "Redirect_uri", OAuth Private Key-indstillingen (nøglen kan undertiden fås, når der dekompilerer en mobilapplikation) og autorisationskode regel overtrædelse (hvornår Autorisationskoden kan bruges mere end én gang til at udstede flere adgangstokens). Disse sårbarheder er mindre almindelige end de ovenfor beskrevne, men det gør dem ikke mindre farlige. Udvikleren bør kende alle de nødvendige praksis for at sikre pålidelig drift af sin webapplikation.
Forfatteren af den oversatte artikel: Simon Saliba.
Vigtig! Oplysninger udelukkende til akademiske formål. Venligst overholde lovgivningen og ikke anvende disse oplysninger til ulovlige formål.
Mere interessant materiale på cisoclub.ru. Abonner på os: Facebook | Vk | Twitter | Instagram | Telegram | Zen | Messenger | ICQ NYE | YouTube | Puls.