Aplicațiile desktop și mobile sunt browsere integrate în aplicație pentru a ajuta la finalizarea întregului proces OAuth 2.0
Procesul este prezentat în figură
OAuth2.0 web
1) Returnarea codului de autentificare la redirecționarea web specificată (acest URI este configurat de dezvoltatorul aplicației)
2) Pentru a schimba tokenul, trebuie să treci clientId-ul și clientSecret pentru a verifica identitatea clientului (obținută de serviciul backend al aplicației)
Menționând cele două puncte de mai sus,
1) Pentru că nu aplicația web detectarea redirecționării Uri este invalidă
2) Pentru că nu există un client de serviciu backend, secretul nu este sigur
Atunci, atacul pe care îl putem întâlni este, așa cum se arată în figura de mai jos, că poate exista o aplicație malițioasă care interceptează authCode pentru a trimite un mesaj către AuthorizationServer pentru a obține tokenul, astfel încât tokenul să fie obținut fără autorizarea clientului către aplicație, ci către o altă autorizare oficială a aplicației, atingând astfel scopul atacului.
Soluție:
1. Clientul generează un verificator de cod aleatoriu șir și salvează acest șir aleatoriu
code_challenge = transform(code_verifier, [Plain| S256])
Dacă metoda transformării este simplă, atunci provocarea codului este echivalentă cu verificarea codului
Dacă metoda de transformare este S256, atunci provocarea codului este egală cu hash-ul Sha256 al verificatorului de cod
2. Aduceți o provocare de cod la cererea de cod de autorizare și cum să generați o provocare de cod. Aceste două sunt legate de codul de autorizare emis de server
3. După obținerea codului de autorizare, clientul aduce verificatorul de cod generat inițial atunci când schimbă codul de autorizare pentru Access Token. Serverul calculează verificatorul de cod conform metodei de transformare limitată, compară rezultatul calculat cu provocarea codului legat și emite un Token de Acces dacă acesta este consistent. |
Postat pe 28.11.2020 20:51:48
|
|
|
|
