Token di usabilità e CSRF

(questa domanda potrebbe essere più adatta al sito Esperienza utente )

Cambia il messaggio di errore in "Abbiamo bisogno che tu effettui nuovamente l'accesso perché sei rimasto inattivo per più di XX minuti." Problema risolto.

Fai sapere all'utente quanto tempo hanno esattamente , perché se devono inviare un modulo complesso devono essere consapevoli del fatto che dovranno raccogliere tutte le informazioni di cui hanno bisogno e preparare qualsiasi testo che devono input entro un tempo prestabilito. Ancora meglio, monitora su quali moduli le sessioni tendono a reimpostare e usa quelle informazioni per capire se è necessario supportare sessioni più durature.

A volte gli utenti potrebbero far scadere un token prima ancora di aver effettuato l'accesso come hai sottolineato. In tal caso, una formulazione sufficientemente generica da coprire entrambi i casi d'uso rimuoverà la necessità di provare e testare l'aspetto della sessione prima della scadenza. Hai ancora bisogno di affrontare la confusione che un messaggio del genere può causare agli utenti che non hanno effettuato l'accesso prima (il loro modello mentale potrebbe non accogliere l'idea che le singole forme scadano invece delle sessioni effettive).

Puoi farlo aggiungendo un link "Ulteriori informazioni" o "Ulteriori dettagli" sul tuo messaggio di errore. Facendo clic su tale collegamento è quindi possibile visualizzare un paragrafo aggiuntivo che spiega (sinteticamente e in prosa molto semplice!) Che i moduli di accesso Web scadono dopo XX minuti per motivi di sicurezza e l'utente è rimasto inattivo per troppo tempo. Dovrai comunque garantire che testo aggiuntivo sia visibile agli utenti senza JS.

A questo punto potresti anche implementare la tua idea di servire un nuovo token CSRF tramite AJAX quando l'utente è rimasto inattivo abbastanza a lungo ...

Modifica: alcuni servizi visualizzano direttamente un timer che indica per quanto tempo la pagina corrente sarà valida. Si può andare fino a implementare tale timer su una pagina di accesso standalone. Ciò preparerà almeno gli utenti all'idea che la pagina sia scaduta / scadrà e può essere particolarmente utile se la pagina deve essere completamente aggiornata quando scade il timer. Detto questo, l'approccio corretto rimane per non invalidare mai la pagina di accesso esistente.

C'è sempre stato uno scambio tra interfaccia utente e sicurezza. Per quanto ne so, i token CSRF nella pagina di accesso servono a proteggere dall'attacco a forza bruta, che potrebbe anche essere ottenuto con altri mezzi come la verifica Captcha. Potrebbe anche essere abusato, se possibile, per fare in modo che le vittime si colleghino al conto dell'attaccante e fare cose cattive, ma è raro, immagino.

Il migliore, penso, è di aggiornare automaticamente il token con quello nuovo non appena è scaduto. Implementare un token CSRF semplice che rimane statico per un certo periodo di tempo non è affatto utile.