Sembra che l'intero problema possa essere risolto in modo molto elegante semplicemente aggiungendo un nuovo flag alle specifiche del cookie HTTP.
Analogamente a come i cookie segnalati con Secure verranno inviati dall'agente utente solo su connessioni sicure e quelli contrassegnati con HttpOnly saranno per sempre inaccessibili tramite l'accesso DOM, perché non specificare un nuovo flag, ad esempio NoCSR o SameOriginOnly , che, se impostato, impedirebbe che il cookie venisse inoltrato con richieste innescate da referrer di origine incrociata?
Ovviamente, verrà disattivato per non interrompere il comportamento precedentemente previsto per i siti Web già esistenti, come per HTML5 Design Principle # 2.1 . Suppongo che esista un buco di sicurezza, ma non uno che non può essere risolto facilmente: non può dipendere in modo indiscriminato, perché i vecchi browser ignorerebbero presumibilmente la bandiera non riconosciuta.
Quindi, perché non creare solo un'enumerazione di whitelisted di NoCSR -implementare le stringhe UA corrispondenti delle versioni degli interpreti degli utenti e quindi accettare / elaborare solo richieste richiedenti e sensibili che portano uno di quei valori di User-Agent: ? Per le richieste inviate con intestazioni UA non autorizzate o non autorizzate, potrebbe essere restituito un errore che richiede ragionevolmente all'utente di eseguire l'aggiornamento a una versione del browser supportata.
La whitelisting potrebbe essere eliminata con librerie di implementazione canoniche (probabilmente sarebbe più simile a una singola funzione semplice) per vari linguaggi lato server.
Non sembra molto più semplice dell'attuale sistema di generazione, tracciamento e lettura di token CSRF sicuri?
Pensieri, chiunque?