Le app desktop e mobile sono browser integrati nell'app per aiutare a completare l'intero processo OAuth 2.0
Il processo è mostrato nella figura
OAuth2.0 web
1) Restituire authCode al Web redirectUri specificato (questo URI è configurato dallo sviluppatore dell'app)
2) Per modificare il token, è necessario passare il clientId e il clientSecret per verificare l'identità del client (ottenuta dal servizio backend dell'applicazione)
Prendendo nota dei due punti sopra indicati,
1) Perché non è valido il rilevamento del redirezionamento dell'app web
2) Poiché non esiste un client di servizio backend, il segreto non è sicuro
Poi, l'attacco che potremmo incontrare è come mostrato nella figura sotto: potrebbe esserci un'applicazione dannosa che intercetta authCode per inviare un messaggio all'AuthorizationServer per ottenere il token, così che il token venga ottenuto senza l'autorizzazione del cliente all'applicazione ma a un'altra autorizzazione ufficiale dell'applicazione, raggiungendo così lo scopo dell'attacco.
Soluzione:
1. Il client genera una stringa casuale: verifica di codice e salva questa stringa casuale
code_challenge = trasformazione(code_verifier, [Plain| S256])
Se il metodo di trasformazione è semplice, allora la sfida del codice è equivalente al verificatore di codice
Se il metodo di trasformazione è S256, allora la sfida del codice è uguale all'hash Sha256 del verificatore di codice
2. Portare una contestazione di codice alla richiesta di codice di autorizzazione e come generare una challenge di codice. Questi due sono vincolati al codice di autorizzazione emesso dal server
3. Dopo aver ottenuto il codice di autorizzazione, il client porta il verificatore di codice inizialmente generato quando scambia il codice di autorizzazione con il Access Token. Il server calcola il verificatore di codice secondo il metodo della trasformazione limitata, confronta il risultato calcolato con la sfida del codice vincolato ed emette un Access Token se è coerente. |
Pubblicato su 28/11/2020 20:51:48
|
|
|
|
