1. Utilizza SSL
2. Assicurati di implementare correttamente la gestione delle sessioni, ad esempio la presenza dell'ID di sessione corretto controllato in ogni pagina e distrutto con il logout
3. Aggiungi controllo cache: no-cache, pragma: no-cache e scadenza: -1 intestazioni ovunque
4. Assicurati che i moduli e ogni variabile sensibile vengano inviati solo tramite le richieste POST e non GET (durante i controlli del codice ho visto innumerevoli volte le pagine che accettano entrambi i metodi senza alcun motivo)

Se un proxy cambia le cose, allora non stai usando SSL, e non usare SSL è molto cattivo se i dati scambiati sono "sensibili". A proposito, dati sensibili su un chiosco pubblico che può essere "migliorato" con un keylogger, beh, non è nemmeno estremamente rassicurante.

È possibile utilizzare Javascript per scaricare e visualizzare le pagine di contenuto senza "modificare la pagina" nel senso del browser. Dovresti quindi fornire i tuoi "pulsanti" indietro e avanti. Quindi aggiungi un hook alla modifica effettiva della pagina (dal punto di vista del browser) per eseguire lo zapping dei contenuti interni.

Nessuno dei precedenti ti salverà se l'utente apre una nuova finestra e dimentica di chiudere quella "sensibile".

I controlli cache si applicano alle connessioni SSL e sono ampiamente supportati dai browser in modo che sembrino l'approccio migliore. Se si sta effettuando la connessione su SSL, un proxy eseguirà un man-in-the-middle e servirà i contenuti, o semplicemente lo ignorerà e tornerà normale. Nel caso in cui esegua un MiTM, interromperà il controllo di attendibilità del certificato del browser in modo che venga visualizzato un grande errore rosso e (si spera) agli utenti venga insegnato ad allontanarsi dal chiosco e utilizzare qualcos'altro. Se non lo fanno, bene, sei SOL.

Se il proxy instrada la connessione e passi nelle intestazioni di controllo cache o Expired, o Last-Modified, il browser si spera che lo supporti. Il problema che si incontra è la cache locale della pagina HTML. Un utente malintenzionato potrebbe semplicemente leggere la pagina dalla cache. Se il browser non lo supporta, non consentire all'utente di visualizzare la pagina. Controlla lo user-agent e confrontalo con un elenco di versioni supportate conosciute.

Ovviamente, come ha detto Tom, se il chiosco ha installato un keylogger, game over.

Una vecchia domanda, ma aggiungendo una risposta per i tempi moderni.

Per le risposte sensibili, devi impostare la seguente intestazione:

Cache-Control: no-store, must-revalidate

Di questi tempi, probabilmente non ti devi preoccupare dell'intestazione dell'1,0% diExpires HTTP. Pragma è solo per richieste, non per risposte.

Per aggiornare la pagina subito dopo il timeout della sessione (in modo che venga visualizzato il modulo di accesso), aggiungi questa intestazione:

Refresh: n + m

Dove n è il numero di secondi fino alla scadenza della sessione e m è un piccolo ritardo. In Java questo è:

session.getMaxInactiveInterval() - ( System.currentTimeMillis() - session.getCreationTime() ) / 1000

Dal caso MSFT n. 111101555217932

Vedrai questa funzionalità con qualsiasi pagina web che accetta dati all'interno di una richiesta POST HTTP. La logica di Azure ACS è che il processo di invio dei dati dei moduli tramite un POST HTTP viene effettivamente visualizzato come una voce nella cronologia dei browser. Se si controlla la cronologia immediata del browser, la voce appare come "In lavorazione ..." nell'elenco. Questo ti consente di "navigare" verso questa voce. Una volta che si tenta di tornare a questa "pagina", il browser nota che il contenuto è già scaduto, quindi richiede all'utente che il contenuto è scaduto e chiede se si desidera inviare nuovamente la richiesta per ottenere la versione "aggiornata" di quella pagina dal server. Dopo aver fatto clic sul pulsante Riprova, i dati dei moduli vengono passati a ADFS e ADFS lo considera come una normale richiesta di accesso, in modo che autentica tale richiesta e restituisca il token SAML e reindirizzamenti automatici alla pagina Web originale.

Vedrai lo stesso comportamento anche con altri browser.

Quindi vogliamo sapere come evitare di consentire agli utenti di accedere come un altro utente semplicemente eseguendo il back, back, back, refresh. Ho avuto alcune discussioni con il nostro team di IE e il nostro team di ASP.NET e ci siamo inventati un paio di cose che potresti provare ad evitare questo problema.

Soluzioni alternative lato client

1. Un suggerimento del nostro team di IE è di modificare la tua pagina di accesso ADFS in modo che non accetti le credenziali di accesso direttamente. Invece contiene solo un pulsante che dice accesso. Quando l'utente fa clic su questo pulsante di accesso, si avrà qualche javascript che esegue la chiamata a window.open () per avviare una seconda piccola finestra di dialogo che si sposta su una seconda pagina ospitata nel sito Web di ADFS. La seconda pagina ADFS accetterà il nome utente e la password e quindi la invierà per l'autenticazione. Dopo che la finestra di dialogo è stata avviata, è possibile chiudere la finestra e utilizzare la finestra genitore per navigare verso l'applicazione del relying party.

2. Un altro suggerimento è provare una chiamata location.replace () come descritto qui: link Questa operazione rimuoverà una voce dall'elenco della cronologia mentre navighi in una nuova pagina.

Soluzioni alternative al lato server

1. Un'opzione consiste nel modificare la pagina di accesso ADFS per richiedere anche all'utente di inviare un valore basato sul tempo come parte dei dati del modulo. Supponiamo che tu abbia aggiunto un valore TimeSubmed al modulo e quando l'utente ha fatto clic sul pulsante di accesso hai uno script che imposta il valore sull'ora corrente e lo invia come parte dei dati di accesso. Quindi dal lato server verificherai questo valore e se fosse più di 2 o 5 secondi dopo l'ora corrente del server, potresti respingere il tentativo di accesso e inviare al cliente una nuova pagina di accesso per inserire manualmente il combinazione nome utente / password di nuovo.

2. Un altro suggerimento lato server è di manipolare la cronologia del browser per rimuovere quella voce "Working ...". Per fare ciò è possibile emettere script lato client all'interno dell'evento PreRender delle pagine. Quindi nella tua pagina di accesso potresti avere

    private void WebForm1_PreRender(object sender, System.EventArgs e)
    {
       if (IsPostBack)
    {
    Response.Write("<html><head><script>location.replace('"+Request.Path+"');\n"
    +"</script></head><body></body></html>\n");
    Response.End();
    }
   

La richiesta POST viene rimossa dalla cronologia di navigazione di IE. La cronologia conterrà solo richieste GET.

1. Puoi anche nascondere la barra di navigazione del browser nel tuo chiosco e aggiungere direttamente i pulsanti indietro e avanti alle tue pagine. Dovresti gestire le funzionalità di navigazione della pagina con le tue pagine e ovviamente non consentire a un utente di navigare "Indietro" dalla pagina di accesso di ADFS.

Purtroppo non esiste un modo semplice per aggirare il problema di disabilitare la possibilità per qualcuno di inviare nuovamente i dati del modulo, anche se i dati del modulo vengono utilizzati per autenticare e accedere a un utente. Tra tutti i suggerimenti proposti, probabilmente implementerei la prima soluzione lato server in cui si passa semplicemente il tempo inoltrato e se si tratta di un certo delta lontano dal tempo del server, ignorare la richiesta perché è il ripubblicare di un precedente tentativo di accesso riuscito.

Nella mia esperienza con la navigazione php è "difficile" tornare indietro dopo essere stato disconnesso e reindirizzato alla schermata di accesso o chiudere la finestra. Concessa qualsiasi istanza di una finestra aperta a una pagina aperta è un in prima della scadenza. A seconda del numero di utenti protetti con bocche sicure che hai, una variazione su CAPTCHA catturerà i tentativi di riutilizzare i cookie o le sequenze di tasti memorizzate. Il metodo più semplice consiste nell'aggiungere una varianza predeterminata a un generatore di pin CAPTCHA. Cioè il pin # generato è 5463 Aggiungo il mio giorno di nascita 14. Nel codice per CAPTCHA è sufficiente aggiungere la stringa utente all'istruzione if. Spiacente, non è brillante ma, per lo scenario che hai descritto, è efficace ed è facile.