Hierdie artikel sal die bekende OAuth kwesbaarhede hanteer. Lesers sal ook leer hoe om veilige en veilige magtiging in die webprogram te implementeer.
Oauth is 'n betroubare protokol, maar sy mate van sekuriteit hang grootliks af van die bewustheid van webontwikkelaars by die implementering van magtiging. Dit maak hierdie onderwerp uiters belangrik vir inligting sekuriteitswerkers. Hulle moet 'n hoë vlak van beskerming van rekeninge van hul gebruikers verskaf. Dit is tyd om kennis te maak met effektiewe praktisyns wat sal help om die gevaar van swak verkoop Oauth te verminder.
BekendstellingOAuth 2.0 protokol word tans in verskeie toepassings wyd gebruik. Deur dit te gebruik, word 'n gerieflike gebruikerskoppelvlak beskikbaar, makliker verifikasie en magtiging in vergelyking met tradisionele metodes om die gebruikersnaam en wagwoord in te voer. Met behoorlike en deurdagte implementering sal die OAuth-protokol veiliger wees as tradisionele magtiging, aangesien gebruikers nie hul rekeningkundige data met 'n derdeparty-aansoek moet deel om toegang tot 'n spesifieke hulpbron te verkry nie. Gebruikers verkies dikwels om in te teken om hul Google-rekeninge, Facebook of LinkedIn te gebruik, in plaas van om 'n nuwe rekening te skep elke keer as jy op 'n webwerf moet registreer. So, die Oauth protokol vereenvoudig ons lewens grootliks.
Oor die algemeen is gewilde Oauth-diensverskaffers baie betroubaar. Teken in met Google of Facebook-rekening inspireer 'n sekere gevoel van sekuriteit, en dit is korrek. Die protokol word noukeurig deur kundiges getoets. Alle beskikbare kwesbaarhede word altyd vinnig deur die ontwikkelaarspan reggestel. Dit is egter opmerklik dat die gevoel van volledige veiligheid vals kan wees.
Oauth Service Providers het die aansoek ontwikkelaars baie redes gelaat om die veiligheid van hul programme te beweer. Trouens, die aanvanklik beskerm Oauth-diens, wat verkeerd geïmplementeer is in die proses van sy installasie, kan 'n maklike teiken vir indringers word. Sodanige voorneme sal lei tot die diefstal van persoonlike data van gebruikers.
Vervolgens moet u die mees algemene kwesbaarhede wat in derdeparty-programme voorkom, oorweeg wat Oauth protokol implementeer om hul gebruikers te magtig. Dit moet onthou word dat die protokol self veilig en betroubaar is. Slegs na die verkeerde implementering word dit kwesbaar vir hacker aanvalle.
Oauth tokey diefstal deur die verwysersopskrif te gebruikWanneer die aansoek magtiging namens die gebruiker by die Oauth-bediener versoek, ontvang 'n persoon die kode om terug te gaan en terug te stuur na die bediener vir die daaropvolgende tjek. Indien die gebruiker tydens die werk na 'n ander bladsy na 'n ander bladsy verwys word, sal die kode in die "verwyser" -opskrif van die HTTP-versoek gesien word. Die kode sal dus op die eksterne webwerf val, wat die gebruikersdata wat op die Oauth-bediener geregistreer is, sal bedreig.
Let wel: Die verwysersopskrif is 'n HTTP-navraagopskrif, dit stuur die URL-gasheer waaruit die versoek gestuur word.
Om die gevolge van hierdie kwesbaarheid te versag, moet die ontwikkelaar seker maak dat sy webprogram nie enige HTML-inspuitings bevat nie. As die inspuitings opgespoor is, kan die aanvaller die prentetiket maklik op sy webbediener stel en 'n manier vind om die gebruiker daaraan te herlei. Hy sal dus die geleentheid kry om die kode te steel van die "verwyser" -opskrif van die HTTP-versoek.
Oauth tokey diefstal met behulp van die redirect_uri parameterDie aansoek begin die magtigingsproses deur 'n versoek aan die Oauth-bediener te stuur:
https://www.example.com/signin/authorize ?[ ..]&redirect_uri=httpps://demo.example.com/loginsuccessful.
Die navraag bevat altyd die "Redirect_uri" -parameter wat deur die Oauth-bediener gebruik word om tokens terug te stuur na die aansoek nadat die gebruiker sy toestemming gegee het. As die waarde van hierdie parameter nie beheer word of nie nagegaan word nie, kan die aanvaller dit maklik verander en die versoek na sy webwerf herlei, waar dit 'n spesiale program gebruik om die teken te verwerk en toegang tot 'n beperkte hulpbron te verkry.
https://www.example.com/signin/authorize ?[ ...]&redirect_uri=httpps://localhost.vil.com.
Soms word soortgelyke URL's geblokkeer. Die aanvaller kan die ontvangde data op die oop URL herlei, soos volg:
https://www.example.com/oauth20_authorize.srf ?[v.
Of dit:
https://www.example.com/oauth2/Authorize? [...]% irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2fattakker% 2F.
By die implementering van Oauth kan jy nooit hele domeine in die wit lys insluit nie. Slegs 'n paar URL's moet bygevoeg word aan "Redirect_uri" nie 'n versoek om die aanstuur te herlei nie.
Vervalsing van kruislynversoekeVervalsing van 'n intersight-versoek kan voorkom wanneer 'n aanvaller daarin slaag om die slagoffer te maak om op sy skakel te klik en sodoende 'n versoek te genereer wat hy nie sal genereer nie. Vervalsing van kruislynversoeke word gewoonlik met die CSRF-token versag, wat met die gebruikersessie geassosieer word. Dit help die aansoek om die persoon van 'n persoon wat die versoek gestuur het, na te gaan. Die "staat" parameter in die OAuth protokol dien as CSRF token.
Dit is die moeite werd om te sien hoe die CSRF-aanval op Oauth uitgevoer word en as die "staat" -parameter gebruik kan word om die gevolge van kwesbaarheid te versag.
Hacker maak 'n webprogram oop en stel die magtigingsproses bekend om toegang tot die diensverskaffer te gebruik wat Oauth gebruik. Die aansoek versoek 'n diensverskaffer om toegang te verkry wat verskaf moet word. Hacker sal na die diensverskaffer se webwerf herlei word, waar u gewoonlik u gebruikersnaam en wagwoord moet invoer om toegang te magtig. In plaas daarvan, die hacker vang en verhoed hierdie versoek en red sy URL. Hacker veroorsaak dat die slagoffer hierdie URL oopmaak. As die slagoffer die diensverskaffer se stelsel ingevoer het deur sy rekening te gebruik, sal sy geloofsbriewe gebruik word om 'n magtigingskode uit te reik. Die magtigingskode ruil toegang tot die toegangsteken. Nou is die Hacker-rekening in die aansoek gemagtig. Dit kan toegang tot die slagoffer se rekening.
So, hoe kan ek hierdie situasie verhoed om die "staat" -parameter te gebruik?
Die aansoek moet 'n waarde skep wat op een of ander manier gebaseer is op die bronrekening (byvoorbeeld, gebruik die gebruiker sessie hash sleutel). Dit is nie so belangrik wat dit is nie, die belangrikste ding is dat die waarde uniek en gegenereer is met behulp van private inligting oor die oorspronklike gebruiker. Dit is toegeken aan die "staat" parameter.
Hierdie waarde word aan die diensverskaffer oorgedra wanneer dit aanleiding gee. Nou nooi die hacker die slagoffer om die URL oop te maak, wat hy behou het.
Die magtigingskode word uitgereik en terug gestuur na die kliënt in die sessie saam met die "staat" parameter.
Die kliënt genereer 'n parameterwaarde gebaseer op 'n sessie-inligting en vergelyk dit met die "staat" waarde, wat terug gestuur is van die magtigingsversoek aan die diensverskaffer. Hierdie waarde stem nie ooreen met die "staat" parameter in die navraag nie, aangesien dit slegs op grond van inligting oor die huidige sessie gegenereer is. Gevolglik word die verkryde waarde nie deur die stelsel aanvaar nie.
Ander kwesbaarhede wat opgespoor word by die implementering van Oauth sluit in die vermoë om XSS (Cross-site Scripting) te gebruik Die magtigingskode kan meer as een keer gebruik word om verskeie toegangstekeninge uit te reik). Hierdie kwesbaarhede is minder algemeen as dié wat hierbo beskryf word, maar dit maak hulle nie minder gevaarlik nie. Die ontwikkelaar moet al die nodige praktyke ken om betroubare werking van sy webprogram te verseker.
Die skrywer van die vertaalde artikel: Simon Saliba.
Belangrik! Inligting uitsluitlik vir akademiese doeleindes. Voldoen asseblief aan wetgewing en moenie hierdie inligting vir onwettige doeleindes toepas nie.
Meer interessante materiaal op cisoclub.ru. Teken in op ons: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ NUUS | YouTube | Pols.