Denna artikel kommer att hantera de välkända Oauth-sårbarheterna. Läsare kommer också att lära sig att genomföra säkert och säkert tillstånd i webbapplikationen.
OAuth är ett tillförlitligt protokoll, men dess grad av säkerhet beror i stor utsträckning på medvetenheten om webbutvecklare vid implementering. Detta gör det här ämnet extremt viktigt för informationssäkerhetspersonal. De måste ge en hög skydd av konton för sina användare. Det är dags att bekanta sig med effektiva utövare som kommer att bidra till att minska risken för dålig försäljning oauth.
IntroduktionOAuth 2.0-protokoll används för närvarande i olika tillämpningar. Med hjälp av det blir ett bekvämt användargränssnitt tillgängligt, lättare autentisering och auktorisation jämfört med traditionella metoder för att skriva in användarnamnet och lösenordet. Med korrekt och omtänksamt genomförande kommer OAUTH-protokollet att vara säkrare än traditionellt tillstånd, eftersom användarna inte behöver dela sina bokföringsdata med en tredjepartsapplikation för att få tillgång till en specifik resurs. Användare föredrar ofta att logga in med hjälp av sina Google-konton, Facebook eller LinkedIn, istället för att skapa ett nytt konto varje gång du måste registrera dig på någon webbplats. Således förenklar Oauth-protokollet i stort sett våra liv.
I allmänhet är populära Oauth-tjänsteleverantörer mycket tillförlitliga. Logga in med Google eller Facebook-konto inspirerar en viss känsla av säkerhet, och det är korrekt. Protokollet testas noggrant av experter. Alla tillgängliga sårbarheter korrigeras alltid snabbt av utvecklaren. Det är dock värt att notera att känslan av fullständig säkerhet kan vara falsk.
OAuth tjänsteleverantörer lämnade applikationsutvecklare många skäl att strida mot sina program. Faktum är att den initialt skyddade Oauth-tjänsten, felaktigt implementerad i processen med sin installation, kan bli ett enkelt mål för inkräktare. Sådan uppmärksamhet kommer att leda till stöld av personuppgifter för användare.
Därefter bör du överväga de vanligaste sårbarheterna som uppstår i tredjepartsapplikationer som genomför Oauth-protokoll för att tillåta sina användare. Man måste komma ihåg att protokollet i sig är säkert och pålitligt. Endast efter felaktig implementering blir det sårbart för hackerattacker.
OAUTH TOCKEY STEF Använd referensrubrikenNär ansökan begär tillstånd på användarens vägnar på OAUTH-servern, tar en person koden för att komma in och skicka tillbaka till servern för sin efterföljande kontroll. Om användaren kommer att omdirigeras till en annan sida, kommer koden att ses i "referer" -rubriken på HTTP-begäran. Koden kommer således att falla på den externa webbplatsen, vilket kommer att hota användardata som är registrerade på OAuth-servern.
Obs! Refererhuvudet är en HTTP-frågehuvud, det sänder den URL-värd från vilken begäran skickas.
För att mildra konsekvenserna av denna sårbarhet måste utvecklaren se till att dess webbapplikation inte innehåller några HTML-injektioner. Om injektionerna upptäcktes kan angriparen enkelt ställa in bildtaggen till sin webbserver och hitta ett sätt att omdirigera användaren på den. Således kommer han att få möjlighet att stjäla koden från "Referenter" rubriken på HTTP-förfrågan.
OAUTH TOCKEY STEF ANVÄNDA REDIRTECT_URI-parameternAnsökan initierar auktoriseringsprocessen genom att skicka en begäran till OAUTH-servern:
https://www.example.com/signin/authorize? []]&redirect_uri=httpps://demo.example.com/loginsuccessful.
Frågan innehåller alltid den "redirect_uri" -parametern som används av OAUTH-servern för att skicka tokens tillbaka till programmet efter att användaren gav sitt samtycke. Om värdet av denna parameter inte kontrolleras eller inte kontrolleras, kan angriparen enkelt ändra den och omdirigera begäran till sin webbplats, där den använder ett speciellt program för att bearbeta token och få tillgång till en begränsad resurs.
https://www.example.com/signin/authorize? [Perthtpps://localhost.evil.com.
Ibland är liknande webbadresser blockerade. Anfallaren kan omdirigera den mottagna data på den öppna webbadressen, så här:
https://www.example.com/oauth20_authorize.srf?[...[/Redirect_uri=httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
Eller det här:
https://www.example.com/oauth2/authorize? [...]% irekt_uri = https% 3a% 2f% 2fapps.facebook.com% 2Fattacker% 2f.
När du implementerar OAUTH kan du aldrig inkludera hela domäner i den vita listan. Endast några webbadresser bör läggas till "redirect_uri" inte omdirigeras en begäran om att öppna omdirigering.
Förfalskning av korsledningsförfrågningarFörfalskning av en intersätt begäran kan uppstå när en angripare lyckas göra offeret att klicka på sin länk och därmed att generera en förfrågan som han inte skulle generera. Förfalskning av korsledningsförfrågningar är vanligtvis mjukad med CSRF-token, som är förknippat med användarsessionen. Det hjälper till att programmet kan kontrollera personen hos en person som skickade begäran. Parametern "Stat" i OAuth-protokollet fungerar som CSRF-token.
Det är värt att visa hur CSRF-attacken utförs på OAuth och som "State" -parametern kan användas för att mildra effekterna av sårbarhet.
Hacker öppnar en webbapplikation och lanserar behörighetsprocessen för att komma åt tjänsteleverantören med OAUTH. Ansökan begär en tjänsteleverantör för att få tillgång till som behöver tillhandahållas. Hacker kommer att omdirigeras till tjänsteleverantörens webbplats, där du vanligtvis behöver ange ditt användarnamn och lösenord för att tillåta åtkomst. Istället fångar hackaren och förhindrar den här förfrågan och sparar sin webbadress. Hacker orsakar på något sätt offret att öppna den här webbadressen. Om offret kom in i tjänsteleverantörens system med sitt konto, kommer dess referenser att användas för att utfärda en behörighetskod. Bemyndigande kodutbyte tillgång till åtkomsttoken. Nu är Hacker-kontot i ansökan tillåtet. Det kan komma åt offrets konto.
Så, hur kan jag förhindra att den här situationen använder parametern "State"?
Ansökan måste skapa ett värde som på något sätt är baserat på källkontot (till exempel, använd användarsessionhash-tangenten). Det är inte så viktigt vad det är, det viktigaste är att värdet är unikt och genererat med privat information om den ursprungliga användaren. Den tilldelas parametern "State".
Detta värde överförs till tjänsteleverantören vid omdirigering. Nu uppmanar hackaren offret att öppna webbadressen, som han behållit.
Auktoriseringskoden utfärdas och skickas tillbaka till kunden i sessionen tillsammans med parametern "State".
Klienten genererar ett parametervärde baserat på en sessionsinformation och jämför den med "State" -värdet, som skickades tillbaka från behörighetsbegäran till tjänsteleverantören. Detta värde matchar inte parametern "State" i frågan, eftersom den endast genererats på grundval av information om den aktuella sessionen. Som ett resultat accepteras det erhållna värdet inte av systemet.
Andra sårbarheter som detekteras vid implementering av OAUTH inkluderar förmågan att utföra XSS (cross-site scripting) med hjälp av "redirect_uri" -parametern, kan OAUTH PRIVATE-tangentinställningen (tangenten ibland erhållas vid dekompilering av en mobilapplikation) och tillståndskod regelbrott (när Tillståndskoden kan användas mer än en gång för att utfärda flera åtkomstkoknader). Dessa sårbarheter är mindre vanliga än de som beskrivs ovan, men det gör dem inte mindre farliga. Utvecklaren bör känna till alla nödvändiga metoder för att säkerställa tillförlitlig drift av sin webbapplikation.
Författaren till den översatta artikeln: Simon Saliba.
Viktig! Information enbart för akademiska ändamål. Vänligen följa lagstiftningen och tillämpar inte denna information för olagliga ändamål.
Mer intressant material på cisoklub.ru. Prenumerera på oss: Facebook | Vk | Twitter | Instagram | Telegram | Zen | Messenger | ICQ New | YouTube | Puls.