Perché gli sviluppatori utilizzano agenti utente incorporati per l'autenticazione di terze parti? Quali sono le alternative?

Question

Perché gli sviluppatori utilizzano agenti utente incorporati per l'autenticazione di terze parti? Quali sono le alternative?

#1 da (7 voti)
#2 da (4 voti)
#3 da (1 voti)

19

Negli ultimi anni ho notato una tendenza nelle app per dispositivi mobili e desktop con l'avvento di OAuth (e potrebbe interessare anche altri framework) per richiedere a un utente di registrarsi o accedere utilizzando provider di autenticazione di terze parti, in genere account social come Twitter, Facebook o Google. Il problema arriva quando non posso fidarmi dell'app in cui sto inserendo le credenziali, perché lo sviluppatore ha incorporato un browser in una finestra di dialogo di proprietà dell'app, e non ho nessun modo per sapere se la pagina che sto visualizzando è una pagina di accesso legittima o che l'agente utente (browser e livelli in alto) può essere considerato affidabile.

Non sto parlando di app di piccoli sviluppatori indie, sto parlando di software di aziende di grande fiducia (almeno nella comunità di sviluppo software dove trascorro la maggior parte del mio tempo). Alcuni esempi che ho visto nelle ultime settimane:

Atlassian Sourcetree ti consente di accedere utilizzando il tuo account Google - in una finestra Atlassian
Postino L'accesso a Google si verifica in una finestra Postman
Microsoft Visual Studio e Office lo fanno con il tuo account Microsoft (garantito, questo è un po 'più attendibile in quanto l'app è di proprietà del provider di autenticazione, ma continua a sostenere il processo)
Alcune app ti chiedono, per esempio, di accedere a Paypal in una finestra del browser all'interno della loro app

Domande simili poste in passato riguardo alle app mobili (ma il problema non è limitato ai dispositivi mobili):

Una domanda relativa a un'app desktop:

Come verificare il segno di Google -in schermo è valido?

E tangenzialmente correlato è l'uso degli iframe nelle applicazioni web:

Che cosa sono le implicazioni per la sicurezza di avere la finestra di accesso all'interno di un iframe

Questo è un problema di fiducia per me quando si passa dallo spazio app al Web per autenticarsi, ottenere un token e tornare all'app. Potrei fidarmi delle aziende abbastanza da installare il loro software, ma non abbastanza da inserire le chiavi principali sul mio account Google (a tutti gli effetti) nel loro software.

Nella ricerca di questa domanda ho trovato questo progetto IETF che afferma:

Embedded user-agents are an alternative method for authorization native apps. They are however unsafe for use by third-parties to the authorization server by definition, as the app that hosts the embedded user-agent can access the user's full authentication credential, not just the OAuth authorization grant that was intended for the app.

EDIT: la bozza precedente è diventata RFC8252 , datata ottobre 2017, grazie a @Geir per avermi indirizzato a questo.

e una direttiva precedente, RFC6749 (datata ottobre 2012) che cita anche tra le altre curiosità:

An embedded user-agent poses a security challenge because resource owners are authenticating in an unidentified window without access to the visual protections found in most external user-agents. An embedded user-agent educates end-users to trust unidentified requests for authentication (making phishing attacks easier to execute).

Le mie domande:

Ho ragione di temere che questa sia una crescente opportunità per gli attacchi di phishing e MITM (browser falso o dirottato nel mezzo che ruba credenziali e / o token in tempo reale, sconfiggendo anche 2FA)? Non tanto che il software affidabile di per sé possa essere reso malizioso, ma questo uso diffuso scoraggia gli utenti dal verificare la fiducia end-to-end, condonando (anche incoraggiando) gli utenti a inserire ciecamente le credenziali in qualsiasi app che li richieda?

Penso che l'ultima sezione citata sopra risponda in modo inequivocabile in senso affermativo, ma sono interessato a ulteriori commenti e prospettive intorno a questo, in particolare come sviluppatore di software stesso.
L'ovvio modo "corretto" di farlo è inoltrare l'utente al proprio browser attendibile per l'autenticazione, tuttavia questa può essere un'esperienza utente scadente e in realtà non risolve il problema (uno sviluppatore malintenzionato potrebbe aprire una finestra dall'app principale che sembra come Chrome, ma non lo è - il fatto che le sessioni utente dalla finestra principale del browser non siano conservate, tra gli altri indizi visivi sarebbe probabilmente passare inosservato di più).

Esiste un modo migliore per progettare l'esperienza utente delle app in modo tale che un utente possa essere certo di utilizzare uno stack software affidabile (app e motore di rendering) in-app? Dovrebbe esserci una gestione a livello di dispositivo o di sistema di tali richieste di autorizzazione in un modo che è difficile da imitare?
Non sono molto coinvolto nella scena della sicurezza, solo un lurker qui, è una preoccupazione ben nota nel settore? Ci sono sforzi per limitare questo tipo di flusso di autenticazione?

oauth web-browser man-in-the-middle phishing account-security

posta pcdev 14.02.2018 - 04:40

fonte

3 risposte

Leggi altre domande sui tag oauth web-browser man-in-the-middle phishing account-security

Quanto è sicuro il portachiavi su OS X? Consigli per uno strumento di gestione certificati per Linux [chiuso]

score 7 · Answer 1

Am I right to be concerned that this is a growing opportunity for phishing and MITM attacks (fake or hijacked browser in the middle which steals credentials and/or tokens in real time, also defeating 2FA)? Not so much that trusted software itself is likely to be made malicious, but in that widespread usage discourages users from verifying end-to-end trust, rather that blindly entering credentials into any app that asks for them?

Sei corretto al 100%. Alla fine, la maggior parte degli utenti si aspetta che i siti web siano simili. Se ogni sito Web ha un lucchetto verde, gli utenti notano grandi avvisi di sicurezza rossi. Quando ogni singolo sito web richiede l'e-mail degli utenti, ecc., Gli utenti iniziano a distribuire le loro informazioni di contatto senza pensarci due volte.

Allo stesso modo, gli utenti saranno "desensibilizzati" quando sempre più app chiedono credenziali usando un browser in-app. Speriamo che questo non porti gli utenti a condividere le credenziali tra servizi senza battere ciglio, ma nel peggiore dei casi possibile.
The obvious "correct" way to do it is to forward the user to their trusted browser for authentication instead, however this can be a poor user experience

Entrambe queste affermazioni sono corrette.

and doesn't actually fix the problem (a malicious developer could open a window from the main app that looks like Chrome, but isn't - the fact user sessions from the main browser window are not preserved, among other visual cues would probably go unnoticed by most).

Tristemente anche vero, anche se a questo punto è, per la maggior parte, semplice phishing. Il malintenzionato potrebbe anche inviare l'utente a un sito Web phishing: /
Is there a better way to design the user experience of apps such that a user can be sure they are using a trusted software stack (app and rendering engine), in-app?

Io non la penso così, purtroppo.

Should there be device- or system-level handling of such auth requests in a way that's hard to mimic?

Questo è estremamente interessante. Una domanda correlata su SE tratta questo problema quando arriva ai prompt di accesso a livello di sistema. Il nocciolo della questione è che non esiste un'implementazione / soluzione in uso corrente, ma alcune idee interessanti includono scorciatoie / pulsanti che chiudono le finestre che non sono di proprietà del sistema. In questo modo, il sistema potrebbe dire "premere XYZ per continuare" e, a meno che non sia realmente il sistema, la finestra viene chiusa e le credenziali non vengono inviate.

In questo caso specifico, il sistema operativo potrebbe avere un'istanza del browser di sistema con funzionalità simili come menzionato sopra. Questo browser può essere una pagina, senza navigazione ipertestuale, un semplice HTML / css / js renderer / parser di login con una facile api per OAuth.

I'm not really involved in the security scene, just a lurker here, is this a well known concern in the industry?

La preoccupazione del phishing è (o almeno dovrebbe essere) sempre a preoccupazione, ma questa è la prima volta che ho pensato personalmente nel contesto di OAuth, et al.

Are there efforts to curb this sort of authentication flow?

Non sono a conoscenza di alcun tentativo di proteggere da questo attacco, ma le smart card hardware come yubikeys codificano i token 2fa allo specifico sito Web con cui sono impostati. Questo protegge dal phishing, ma non impedisce a un browser malevolo / falso di rubare nome utente, password, ecc. Inoltre, un browser malevolo (in-app) potrebbe semplicemente rubare i cookie di sessione una volta che l'utente ha effettuato l'accesso.

Soluzione proposta per gli sviluppatori di applicazioni

OAuth dovrebbe essere fatto tramite il browser predefinito dell'utente, non in-app .

Possibile soluzione per gli sviluppatori del sistema operativo

Come discusso sopra, il sistema operativo potrebbe teoricamente fornire metodi di input fidati per OAuth, ecc. Questo potrebbe anche estendersi oltre OAuth per consentire agli utenti di accedere facilmente e in sicurezza a servizi come git in cli, ecc.

score 4 · Answer 2

È una preoccupazione, anche se (credo) una che solo ora sta diventando ampiamente riconosciuta. Ad esempio, RFC 8252 afferma su OAuth2 che:

Le richieste di autorizzazione di OAuth 2.0 devono essere eseguite solo da app native tramite agenti utente esterni, in primo luogo il browser dell'utente. ( link ).

score 1 · Answer 3

Non è una risposta completa, ma voglio aggiungere che U2F rende quasi impossibile l'autenticazione dal browser. Se dovesse essere usato, la vostra strategia "corretta" diventa effettivamente una strategia sicura. Con U2F, gli utenti non inseriscono password nel loro browser. Invece c'è un handshake sicuro tra il browser e l'autenticatore U2F ( riepilogo del protocollo ). Il più grande problema con U2F è che le aziende non si sentono motivate a investire nell'opzione.