Almacenamiento de datos xml en una cookie

Question

Estoy intentando almacenar un objeto serializado xml en una cookie, pero aparece un error como este:

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

Conozco el problema por casos similares cuando intentas almacenar algo que parece código javascript en un campo de entrada de formulario.

¿Cuál es la mejor práctica aquí?¿Hay alguna manera (como el problema de formulario que describí) de suprimir esta advertencia del marco asp.net, o debería serializarlo en JSON o quizás debería serializarlo en binario?¿Cuál es la práctica común al almacenar datos serializados en una cookie?

EDITAR:Gracias por la respuesta.La razón por la que quiero almacenar más datos en la cookie que el ID es porque el objeto que realmente necesito tarda unos 2 segundos en recuperarse de un servicio sobre el que no tengo control.Creé un objeto liviano 'KundeContext' para contener algunas de las propiedades del objeto completo, pero se usan el 90% del tiempo.De esta manera sólo tengo que llamar al servicio lento en el 10% de mis páginas.Si solo almacenara el ID, igual tendría que llamar al servicio en casi todas mis páginas.

Podría almacenar todas las cadenas e entradas por separado, pero el objeto tiene otros objetos livianos como 'información de contacto' y 'dirección' que sería tedioso almacenar manualmente para cada una de sus propiedades.

Answer 1

No almacenaría datos en XML en la cookie; para empezar, hay un límite en el tamaño de la cookie (solía ser 4K para todo encabezados, incluida la cookie).Elija una estrategia de codificación menos detallada, como delimitadores, p.a|b|c o valores de cookies separados.La codificación delimitada hace que sea especialmente fácil y rápido decodificar los valores.

El error que ve es que ASP.NET se queja de que los encabezados parecen un ataque XSS.

Answer 2

Almacenar datos serializados en una cookie es una muy, muy mala idea.Dado que los usuarios tienen control total sobre los datos de las cookies, les resulta demasiado fácil utilizar este mecanismo para proporcionarle datos maliciosos.En otras palabras: cualquier la debilidad en su código de deserialización se vuelve instantáneamente explotable (o al menos una forma de bloquear algo).

En su lugar, mantenga únicamente el identificador más simple posible en sus cookies, cuyo formato pueda validarse fácilmente (por ejemplo, un GUID).Luego, almacene sus datos serializados en el lado del servidor (en una base de datos, un archivo XML en el sistema de archivos o lo que sea) y recupérelos usando ese identificador.

Editar:Además, en este escenario, asegúrese de que su identificador sea lo suficientemente aleatorio como para que a los usuarios les resulte imposible adivinar los identificadores de los demás y hacerse pasar por otros simplemente cambiando un poco su propio identificador.Nuevamente, los GUID (o identificadores de sesión de ASP.NET) funcionan muy bien para este propósito.

Segunda edición después de la aclaración del escenario por parte del propietario de la pregunta:¿Por qué utilizar sus propias cookies en este caso?Si mantiene una referencia al objeto original o a su objeto liviano en el estado de sesión (objeto de sesión), ASP.NET se encargará de todos los detalles de implementación por usted de una manera bastante eficiente.

Answer 3

Mira en el Ver estado.Quizás desee conservar los datos en las devoluciones de datos en ViewState en lugar de utilizar cookies.De lo contrario, probablemente debería almacenar el XML en el servidor y un identificador único para esos datos en la cookie.

Answer 4

Podrías considerar usar Estado de sesión para almacenar el valor.Puede configurarlo para utilizar una cookie para almacenar la identificación de la sesión.Esto también es más seguro, porque el valor no es visible ni modificable por parte del usuario.

Otra alternativa es utilizar un mecanismo de almacenamiento en caché distribuido para almacenar el valor.Mi favorito actual es Memcached.