Supponiamo tu abbia un'app che utilizza OAuth in modo che l'app possa accedere ai servizi dell'utente (ad es. OneDrive, Google Drive, ecc.)
All'interno dell'app hai incluso il client segreto OAuth (e l'ID client) come costanti di stringa.
Un utente malintenzionato estrae questi dalla tua app utilizzando tecniche di reverse engineering. Qual è la cosa peggiore che l'hacker possa fare ora, conoscendo il segreto client OAuth della tua app?
Distribuire un segreto client condiviso è come distribuire le chiavi complete per il regno e una violazione di CWE-602: Applicazione sul lato client della sicurezza lato server . Questo perché chiunque abbia l'app ha quindi accesso completo alle risorse condivise sul lato server.
L'impatto di un token di accesso OAuth rubato dipende interamente dallo ambito , che è definito nella base64 token di accesso codificato.
Nel tipo di concessione del codice di autorizzazione, in cui i segreti dei clienti sono tenuti a rimanere segreti, l'utente può dire al servizio che la propria applicazione è autorizzata ad accedere a determinati elementi del proprio account. La cosa importante qui è che hanno autorizzato la tua applicazione, non altre applicazioni. Il segreto del cliente è come autenticate la vostra applicazione al servizio.
L'acquisizione di un segreto del client può consentire a un'applicazione dannosa di impersonare la tua applicazione e qualsiasi autorizzazione è stata concessa. Ciò potrebbe includere la riproduzione di accessi e i token di aggiornamento per accedere all'account di un utente senza autorizzazione.
Credo che l'attaccante di solito abbia bisogno di acquisire ulteriori informazioni (ad esempio, token di accesso) affinché il segreto del cliente sia utile nella pratica (mi piacerebbe sapere di eventuali scenari in cui ciò non sarebbe il caso). Gli attacchi in cui un utente esistente è attirato su una pagina malevola (con accesso al segreto del client) possono funzionare in alcuni contesti - sebbene possano esservi complicazioni intorno al referrer e alla pagina in cui l'utente viene restituito.
La gravità ("la cosa peggiore che potrebbe fare") varia a seconda dell'ambito, ma è probabile che abbia un impatto negativo sugli utenti dell'applicazione. Nei tuoi esempi di Google Drive e OneDrive, potrebbe consentire a un utente malintenzionato di leggere o modificare i file di un utente, ad esempio, se è l'autorizzazione che ha dato.
Refs:
Il tipo di sovvenzione implicita è il migliore per ambienti in cui un token non può essere tenuto segreto (desktop nativo, mobile nativo, browser lato client, ecc.)
Leggi altre domande sui tag oauth secret-sharing