Progettazione di single-sign-on con JSONP / CORS?

Naviga le tue risposte
9

Mi piace il modo in cui OAuth / OpenID può autenticare / identificare un utente da un altro dominio, ma solo se l'altro dominio lo consente (presumibilmente sulle istruzioni dell'utente).

Mi piacerebbe fare qualcosa di simile, ma usando CORS AJAX o un'alternativa come JSONP. Il problema è che quando si utilizza un reindirizzamento a pagina intera, il "dominio di accesso" può essere certo su quale dominio fornisca auth_token / info, perché sta emettendo un Redirect HTTP stesso. Tuttavia, questo non è vero per JSONP.

I miei pensieri attuali sono di seguito, e le mie domande sono:

  • Quali sono i punti deboli in questo modello?
  • C'è un modo per farlo senza due richieste separate (per il caso non CORS)?

Caso generale:

MODIFICA: questa sezione inizialmente presupponeva una richiesta JSONP - infatti, penso che potrebbe essere qualsiasi tipo di dati

Caso A : utente che ha effettuato l'accesso sul "dominio di accesso" (utilizzando i cookie)

  1. Il client inoltra una richiesta al "dominio di accesso", fornendo un URL sul "dominio del servizio"
  2. Il server di login esamina l'URL fornito e pensa "sì, va bene" e restituisce una risposta HTTP Redirect (3XX) che include un auth_token / qualsiasi cosa nell'URL
  3. Il client segue il reindirizzamento al dominio del servizio. Il dominio del servizio memorizza il auth_token / qualsiasi cosa nella sessione e restituisce una risorsa statica (ad esempio un'immagine)
  4. Il client effettua quindi una seconda richiesta al dominio del servizio (non è consentita alcuna origine incrociata) per recuperare il token_autore / qualunque sia.

Caso B : l'utente non ha effettuato l'accesso sul "dominio di accesso" o non ha autorizzato i dettagli di condivisione con il "dominio del servizio".

  1. Il client inoltra una richiesta al "dominio di accesso", fornendo un URL sul "dominio del servizio"
  2. Il server di login restituisce una risposta HTTP Redirect (3XX) che include uno stato "non autorizzato" nell'URL (o forse l'URL di un accesso OAuth a pagina intera)
  3. Il client segue il reindirizzamento al dominio del servizio. Il dominio del servizio memorizza lo stato "non autorizzato" nella sessione, restituendo una risorsa statica al client.
  4. Il client effettua quindi una seconda richiesta al dominio del servizio (non è consentita alcuna origine incrociata) per scoprire che l'autorizzazione / identificazione non è riuscita.

Caso C : altro sito che tenta di ispezionare lo stato di accesso

  1. L'utente naviga verso il sito dubbia
  2. Il client effettua una richiesta al server di login, fornendo un URL sul effettivo dominio di servizio
  3. Il server di login reindirizza a una pagina del dominio del servizio effettivo, che restituisce un risultato statico
  4. L'utente può o non può aver effettuato l'accesso - ma il client non può scoprirlo perché l'endpoint "dominio del servizio" che gli dirà è vietato dalla restrizione di origine incrociata

Caso CORS AJAX

Se l'endpoint "server di accesso" ha CORS abilitato, la richiesta potrebbe essere effettuata come richiesta AJAX. Se l'endpoint "dominio di servizio" non ha CORS abilitato, il risultato finale di questa richiesta AJAX potrebbe effettivamente essere un'eco di auth_token / qualunque, invece di richiedere una seconda richiesta.

  1. Il client invia una richiesta CORS AJAX al "dominio di accesso", fornendo un URL sul "dominio del servizio"
  2. Il server di login restituisce una risposta HTTP Redirect (3XX) che include auth_token / failure / whatever nell'URL
  3. Il client segue il reindirizzamento al dominio del servizio.
  4. Il dominio del servizio restituisce un documento contenente tutte le informazioni fornite nell'URL (auth_token / qualunque).

In effetti, questo comportamento "echo the auth_token" potrebbe anche essere usato al posto della risorsa statica dalla sezione precedente, supportando quindi entrambi i modelli con lo stesso endpoint.

    
posta cloudfeet 31.05.2013 - 16:57
fonte

1 risposta

6

OAuth è flessibile e talvolta il flusso OAuth viene modificato per esigenze specifiche dell'applicazione. I due flussi più comuni sono 2-legged e 3-legged , che se questi flussi sono implementati correttamente, allora sono generalmente accettati come sicuri.

L'implementazione CORS AJAX del flusso OAuth viola due requisiti di sicurezza di RFC-6749 - OAuth 2.0 Framework di autorizzazione . Questa deviazione dallo standard mina la capacità del server di autorizzazione di convalidare correttamente il client e le intenzioni del cliente.

  1. Deve esserci un controllo per impedire a un client JavaScript malintenzionato di falsare le interazioni con il server di autorizzazione . Se l'URL viene fornito come argomento all'interno di una richiesta Ajax CORS, piuttosto che controllare l' intestazione di origine HTTP , quindi un client malevolo può mentire sul suo contesto. Inoltre, viene utilizzato un reindirizzamento per l'autenticazione reciproca del server di autorizzazione e del client. Non avere questi controlli sul posto è una violazione di RFC-6749 - 10.2. Rappresentazione del client :

    A malicious client can impersonate another client and obtain access to protected resources if the impersonated client fails to, or is unable to, keep its client credentials confidential.

    The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.

  2. Il flusso OAuth deve essere avviato dall'utente. Il parametro dello stato OAuth viene utilizzato per impedire CSRF quando si stabilisce l'autenticazione. Costringere un utente ad accedere ad un'applicazione web è un link utile in una catena di attacco di sessione. Dopo aver stabilito una sessione, un utente malintenzionato può controllare la sessione appena creata utilizzando CSRF o XSS. La mancata dimostrazione dell'intenzione dell'utente in questo contesto è una violazione di RFC-6749 - 10.12. Falsificazione richiesta tra siti diversi :

    A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).

risposta data 08.09.2014 - 16:36
fonte

Leggi altre domande sui tag

In che modo includere un prefisso magico a una risposta JSON per impedire gli attacchi XSSI? Quale applicabilità deve risolvere il problema di stallo?