Considerazioni sulla visualizzazione dell'output OpenID e WS- * a un utente finale

0

Sto creando un sito "Impara OpenID e WS- *" e sto utilizzando tutte le migliori pratiche per rendere il sito sicuro.

Vorrei creare una pagina che decodifichi il token OpenID o WS- * della sessione corrente e visualizzarlo in una pagina di diagnostica speciale. Cosa devo esporre e non esporre per impedire un attacco di riproduzione? Non sono interessato alla divulgazione di informazioni.

È sufficiente posizionarlo su una pagina HTTPS a cui si accede utilizzando richieste POST convalidate?

Il mio intento nel porre questa domanda è di capire quanto siano preziosi certi campi in una determinata risposta di autenticazione.

    
posta random65537 22.07.2012 - 22:21
fonte

1 risposta

1

Che cosa vuoi proteggere quando mostri il token? Riproduci l'attacco? Rivelazione di un 'informazione? Etc?

se il sito si limita a testare la gestione dei token, allora è accettabile mostrare l'intero token in quanto è perché non dovrebbero usare un token da un sistema di produzione.

Se un utente malintenzionato ha il token completo, può riprodurlo, in modo che possa impersonare potenzialmente l'utente. Potrebbero anche riprodurlo contro altre applicazioni potenzialmente se il token non è crittografato (o le applicazioni condividono la stessa chiave di decrittografia). Inoltre, se il token contiene reclami con segreti o informazioni personali, un utente malintenzionato potrebbe raccogliere tali informazioni.

Con tutto ciò che viene detto, il token è inutile per l'autenticazione se si spoglia la firma (beh, supponendo che l'applicazione in realtà convalidi la firma).

MODIFICA: se vuoi mostrare il token completo ma impedire gli attacchi di riproduzione, tieni semplicemente una voce per quel token prendendo un hash di esso. WIF supporta la cache dei token, che è progettata in parte per tale motivo, ma dovresti eseguire un'implementazione personalizzata.

    
risposta data 23.07.2012 - 01:03
fonte

Leggi altre domande sui tag