Da quello che posso vedere, CAS è una forma di autenticazione OAuth2, anche se non usano quel termine sul loro sistema.
Per rendere OAuth2 sicuro, il servizio che lo utilizza deve avere un insieme di chiavi (è più simile ad avere un login e una password segreti.) Senza tali chiavi, sarebbe molto facile inviare il l'utente direttamente al server CAS con un ID in modo che l'utente malintenzionato sappia esattamente quale ID si intende utilizzare.
+------------------+ +----------------------+
| | | |
| Your Server +-------+---------->| CAS Server |
| | | | |
+------------------+ | +--------+-------------+
| |
+------------------+ | |
| | | |
| Hacker Server +-------+ |
| | v
+---------+--------+ +----------------------+
. | |
+...........................>| Back to Your Server |
| |
+----------------------+
Senza alcuni segreti del tuo computer, abbiamo un modo molto semplice per sapere quale identificatore di sessione è un hacker. Generiamo solo detto ID e ti inviamo al server CAS. Attendi un po 'e poi accedi al server interessato.
Immagino che CAS abbia i segreti necessari, quindi questo non avrebbe funzionato.
Ora, se posso creare un attacco XSS che imposta un cookie con l'ID di sessione, allora posso anche acquisire le conoscenze necessarie per connettermi al server una volta che l'utente ha effettuato l'accesso.
Con l'XSS potrebbero probabilmente sfruttare un problema sui tuoi sistemi. Quindi l'hacker ha un link al tuo server che qualcosa di sbagliato ed esegue il codice dell'hacker (JavaScript o meta tag). Quel codice imposta l'ID di sessione o controlla l'ID di sessione esistente e lo POST su uno dei computer del pirata informatico.
+------------------+ +----------------------+
| | | |
| Your Server +------------------>| CAS Server |
| | | |
+------------+-----+ +--------+-------------+
^ | |
| | |
| v v
+--------+---------+ +----------------------+
| | | |
| Hacker Server +..................>| Back to Your Server |
| | | |
+------------------+ +----------------------+
In questo caso, poiché l'ID della sessione non cambierà, avranno accesso al tuo server per 15 o 20 minuti dopo che l'utente ha effettuato l'accesso. Un attacco XSS è piuttosto facile da evitare, ma ho sentito parlare di molti di questi attacchi (ho lavorato su Drupal per un po 'e ne ho scoperti parecchi da parte di programmatori che non pensano fuori dagli schemi e utilizzano dati potenzialmente macchiati così com'è).
Un esempio di questo è per colpire una pagina 404 utilizzando il codice nell'URI:
http://example.com/<script>document.cookie = "JSESSIONID=123";</script>
Un programmatore che crea una pagina 404 e mostra il tag <script> così com'è (cioè senza sostituire < con < e > con > ) consente una attacco cross-site in quanto il rogue JavaScript verrà eseguito sul tuo sito.
Nota che con un attacco Man In The Middle (MITM), non hai nemmeno bisogno di un XSS o di una cattiva implementazione di OAuth2. Ma è più difficile eseguire un MITM e nella maggior parte dei casi richiede un luogo pubblico in modo che le persone al lavoro abbiano meno probabilità di avere un collega hacker che sa come essere un MITM.