Anche se imposto HTTPS e utilizzi token anti-contraffazione, sembra che l'autenticazione di Windows possa essere intrinsecamente insicura perché non richiede che l'utente trasmetta esplicitamente le credenziali dal client al server.
In ambienti in cui la gente usa browser più vecchi che potrebbero non imporre CORS (e soprattutto se questa gente ha disabilitato l'intestazione del referrer del browser per qualsiasi motivo) - Non sono sicuro di cosa impedirebbe a un sito Web malevolo di stabilire una sessione su un per conto dell'utente - gli utenti non devono nemmeno accedere!
La confusione, per me, si riduce a un punto: l'autenticazione iniziale:
- Se ho un sito web ospitato su un dominio locale - per semplicità chiamiamolo semplicemente abc.com (anche se per un'applicazione intranet è probabilmente solo un indirizzo IP).
- Un utente di Active Directory valido apre il suo browser e inconsapevolmente va a xyz.com (inconsapevolmente perché non sanno che si tratta di una configurazione di un sito malevolo da parte di uno dei loro ex, ma ora collaboratori licenziati e scontenti)
- xyz.com fa una richiesta valida ad abc.com
L'autenticazione di Windows è certamente una sorta di scatola nera per me - la mia ipotesi qui è che la richiesta di abc.com sarà considerata valida e la risposta fornirà il cookie di sessione necessario per le richieste future. A questo punto, ecco le mie domande:
- Il browser avrà un cookie di sessione valido per ulteriori richieste ad abc.com o il browser lascerà il cookie di sessione perché non ci sono schede / finestre attive aperte per abc.com?
- Anche se il cookie è contrassegnato con HttpOnly, l'attaccante non può ancora accedere al cookie tramite TRACE o il browser ha un modo per notificare al server che il cookie non deve più essere valido?
Se è possibile impedire al sito Web dannoso di accedere / dirottare un cookie, posso vedere come potrebbe essere possibile ragionevolmente proteggere un sito Web intranet che utilizza l'autenticazione di Windows di far sì che un utente, che non ha ancora un token anti-contraffazione , possa accedere al sito web accedendo a una pagina specifica (pagina di destinazione) che effettui prima una richiesta non restituirebbe alcun dato protetto, ma restituirebbe invece il cookie di sessione valido e un token anti-contraffazione in un'intestazione personalizzata della risposta. Tutte le chiamate future dovranno includere il token anti-contraffazione fornito dalla richiesta precedente e in caso contrario non sarà necessario inserire nuovamente la pagina di destinazione. Poiché questo token anti-contraffazione dovrebbe essere tenuto in memoria (da qualcosa come un intercettore di richiesta), non dovrebbe essere accessibile a javascript in esecuzione su altri domini (e supponendo che sia stata presa la dovuta diligenza per impedire agli attacchi XSS di accedere al token). Verrà emesso un nuovo token con ogni risposta dal server, l'intercettore lo prenderà e quindi lo includerà nell'intestazione appropriata alla successiva richiesta dal client al server.
Si noti che questo è, naturalmente, il presupposto che non ci sia alcun programma dannoso in esecuzione al di fuori del browser.