Acest articol se va ocupa de vulnerabilitățile bine-cunoscute de outh. Cititorii vor învăța, de asemenea, cum să implementeze o autorizație sigură și sigură în aplicația web.
Oauth este un protocol fiabil, dar gradul de securitate depinde în mare măsură de conștientizarea dezvoltatorilor web la implementarea autorizației. Acest lucru face ca acest subiect să fie extrem de important pentru profesioniștii din domeniul securității informațiilor. Ei trebuie să ofere un nivel ridicat de protecție a conturilor utilizatorilor lor. Este timpul să vă familiarizați cu practicanți eficienți care vor ajuta la reducerea pericolului de vânzare a lui Oauth.
IntroducereProtocolul Oauth 2.0 este utilizat în prezent pe scară largă în diferite aplicații. Folosind aceasta, o interfață convenabilă de utilizator devine disponibilă, autentificare mai ușoară și o autorizație în comparație cu metodele tradiționale pentru introducerea numelui de utilizator și a parolei. Cu implementarea corectă și atentă, protocolul OAUTH va fi mai sigur decât autorizația tradițională, deoarece utilizatorii nu au nevoie să-și împărtășească datele contabile cu o cerere terță parte pentru a accesa o resursă specifică. Utilizatorii preferă adesea să se conecteze utilizând Conturile Google, Facebook sau LinkedIn, în loc să creeze un cont nou de fiecare dată când trebuie să vă înregistrați pe un site Web. Astfel, protocolul Oauth simplifică foarte mult viața noastră.
În general, furnizorii populari de servicii Oauth sunt foarte fiabile. Conectați-vă cu Google sau contul Facebook inspiră un anumit sens de securitate și este corect. Protocolul este testat cu atenție de către experți. Toate vulnerabilitățile disponibile sunt întotdeauna corectate rapid de echipa dezvoltatorului. Cu toate acestea, merită remarcat faptul că sentimentul de siguranță completă poate fi falsă.
Oauth Furnizorii de servicii au părăsit dezvoltatorii de aplicații o mulțime de motive pentru a susține siguranța programelor lor. De fapt, serviciul OAuth inițial protejat, implementat incorect în procesul de instalare, poate deveni o țintă ușoară pentru intruși. O astfel de preocupare va duce la furtul datelor personale ale utilizatorilor.
În continuare, ar trebui să luați în considerare cele mai frecvente vulnerabilități întâlnite în cererile terților care implementează Protocolul Oauth pentru a autoriza utilizatorii lor. Trebuie să ne amintim că protocolul în sine este sigur și fiabil. Numai după implementarea incorectă, ea devine vulnerabilă la atacurile hackerului.
Oauth Tockey Furt folosind antetul refereruluiCând aplicația solicită autorizarea în numele utilizatorului de la serverul Oauth, o persoană primește codul pentru a intra și trimite înapoi la server pentru verificarea ulterioară. Dacă în timpul lucrării, utilizatorul va fi redirecționat într-o altă pagină, codul va fi văzut în antetul "Rerificator" al cererii HTTP. Astfel, codul va cădea pe site-ul extern, care va amenința datele utilizatorului înregistrate pe serverul Oauth.
Notă: Antetul refererului este un antet de interogare HTTP, transmite gazda URL din care este trimisă cererea.
Pentru a înmuia consecințele acestei vulnerabilități, dezvoltatorul trebuie să se asigure că aplicația Web nu conține injecții HTML. Dacă au fost detectate injecțiile, atacatorul poate seta cu ușurință eticheta de imagine pe serverul său web și să găsească o modalitate de a redirecționa utilizatorul pe acesta. Astfel, el va avea ocazia să fure codul de la antetul "Rerificator" al cererii HTTP.
Oauth Tockey Furt folosind parametrul Redirect_uriAplicația inițiază procesul de autorizare prin trimiterea unei cereri către serverul OAUTH:
https://www.example.com/signin/authorize ?....]]&Redirect_uri=httpps://demo.example.com/loginsuccesul.
Interogarea conține întotdeauna parametrul "Redirect_uri" utilizat de serverul OAuth pentru a trimite jetoane înapoi la aplicație după ce utilizatorul și-a dat consimțământul. Dacă valoarea acestui parametru nu este controlată sau nu este bifată, atacatorul poate schimba cu ușurință și redirecționarea solicitării pe site-ul său web, unde utilizează un program special pentru procesarea tokenului și obținerea accesului la o resursă limitată.
https://www.example.com/signin/authorize) [...]] ]&redirect_uri=httpps://localhost.evil.com.
Uneori sunt blocate URL-uri similare. Atacatorul poate redirecționa datele primite pe adresa URL deschisă, astfel:
https://www.example.com/oauth20_authorize.srf? [//acounts.httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
Sau asta:
https://www.example.com/oauth2/authorize? [...]% irect_uri = https% 3a% 2F% 2fapps.facebook.com% 2fattacker% 2f.
La implementarea Oauth, nu puteți include niciodată domenii întregi în lista albă. Doar câteva adrese URL ar trebui adăugate la "Redirect_uri" care nu au redirecționat o cerere de a deschide redirecționarea.
Falsificarea cererilor transfrontaliereFurzirea unei cereri de intercalare poate să apară atunci când un atacator reușește să facă victima să facă clic pe link-ul său și, astfel, să genereze o cerere pe care nu o va genera. Falsificarea solicitărilor transfrontaliere este de obicei înmuiată cu tokenul CSRF, care este asociat cu sesiunea de utilizator. Ajută la cererea de a verifica persoana unei persoane care a trimis cererea. Parametrul "de stat" din protocolul Oauth servește drept token CSRF.
Merită vizionarea modului în care atacul CSRF se desfășoară pe Oauth și, pe măsură ce parametrul "de stat" poate fi utilizat pentru a atenua efectele vulnerabilității.
Hacker deschide o aplicație web și lansează procesul de autorizare pentru a accesa furnizorul de servicii utilizând OAUTH. Aplicația solicită un furnizor de servicii să acceseze care trebuie furnizate. Hacker va fi redirecționat către site-ul furnizorului de servicii, unde trebuie de obicei să introduceți numele de utilizator și parola pentru a autoriza accesul. În schimb, hackerul captează și previne această solicitare și salvează adresa URL. Hacker cumva cauzează victima să deschidă această adresă URL. Dacă victima a intrat în sistemul furnizorului de servicii utilizând contul său, atunci acreditările sale vor fi utilizate pentru a emite un cod de autorizare. Codul de autorizare schimbă accesul la jetonul de acces. Acum este autorizat contul Hacker din aplicație. Poate accesa contul victimei.
Deci, cum pot împiedica această situație folosind parametrul "State"?
Aplicația trebuie să creeze o valoare care este cumva pe baza contului sursă (de exemplu, utilizați cheia de sesiune de utilizator). Nu este atât de important ceea ce este, principalul lucru este că valoarea este unică și generată folosind informații private despre utilizatorul original. Acesta este atribuit parametrului "de stat".
Această valoare este transmisă furnizorului de servicii atunci când redirecționează. Acum, hackerul invită victima să deschidă adresa URL, pe care o păsa.
Codul de autorizare este emis și trimis înapoi clientului în sesiune împreună cu parametrul "State".
Clientul generează o valoare a parametrilor bazată pe o informație despre sesiune și o compară cu valoarea "de stat", care a fost trimisă înapoi de la cererea de autorizare către furnizorul de servicii. Această valoare nu se potrivește cu parametrul "stare" din interogare, deoarece a fost generat numai pe baza informațiilor despre sesiunea curentă. Ca rezultat, valoarea obținută nu este acceptată de sistem.
Alte vulnerabilități detectate la implementarea Oauth includ capacitatea de a efectua XSS (script-ul transfrontalier) utilizând parametrul "Redirect_uri", setarea cheii private Oauth (cheia poate fi uneori obținută la decompilarea unei aplicații mobile) și încălcarea regulii codului de autorizare (când Codul de autorizare poate fi utilizat de mai multe ori pentru a emite jetoane de acces multiple). Aceste vulnerabilități sunt mai puțin frecvente decât cele descrise mai sus, dar nu le face mai puțin periculoase. Dezvoltatorul ar trebui să cunoască toate practicile necesare pentru a asigura funcționarea fiabilă a aplicației sale web.
Autorul articolului tradus: Simon Saliba.
Important! Informații exclusiv în scopuri academice. Respectați legislația și nu aplicați aceste informații în scopuri ilegale.
Material mai interesant pe cisoclub.ru. Aboneaza-te la noi: Facebook | VK | Twitter | Instagram | Telegrama | Zen |. Messenger | ICQ Nou | YouTube | Puls.