Is there any prior research that describes how a cookie, or cookie
alternative would be used to provide such a guarantee?
Non penso che tu possa fornire tale garanzia, tranne forse nel dirlo nella tua politica sulla privacy e poi seguire quella politica.
The scope would be restricted to a one, or a very limited set of URLs,
L'impostazione dell'ambito può essere effettuata dal flag di sicurezza e dagli attributi del dominio e del percorso quando viene impostato il cookie. Tuttavia, è molto difficile per l'utente finale tracciare questo usando un normale browser; Supponi di limitare il cookie al percorso /loggedIn . Se l'utente visita il tuo URL /information , a prima vista sembra che il tuo sito non riceverà il cookie per le richieste a questo URL. Tuttavia, la pagina potrebbe presentare richieste a /loggedIn utilizzando JavaScript o richieste di risorse, consentendo all'utente di essere rintracciato di nascosto.
Sì, un utente interessato alla privacy potrebbe verificarlo. Tuttavia, se fossero così preoccupati per la privacy, eliminerebbero comunque i loro cookie, rendendo inutile la complessa politica sui cookie e l'implementazione.
Il client che imposta il nome e il valore del cookie non risolve questo problema. Si potrebbe continuare a tracciare il lato utente del server utilizzando il nome del cookie e le informazioni sul valore. Non sono d'accordo con ThoriumBR su Session Fixation perché non penso che ciò accresca il rischio di un simile attacco. Se l'utente malintenzionato può impostare il cookie sul browser della vittima, è irrilevante che questo cookie sia un nome e un valore scelto dall'utente o un nome o valore scelto da sever. Inoltre, non modifica il livello di rischio di un'altra vulnerabilità simile: Login CSRF . Sì se la vulnerabilità esiste, l'utente malintenzionato può accedere all'utente nell'account dell'utente malintenzionato e impostare il nome e il valore del cookie, tuttavia l'impostazione del nome e del valore del cookie non aggiunge alcun valore in sé.
Se sei preoccupato che l'uso dei cookie dissuada gli utenti attenti alla privacy dall'utilizzo del sito, non è necessario utilizzarli affatto per mantenere lo stato lato client. Un modo è far funzionare il tuo sito solo tramite i postback. Cioè, ogni azione e navigazione del sito causa la creazione di una richiesta POST e i dati POST contengono token allo stato lato server.
per es.
<form method="post" action="/siteAction">
<input type="hidden" name="token" value="aaaaaaaaaaaaaaaaaaaaaa" />
<input type="hidden" name="action" value="navigateAccountPage" />
<input type="hidden" name="params" value="{foo: 'bar'}" />
</form>
* params dovrebbe essere codificato in html, tuttavia escluso per semplicità
Ciò consentirà di memorizzare lo stato lato client senza la necessità di alcun cookie. L'utente sa di non essere monitorato in quanto può semplicemente controllare i cookie e lo spazio di archiviazione del browser (tecnicamente archiviazione HTML5, Flash e Silverlight per essere completi).