Insidie nell'utilizzo di OAuth per le applicazioni mobili

La prima considerazione è che SSL / TLS è assolutamente necessario per implementare correttamente.

Bisogna considerare anche i meccanismi authn a 2 o 3 gambe. Mentre molti consiglieranno l'approccio a 3 zampe più complesso (e sicuro), è possibile che a 2 zampe avrebbe vantaggi se fatto bene per alcune app.

Ci sono stati alcuni scoperte di attacchi temporizzati su OAuth fatto da rootlabs . Ci sono anche rischi da XSS / CSRF e ClickJacking (e altri attacchi contro l'authn), proprio come in qualsiasi applicazione web.

ArsTechnica ha pubblicato due articoli su architettura di sicurezza OAuth , una collegata da Bruce Schneier .

Non ho abbastanza punti per fare un commento, quindi ho aggiunto questo come risposta. OAuth è innanzitutto un protocollo di autorizzazione e non principalmente un'autenticazione. Anche se l'autenticazione è incorporata nel protocollo, non è lo scopo principale.

Il problema più grande con OAuth 1.0a nelle applicazioni mobili e desktop è che la chiave Consumer / Application e il segreto Consumer / Application, utilizzati per firmare le richieste, possono essere estratti e esposti pubblicamente.

Ad esempio, se sei fornitore di dati e crei e fornisci una chiave di consumo a un'altra applicazione web di terze parti che vuole accedere ai dati degli utenti, la chiave e il segreto saranno sempre nascosti bene nel Web di terze parti server. Nessuno dovrebbe avere accesso ad essi (ad eccezione di alcuni sysadmin o sviluppatori). Ma questa chiave non è esposta pubblicamente al mondo.

Tuttavia, nel caso di applicazioni mobili o desktop, gli utenti finali devono scaricare queste applicazioni sul loro telefono / computer. Pertanto, qualsiasi hacker può scaricare l'applicazione ed estrarre la chiave / coppia segreta dal programma. Di conseguenza, può creare un'applicazione dannosa che finge di essere l'applicazione consumer originale.

Questo è di gran lunga il problema più serio di OAuth che io conosca, almeno nella versione 1.0a del protocollo. Il problema non è così grave, perché gli utenti finali dovranno ancora approvare l'accesso all'applicazione dannosa e spetterà a loro vedere che ha un nome diverso e che potrebbe essere sospetto riguardo l'ACCESS che desidera. Tuttavia, quando sei un fornitore che si aspetta di avere utenti mobili, non dovresti mai fidarti che siano quelli che dicono di essere.

Per quanto riguarda gli esempi sopra forniti da ATDRE, non penso che ti debba preoccupare molto, perché questi articoli presentano alcuni scenari ipotetici e non dicono nulla di concreto sui difetti di OAuth. OAuth 1.0a è perfettamente sicuro come protocollo se eseguito su SSL. Gli attacchi di cui parlano sono solo esempi comuni di web hacking, che non ha nulla a che fare con OAuth.

Ad esempio, se qualcuno ruba il cookie dell'utente finale, ovviamente può accedere e approvare richieste per conto dell'utente ... ma questo non è un problema OAuth. O l'esempio di temporizzazione, che è un esempio di una particolare implementazione della libreria del protocollo, non con il protocollo stesso ...

Mi dispiace di non poterti dire dettagli su OAuth 2.0, perché non ho ancora implementato quella versione, tuttavia posso dirti che la versione 1.0a del protocollo è buona dal punto di vista della sicurezza ...