Sommario

evil.example.com potrebbe utilizzare una cornice nascosta per richiedere un ticket CAS da corporation.example.net, quindi convalidarlo per ricevere il nome utente dell'utente sfortunato. Questo deanonymizes in modo efficace l'utente CAS a qualsiasi sito dannoso che visitano.

• In qualità di autore / manutentore del server CAS, come posso evitare la deanonimizzazione dei miei utenti?
• Come utente CAS, come posso impedire la deanonimizzazione di me stesso?

Sfondo:

CAS (Central Authentication Service) è un sistema single sign-on con un flusso basato sul redirect:

1. La pagina del client reindirizza al server CAS con un parametro service che è l'URL del sito del cliente.
2. Il server CAS autentica l'utente tramite un cookie esistente, una pagina di accesso, ecc.
3. Il server CAS reindirizza a service URL con il parametro ticket aggiunto.
4. Il client chiama un endpoint di convalida del server, scambiando il ticket per un nome utente.

Attacco

1. L'utente è già autenticato con il server CAS di corporation.example.net e il browser ha il cookie di concessione ticket per quel dominio.
2. L'utente passa a http://evil.example.com/dancing-bunnies.html , che incorpora http://corporation.example.net/cas/login?service=http://evil.example.com/attack.html come frame. (L'inquadratura è meno evidente di un reindirizzamento - non c'è alcuna differenza di sicurezza.)
3. L'endpoint /login del server CAS nel frame vede che lo user-agent ha già i cookie di accesso, quindi reindirizza ciecamente all'URL del servizio, oltre a un ticket: http://evil.example.com/attack.html?ticket=ST-abc123
4. evil.example.com legge il ticket da querystring e GETs http://corporation.example.net/cas/validate?service=http://evil.example.com/attack.html&ticket=ST-abc123 , che risponde con yes\nalice\n .
5. evil.example.com ora sa che l'utente è alice @ corporation.example.net .

Possibile miglioramento

1. Limita il dominio su service URL del parametro a un set sicuro noto
2. Richiede l'interazione dell'utente prima del reindirizzamento al client
3. Vieta l'inquadratura (con intestazioni o script)

Qualche svantaggio di uno di questi? Ci sono altre soluzioni?

Note

• Limitare il parametro service a una corrispondenza stringa su un set di URL sicuri noti è probabilmente poco pratico, poiché viene utilizzato dai client per portare lo stato tramite il processo di reindirizzamento.

ETA: sarò molto triste se la tua risposta presuppone quanto segue ...

• ... che l'attacco si basa sulla comunicazione tra origini
• ... che sto affermando che questo fa qualcosa di diverso dal deanonymize dell'utente