Il design SSO è sicuro?

Question

Il design SSO è sicuro?

#1 da (1 voti)
#2 da (1 voti)

4

Stiamo lavorando a un'implementazione SSO che verrebbe utilizzata su domini. Mi rendo conto che ci sono modelli funzionanti collaudati come CAS per questo, ma sto giocando con un approccio diverso e voglio ricevere feedback da tutti voi qui per vedere se questo è sicuro o meno. La premessa di base è che non vogliamo utilizzare i reindirizzamenti se non è necessario e vogliamo che i siti dei prodotti siano in grado di personalizzare le proprie pagine di accesso. Si rivolge solo a IE8 + e ai moderni FF e webkit. Quindi, senza ulteriori indugi l'implementazione:

Il client accede al sito del prodotto A.com. Non hanno un cookie di sessione per a.com, quindi il sito avvia lo script dell'autore genitore.
Lo script padre crea un iframe che carica una pagina dal server di autenticazione su auth.com. Auth.com convalida la richiesta in base all'intestazione del referer e, se il referer non è affidabile, risponde con x-frame-options: DENY e / o reindirizzamento del frame.
Lo script su questa pagina (lo script con cornice) fa una richiesta ajax al server di auth.com che richiede un token di tempo SSO 1 (1TT).
Il client non ha un cookie auth.com quindi questo è rifiutato, e lo script iframe dice allo script genitore di compilare un modulo di autenticazione usando window.postMessage (e lo script genitore convalida l'origine) per comunicare poiché è cross domain.
L'utente inserisce le proprie credenziali e invia invia.
Le credenziali vengono passate dallo script padre allo script framed tramite postMessage nuovamente, e lo script con frame le usa per accedere a auth.com, ricevendo sia un cookie auth.com che un 1TT.
L'1TT è passato allo script genitore.
Lo script genitore passa il 1TT al server di A.com.
A.com utilizza l'1TT per ottenere le informazioni dell'utente dal server di auth.com tramite un'API interna privata e auth.com invalida l'1TT in modo che non possa essere riutilizzato.
A.com restituisce un cookie di sessione per A.com al client e ora il client esegue la sua attività su A.com.
Quindi il client passa a B.com, ma ancora non ha cookie di sessione per B.com. Lo script genitore viene eseguito nuovamente, il che crea un iframe che punta nuovamente a auth.com. Lo script iframe richiede un 1TT da auth.com e dal momento che ha un cookie di sessione per auth.com questa volta ne ottiene uno.
L'1TT viene passato dallo script iframe allo script padre al server di B.com che lo utilizza per ottenere l'utente da auth.com e rilasciare un cookie di sessione per B.com.

La mia preoccupazione principale è al punto 2. È un modo solido per prevenire l'inquadramento dannoso? Quali altre vulnerabilità di sicurezza sono suscettibili a questo?

Modifica: tutti i siti e gli script verranno caricati HTTPS.

sso

posta rbrc 15.02.2013 - 20:27

fonte

2 risposte

Leggi altre domande sui tag sso

Dispositivi IoT noti non protetti [chiuso] Crittografia dell'intero disco su un tablet (che non ha una tastiera di preavvio) [chiuso]

score 1 · Answer 1

Non ci sono abbastanza informazioni nel tuo elenco (tanto difficile da credere, con 12 passaggi e tutto) per rispondere correttamente, ma come hai detto nel tuo commento sopra - questo è abbastanza vicino al modello di StackExchange.

Con questo in mente; hai considerato di gestire il tuo provider OpenID ? La specifica del protocollo sembra molto simile a ciò che stai cercando. Anche questo è un modello ben collaudato, quindi molte delle preoccupazioni sono già state ben risolte. OAuth potrebbe essere adatto, ma è progettato attorno a token di accesso limitati - non ne sai abbastanza su ciò che stai facendo per dire quale è più appropriato.

Tornando al tuo modello - quello che hai specificato sembra ok, anche se, come scritto, c'è un mix di elementi di "modello" e di "implementazione" che lo rendono un po 'difficile da analizzare. Stai facendo affidamento sul referrer, ma in questo scenario sembra, fingendo che il referrer acceda solo un client a un altro sito a cui avrebbero comunque accesso. Stai dipendendo da referer però - forse basta caricare il frame con una richiesta GET incluso il referrer?

Stai anche facendo affidamento sulla possibilità di passare informazioni avanti e indietro tra i frame; potresti voler prendere in considerazione l'utilizzo di una pagina provvisoria su auth.com invece (cioè inoltrare l'utente a auth.com, se l'utente ha già effettuato l'accesso, POST torna al link con 1TT). Usare iframe complica le cose (cosa succede se sei già in una cornice? Stai facendo affidamento sul browser qui per "scoppiare" con successo - potrebbe essere sovvertito facendo scherzi con il DOM?). potresti essere in grado di renderlo sicuro, ma è un fattore di complicazione - e il nemico di buona sicurezza tende a essere schemi troppo complicati.

score 1 · Answer 2

Questo design SSO presenta una serie di limiti tecnici che ne rendono impossibile l'implementazione. Ci sono problemi di sicurezza con questo design.

La vulnerabilità peggiore implementata da questo progetto è OWASP A9-Insufficient Transport Layer Protezione . SSL deve essere utilizzato per proteggere tutte le informazioni di autenticazione, quindi se si versa un cookie di autenticazione su HTTP una sessione potrebbe essere dirottata. Quindi, se un utente su una rete Wi-Fi dovesse autenticare usando questo design SSO, potrebbe avere il suo account compromesso con uno strumento come firesheep .

# 2 non è possibile: Il sito di origine A.com deve caricare l'iframe di autenticazione utilizzando una pagina HTTPS. Tuttavia, facendo ciò, mancherà l'elemento di intestazione referer e non c'è modo di verificare da dove provenga la richiesta. La proposta dell'intestazione di origine di Mozilla sta tentando di risolvere questo problema, ma il suo non supportato da tutti i browser. OAuth utilizza un URL di callback firmato per assicurare che un browser sia autenticato in un dominio trusted .

Per il n. 9, invece di condividere i dati utente con "private internal API", prova a utilizzare uno standard pubblico come OAuth. In effetti ciò che hai descritto suona molto simile a OAuth a 3 zampe . OAuth è probabilmente il modo in cui hai autenticato il link per porre questa domanda e ha dimostrato di essere sicuro.