È perfettamente possibile utilizzare il modello di token di sincronizzazione insieme al corretto supporto di navigazione / multi-tab. È solo se si prende il consiglio discutibile:
To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request
che hai problemi. In realtà non c'è una buona ragione per farlo su ogni richiesta.
C'è solo un vantaggio nel ricorrere al token CSRF nel punto in cui una sessione eleva l'autorizzazione, in genere sul login e su altri percorsi che cambiano lo stato di accesso (ad es. registrazione, recupero account, utente switch). Questi sono i punti in cui si dovrebbe anche ciclare l'identificatore di sessione, quindi ha senso farlo entrambi contemporaneamente. La modifica dell'ID di sessione impedisce il sequestro della sessione tramite la fissazione della sessione; la modifica del token CSRF impedisce un attacco CSRF attraverso la fissazione della sessione.
Torna a una pagina memorizzata nella cache nello stato di logout o di login precedente (o tenendone uno aperto in un'altra scheda) e poi provando a fare qualcosa si interromperà, ma la maggior parte delle persone probabilmente non si aspetteranno che funzioni a quel punto.
Puoi inserire alcuni JavaScript per rilevare quella situazione, se lo desideri, controllando che il cookie di sessione corrisponda a quello che è stato usato al momento della creazione della pagina. (O un cookie associato che non è l'identificatore e non è httponly , a seconda dei casi.) Se non corrisponde, è possibile aggiungere un div di avviso e il link di ricarica alla pagina e / o impedire i controlli di modulo attivi sulla pagina dall'essere reattivo. Dovresti eseguire quel controllo onload , più onpageview per bfcache se stai permettendo la memorizzazione nella cache e potenzialmente su un poller occasionale per catturare il caso multi-tab. (Questo può anche essere utile per intercettare il timeout della sessione sul lato client e presentare un errore più amichevole.)