OAuth Flusso di autorizzazione e reindirizzamento

La consegna del codice di autorizzazione non è più un problema di sicurezza rispetto all'invio della password dell'utente dal browser al server di Facebook (ad esempio). Ciò significa che se c'è una connessione non sicura, un utente malintenzionato sarebbe comunque in grado di compromettere l'autenticazione dell'utente. Per questo motivo, OAuth è pensato per essere eseguito con HTTPS.

Il motivo per cui ha bisogno di essere implementato in questo modo è perché solo in questo modo il client OAuth è in grado di identificare l'utente che ha richiesto OAuth. Questo perché quando un utente, ad esempio, fa clic sul pulsante di Facebook su StackOverflow, lo collega immediatamente a Facebook dove inizia il processo OAuth. StackOverflow finora non sa che questo utente ha richiesto OAuth tramite Facebook. Solo ora reindirizzando l'utente a StackOverflow insieme al codice di autenticazione StackOverflow sa che questo utente (con il suo ID di sessione) ha utilizzato facebook OAuth e ottenuto questo codice di autenticazione. Ora StackOverflow è in grado di connettere l'ID sessione con il codice di autenticazione e sa chi ha richiesto l'OAuth di Facebook.

modifica Ho esaminato la RFC di OAuth e devo apportare una correzione per quanto riguarda il mio primo punto. Sebbene sia altamente raccomandato che l'endpoint di reindirizzamento utilizzi HTTPS, è non obbligatorio ancora. Vedi Riservatezza richiesta endpoint . Quindi il codice di autenticazione potrebbe essere inviato in modo non crittografato ad un certo punto, cioè quando si reindirizza al server originale che non ha attivato HTTPS. Ma comunque, per me questo è un enorme problema di sicurezza con l'intero processo OAuth. L'HTTPS dovrebbe essere obbligatorio. Se un server non può HTTPS è la connessione, non dovrebbe giocare con OAuth dopo tutto.

Viene rinviato al browser perché è essenziale farlo in questo modo.

Potrebbe essere pazzesco, ma l'intera sicurezza OAuth / OpenId si basa sul fatto che il tuo browser eseguirà il reindirizzamento corretto.

Analizziamo un attacco se non utilizzi il browser come reindirizzamento, ma prima definiamo una versione semplificata del "framework" OAuth per il nostro esempio.

• Client: l'applicazione a cui desideri connetterti
• Browser: il tuo browser ...
• Provider: il provider OAuth (es .: Google o Facebook)
• Male: l'attaccante.

Il flusso normale

1. Browser chiedi al client di accedere
2. Il client reindirizza il browser al provider
3. Provider autentica il browser quindi reindirizza a Client con token
4. Il client comunica con il provider che fornisce il token per l'autorizzazione.
5. Client concede l'autorizzazione al browser.

Il tuo flusso

1. Browser chiedi al client di accedere
2. Il client reindirizza il browser al provider
3. Provider autentica il browser e invia token al client dandogli l'autorizzazione
4. Client concede l'autorizzazione al browser

Il problema qui è che il client non è sicuro che il browser con cui sta comunicando sia lo stesso browser che si autentica con il provider.

Un attacco al tuo flusso

1. Accesso al browser Male per qualche cattiva ragione
2. Il male impersona il browser e chiede al cliente di accedere.
3. Il client invia il link di reindirizzamento a Evil
4. Evil inoltra il link al browser che lo reindirizza al provider
5. Il provider autentica il browser e invia il token al Cliente dandogli l'autorizzazione
6. Il client concede l'autorizzazione al malvagio pensando che sia Browser

Vedi il problema nell'ultimo passaggio?

Questo non si sarebbe verificato se si stesse utilizzando un reindirizzamento del browser per inviare il token al client. Utilizzando un reindirizzamento del browser, ci si assicura che il browser che si autentica con il provider sia lo stesso browser che sta tentando di ottenere diritti di autorizzazione con il client.

Questo è un passaggio cruciale. Soprattutto perché molti Provider invieranno automaticamente il token dopo la prima volta se effettui il login. Quindi, Evil potrebbe ottenere l'accesso al tuo account solo visitando la sua pagina e non lo sapresti nemmeno.

Lo stesso attacco con flusso normale

1. Accesso al browser Male per qualche cattiva ragione
2. Il male impersona il browser e chiede al cliente di accedere.
3. Il client invia il link di reindirizzamento a Evil
4. Evil inoltra il link al browser che lo reindirizza al provider
5. Provider autentica il browser quindi reindirizza a Client con token
6. Il client comunica con il provider che fornisce il token per l'autorizzazione.
7. Client concede l'autorizzazione al browser.

Qui il male è stato eclissato alla fine a causa del reindirizzamento. Questo è il motivo per cui i protocolli eseguono così tanti controlli sull'URL di reindirizzamento per assicurarsi che non vengano reindirizzati a un sito dannoso che ruba il token di autorizzazione.

OAuth / OpenId ti protegge nuovamente dal tentativo di phishing. Ma possono farlo solo perché il tuo browser sta facendo il reindirizzamento giusto. Sull'app desktop / mobile questo non funziona, quindi perché i protocolli sono meno sicuri sull'app desktop / mobile.

In particolare, protegge il Cliente dal tentativo di phishing. Il cliente deve prendere la decisione molto difficile: il browser che richiede l'autorizzazione è lo stesso del browser che si autentica con il provider? E l'unica cosa che aiuta il cliente a farlo è il reindirizzamento e il fatto che il tuo browser sia sicuro.

Dal momento che protegge direttamente il cliente dal phishing, protegge indirettamente te.