Aplikacje desktopowe i mobilne to wbudowane przeglądarki w aplikacji, które pomagają w ukończeniu całego procesu OAuth 2.0
Proces przedstawiony jest na rysunku
OAuth2.0 web
1) Zwracaj autoryzacyjny kod do określonego Web redirectUri (ten URI jest konfigurowany przez dewelopera aplikacji)
2) Aby zmienić token, trzeba przekazać clientId i clientSecret, aby zweryfikować tożsamość klienta (uzyskaną przez usługę backendową aplikacji)
Zwracając uwagę na powyższe dwa punkty,
1) Ponieważ nie wykrywanie URI jest nieprawidłowe w aplikacji webowej
2) Ponieważ nie ma usługi backendowejKlientSecret nie jest bezpieczny
Wtedy atak, z którym możemy się spotkać, wygląda, jak pokazano na poniższym rysunku: złośliwa aplikacja przechwyca authCode i wysyła wiadomość do AuthorizationServer, aby uzyskać token, dzięki czemu token zostanie uzyskany bez autoryzacji klienta dla aplikacji, lecz do innej oficjalnej autoryzacji aplikacji, co osiąga cel ataku.
Rozwiązanie:
1. Klient generuje losowy ciąg tekstu: weryfikator kodu i zapisuje ten losowy ciąg
code_challenge = transform(code_verifier, [Plain| S256])
Jeśli metoda transformacji jest zwykła, to code challenge jest równoważny z code verifierem
Jeśli metoda transformacji to S256, to wyzwanie kodowe jest równe hashowi Sha256 weryfikatora kodu
2. Złożyć wyzwanie kodowe do żądania kodu autoryzacyjnego oraz jak wygenerować wyzwanie kodowe. Te dwa są powiązane z kodem autoryzacyjnym wydanym przez serwer
3. Po uzyskaniu kodu autoryzacyjnego klient przynosi początkowo wygenerowany weryfikator kodu podczas wymiany kodu autoryzacyjnego na Access Token. Serwer oblicza weryfikator kodu według metody transformacji bound, porównuje obliczony wynik z wyzwaniem bound code challenge i wydaje Access Token, jeśli jest on spójny. |
Opublikowano 28.11.2020 20:51:48
|
|
|
|
