Memorizzazione di dati XML in un cookie

Question

Sto provando a memorizzare un oggetto serializzato xml in un cookie, ma ricevo un errore del genere:

A potentially dangerous Request.Cookies value was detected from the client (KundeContextCookie="<?xml version="1.0" ...")

Conosco il problema da casi simili quando provi a memorizzare qualcosa che assomiglia al codice javascript in un campo di input del modulo.

Qual è la migliore pratica qui? C'è un modo (come il problema con il modulo che ho descritto) di sopprimere questo avviso dal framework asp.net, o dovrei invece serializzare JSON o forse dovrei serializzarlo binario? Qual è la pratica comune quando si archiviano dati serializzati in un cookie?

EDIT: Grazie per il feedback. Il motivo per cui voglio memorizzare più dati nel cookie rispetto all'ID è perché l'oggetto di cui ho veramente bisogno impiega circa 2 secondi per recuperare da un servizio sul quale non ho alcun controllo. Ho creato un oggetto leggero "KundeContext" per contenere alcune proprietà dell'intero oggetto, ma queste vengono utilizzate il 90% delle volte. In questo modo devo solo chiamare il servizio lento sul 10% delle mie pagine. Se solo memorizzassi l'id, dovrei comunque chiamare il servizio su quasi tutte le mie pagine.

Potrei memorizzare tutte le stringhe e gli inserti separatamente, ma l'oggetto ha altri oggetti leggeri come "informazioni di contatto" e "indirizzo" che sarebbe noioso archiviare manualmente per ciascuna delle loro proprietà.

Answer 1

Non memorizzerei i dati in XML nei cookie - esiste un limite alle dimensioni dei cookie per i principianti (usato per essere 4K per le intestazioni tutte incluso il cookie). Scegli invece una strategia di codifica meno dettagliata come i delimitatori invece ad es. a | b | c o valori di cookie separati. La codifica delimitata rende particolarmente facile e veloce la decodifica dei valori.

L'errore che vedi è ASP.NET che si lamenta che le intestazioni sembrano un attacco XSS.

Answer 2

La memorizzazione di dati serializzati in un cookie è una pessima idea. Poiché gli utenti hanno il controllo completo sui dati dei cookie, è troppo facile per loro utilizzare questo meccanismo per fornire dati dannosi. In altre parole: qualsiasi debolezza nel codice di deserializzazione diventa immediatamente sfruttabile (o almeno un modo per bloccare qualcosa).

Invece, conserva nei tuoi cookie solo l'identificatore più semplice possibile, di un tipo di cui il formato può essere facilmente convalidato (ad esempio un GUID). Quindi, archivia il tuo lato dati serializzato lato server (in un database, file XML sul filesystem o altro) e recuperalo utilizzando quell'identificatore.

Modifica: inoltre, in questo scenario, assicurati che il tuo identificatore sia abbastanza casuale da rendere impossibile agli utenti di indovinare gli identificativi reciproci e di impersonarsi cambiando semplicemente il proprio identificatore un po '. Ancora una volta, i GUID (o identificatori di sessione ASP.NET) funzionano molto bene per questo scopo.

Seconda modifica dopo chiarimento dello scenario da parte del proprietario della domanda: perché utilizzare i propri cookie in questo caso? Se mantieni un riferimento all'oggetto originale o al tuo oggetto leggero nello stato della sessione (oggetto Session), ASP.NET si prenderà cura di tutti i dettagli dell'implementazione in modo abbastanza efficiente.

Answer 3

Guarda nel Visualizza stato . Forse ti piacerebbe conservare i dati tra i postback nel ViewState invece di utilizzare i cookie. Altrimenti, dovresti probabilmente memorizzare l'XML sul server e un identificatore univoco per quei dati nel cookie,

Answer 4

Puoi esaminare l'utilizzo di Session State per memorizzare il valore . È possibile configurarlo per utilizzare un cookie per memorizzare l'id di sessione. Anche questo è più sicuro, perché il valore non è né visibile né modificabile dal lato utente.

Un'altra alternativa è utilizzare un meccanismo di memorizzazione nella cache distribuito per memorizzare il valore. Il mio preferito attuale è Memcached .