Az asztali és mobilalkalmazások beágyazott böngészők az alkalmazásba, hogy segítsék az egész OAuth 2.0 folyamat befejezését
A folyamatot az ábrán ábrázoljuk
OAuth2.0 web
1) Visszaküldd az authCode-ot a megadott Web redirectUri-ba (ezt az URI-t az alkalmazásfejlesztő konfigurálja)
2) A token megváltoztatásához át kell adnod a clientId és clientSecret fájlokat, hogy ellenőrizd az ügyfél identitását (amit az alkalmazás backend szolgáltatás szerez meg)
A fent említett két pont figyelembevételével,
1) Mivel nem a webalkalmazás átirányítási Uri felismerése érvénytelen
2) Mivel nincs háttérszolgáltatás, kliensSecret nem biztonságos
Ekkor a támadás, amivel az alábbi ábrán látható, előfordulhat, hogy egy rosszindulatú alkalmazás fogja el az authCode-ot, hogy üzenetet küldjön az AuthorizationServernek a token megszerzésére, így a token az ügyfél engedélye nélkül megszerzik az alkalmazásnak, hanem egy másik hivatalos alkalmazásengedélyezés felé, elérve a támadás célját.
Megoldás:
1. Az ügyfél véletlenszerű stringet: kódellenőrzőt generál, és elmenti ezt a véletlenszerű stringet
code_challenge = transform(code_verifier, [Egyszerű| S256])
Ha a transzformációs módszer egyszerű, akkor a kód kihívás ekvivalens a kódellenőrrel
Ha a transzformációs módszer S256, akkor a kód kihívás egyenlő a kódellenőr Sha256 hash-jével
2. Hozz egy kód kihívást az engedélyezési kódkéréshez és annak generálásához. Ez a kettő a szerver által kiadott engedélyezési kódhoz van kötve
3. Az engedélyezési kód megszerzése után az ügyfél az eredetileg generált kódellenőrt hozza magával, amikor az Access Token hitelesítési kódját cseréli. A szerver a kódellenőrzőt a bound transform módszer szerint számolja ki, összehasonlítja a kiszámított eredményt a bound code kihívással, és ha az konzisztens, Access Tokent ad ki. |
Közzétéve 2020. 11. 28. 20:51:48
|
|
|
|
