Namizni in mobilni aplikaciji sta vgrajeni brskalniki v aplikaciji, ki pomagajo pri dokončanju celotnega procesa OAuth 2.0
Postopek je prikazan na sliki
OAuth2.0 splet
1) Vrni avtenthCode na določen Web redirectUri (ta URI konfigurira razvijalec aplikacije)
2) Za spremembo žetona morate posredovati clientId in clientSecret, da potrdite identiteto klienta (pridobljeno s strani aplikacijske backend storitve)
Ob upoštevanju zgornjih dveh točk,
1) Ker spletna aplikacija ne zaznava preusmeritev URL-jev ni veljavna
2) Ker ni zadnje storitve, odjemalec ni varen
Napad, s katerim se lahko srečamo, je, kot je prikazano na spodnji sliki: lahko gre za zlonamerno aplikacijo, ki prestreže AuthCode in pošlje sporočilo AuthorizationServerju za pridobitev žetona, tako da žeton pridobi brez avtorizacije uporabnika aplikaciji, vendar z drugo uradno avtorizacijo aplikacije, s čimer doseže namen napada.
Rešitev:
1. Odjemalec ustvari naključni niz: code verifier in shrani ta naključni niz
code_challenge = transform(code_verifier, [Navadno| S256])
Če je metoda transformacije preprosta, je izziv kode enakovreden preverjanju kode
Če je metoda transformacije S256, je izziv kode enak hashu Sha256 preverjevalca kode
2. Prinesite izziv kode na zahtevo za avtorizacijsko kodo in kako ustvariti izziv kode. Ti dve sta vezani na avtorizacijsko kodo, ki jo izda strežnik
3. Po pridobitvi avtorizacijske kode odjemalec prinese začetno generirano preverjevalno kodo kode ob izmenjavi avtorizacijske kode za Access Token. Strežnik izračuna preverjevalca kode po metodi vezane transformacije, primerja izračunani rezultat z izzivom vezane kode in izda dostopni žeton, če je ta skladen. |
Objavljeno na 28. 11. 2020 20:51:48
|
|
|
|
