Serve aiuto per capire il meccanismo di autenticazione di Windows

1

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:

  1. 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).
  2. 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)
  3. 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.

    
posta Jordan 23.09.2015 - 13:41
fonte

3 risposte

2

È probabile che la tua richiesta iniziale sia una richiesta GET, che se implementata secondo gli standard sarà un "metodo sicuro ". Cioè, non apporta modifiche a nessuno stato.

Le richieste di sicurezza non devono essere protette perché la Stessa politica di origine impedisce un'altra origine (ad es. dominio, protocollo o porto) dalla lettura della risposta. Nota che la richiesta verrebbe comunque fatta dal dominio straniero, solo che non ha modo di leggere la risposta nella richiesta effettuata tramite il browser dell'utente.

Le richieste non sicure (che dovrebbero essere implementate come POST), dovrebbero fare uso di un metodo di prevenzione CSRF perché anche se la risposta non può essere letta in una richiesta di origine incrociata, le richieste vengono comunque fatte e, dato che è "non sicuro", avrà conseguenze (ad esempio eliminando un oggetto che l'utente ha il permesso di eliminare ).

Sotto questo aspetto, "Autenticazione di Windows" ha lo stesso effetto dei cookie in quanto autentica l'utente nel proprio browser, ma non impedisce alle richieste di origine incrociata di apportare modifiche senza alcun tipo di meccanismo di prevenzione (ad esempio Pattern token di sincronizzazione o X-Requested-With intestazione per proteggere le richieste AJAX ).

    
risposta data 24.09.2015 - 09:52
fonte
1

"Autenticazione di Windows" non è un vero metodo di autenticazione. Su un server MS IIS, quando si implementa l'autenticazione di Windows, sarà necessario selezionare "NTLM" (che è vecchio, lento e piuttosto insicuro) o "Negoziare", in cui il server tenterà di autenticarsi utilizzando Kerberos, quindi ricorrere a NTLM se non vengono soddisfatte le condizioni per utilizzare Kerberos.

Nel caso di Kerberos, non penso davvero che affidarsi a un KDC per autenticare l'utente non sia una cosa negativa e sarebbe meno sicuro di quello che farebbe il server Web.

Ti suggerisco di leggere rapidamente la pagina del protocollo Kerberos di Wikipedia , in modo da poter iniziare con giuste ipotesi.

    
risposta data 23.09.2015 - 15:08
fonte
0

Penso che mi mancasse la stessa politica di origine applicata quando la richiesta arriva indietro al client e il browser non permetterà al client di decodificare la risposta se il dominio di hosting del client è non è uguale al dominio del server - questo allora rende chiaro il motivo per cui i token CSRF non sono necessari per le richieste che sono idempotenti.

    
risposta data 23.09.2015 - 19:31
fonte

Leggi altre domande sui tag