Flusso implicito OAuth e problema del delegato confuso

Credo che il seguente esempio mostri il problema (basato sulla risposta accettata da link )

Tutto ciò presuppone l'utilizzo del flusso implicito di OAuth

1. Alice collega il suo browser a GoodApp.com

2. GoodApp.com ottiene un token di accesso OAuth autorizzato da Alice.

   A) Questo token di accesso è legato all'identità di Alice sul server di autorizzazione.

   B) Il token di accesso viene utilizzato da GoodApp.com per autenticare Alice o accedere a
      alcune risorse OAuth per conto di Alice.

3. Alice collega il suo browser a BadApp.com (per qualsiasi motivo, diciamo BadApp.com "offre giochi che sembrano divertenti")
4. BadApp.com ottiene un token di accesso OAuth autorizzato da Alice.
5. BadGuy (che controlla BadApp.com) collega quindi il suo browser a BadApp.com e ottiene BadApp.com reindirizza il browser di BadGuy a GoodApp.com con un OAuth contraffatto risposta all'autorizzazione che include il token di accesso di BadApp.com per Alice.

6. Se GoodApp.com accetta la risposta falsificata, BadGuy può agire come Alice come segue.

   A) Se il token di accesso viene usato da GoodApp.com per autenticare Alice, allora può farlo BadGuy    qualsiasi cosa che Alice potrebbe fare su GoodApp.com

   B) Se il token di accesso viene utilizzato da GoodApp.com per accedere ad una risorsa OAuth, quindi BadGuy    può causare a GoodApp.com di fare qualsiasi cosa all'interno dello "scope" del token di accesso, il tutto su    per conto di Alice.

Pertanto, se GoodApp.com verifica che qualsiasi token di accesso ricevuto è effettivamente destinato a se stesso, allora può evitare le cose brutte come descritto nell'esempio sopra.

Si noti che ritengo che l'uso corretto del parametro "stato" da parte del client OAuth per la falsificazione di richieste cross-site possa anche mitigare questo problema, indipendentemente dalla convalida del token di accesso.

Penso che il modo migliore per capire come questo modello di OAuth possa essere insicuro è parlare dello scopo degli ambiti OAuth.

Secondo il suo design, un ambito OAuth rappresenta un insieme di possibili azioni che possono essere eseguite per conto dell'utente autenticato. Quindi (come esempio inventato) se il tuo cliente ottiene un ambito token con l'ambito "send_messages" , allora può inviare messaggi per conto dell'utente. In un certo senso, la definizione vera di un ambito è ciò che le azioni che un token con quell'ambito consente di eseguire.

Il problema con il modo "Accedi con FB / Twitter / ecc." è implementato è che tutti usano un singolo ambito (ad esempio "public_profile" per Facebook).

Secondo la documentazione, questo ambito è abbastanza innocuo: con questo il client può visualizzare l'identità dell'utente corrente. Tuttavia, se un sito Web di terze parti A.com utilizza questo token per verificare l'identità di un utente e registrarlo su A.com, ha sostanzialmente ampliato la definizione di public_profile scope per indicare "visualizza le informazioni del profilo pubblico e anche accedi alle risorse di questo utente su A.com ".

Tutto ciò che serve a questo punto è che un utente malintenzionato ottenga un token con un public_profile scope (ad esempio, eseguendo un altro sito Web con un collegamento "Accedi con Facebook") - questo ambito richiesto sembra innocuo secondo la documentazione di Facebook e ciò che mostrano all'utente, ma in realtà se l'hacker può passarlo a A.com, può accedere alle risorse dell'utente.

La soluzione

La soluzione emersa è che A.com verifichi che il token sia stato generato specificamente per A.com, ovvero che durante il flusso di accesso OAuth l'utente sia stato reindirizzato a A.com anziché a un altro sito.

Per fare ciò, il token OAuth generato ha ulteriori informazioni ad esso associate, in particolare "a quale sito / applicazione è stato inviato questo token". La presenza di questa informazione extra determina il risultato quando si ispeziona il token (ad esempio / debug_token endpoint).

(Personalmente ritengo che questo più o meno costituisca un "ambito invisibile", e non avremmo questa confusione se Facebook / etc avesse fornito ambiti di accesso personalizzati di terze parti, ad esempio "third-party:a.com" - tuttavia, la soluzione esistente è altrettanto funzionale.)

(Il flusso "implicito" di OAuth a volte viene completamente incolpato in questa situazione, che a mio parere manca metà punto.Il problema è che il flusso "implicito" consente a un utente malintenzionato di inserire i propri token OAuth di intercettando il reindirizzamento del browser, ma questo non sarebbe un problema se gli ambiti di OAuth non venissero ridefiniti.)

La falsificazione di richieste tra siti diversi, che è il problema che hai descritto nella tua domanda, è leggermente diversa da un più generale problema di vice confuso che è descritto nell'altra risposta. CSRF coinvolge il token dell'attaccante, non quello di Alice (usando lo stesso esempio di prima). E sì, CSRF può essere mitigato sfruttando il parametro state.

Ma un diverso esempio di confuso problema di vice, come descritto nell'altra risposta, non è così semplice. Invece, il server di autorizzazione dovrebbe convalidare ogni chiamata API contro id_cliente e token di accesso (con scope)