Stocker des données XML dans un cookie

Question

J'essaie de stocker un objet sérialisé XML dans un cookie, mais j'obtiens une erreur comme celle-ci:

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

Je connais le problème dans des cas similaires lorsque vous essayez de stocker quelque chose qui ressemble à du code javascript dans un champ de saisie de formulaire.

Quelle est la meilleure pratique ici? Existe-t-il un moyen (comme le problème de forme décrit ci-dessus) de supprimer cet avertissement du framework asp.net, ou devrais-je plutôt sérialiser JSON ou plutôt binaire le sérialiser? Quelle est la pratique courante lors du stockage de données sérialisées dans un cookie?

EDIT: Merci pour les commentaires. La raison pour laquelle je veux stocker plus de données dans le cookie que l'ID est que l'objet dont j'ai vraiment besoin prend environ 2 secondes pour récupérer d'un service que je n'ai aucun contrôle sur. J'ai créé un objet léger 'KundeContext' pour contenir quelques propriétés de l'objet complet, mais celles-ci sont utilisées 90% du temps. De cette façon, je n'ai qu'à appeler le service lent sur 10% de mes pages. Si je ne stockais que l'identifiant, je devrais quand même appeler le service sur presque toutes mes pages.

Je pourrais stocker toutes les chaînes et toutes les entrées séparément, mais l'objet contient d'autres objets légers, tels que 'contactinformation' et 'address', qu'il serait fastidieux de stocker manuellement pour chacune de leurs propriétés.

Answer 1

Je ne stockerais pas de données au format XML dans le cookie - la taille du cookie pour les débutants est limitée (auparavant 4K pour tous les en-têtes, y compris le cookie). Choisissez une stratégie de codage moins détaillée, telle que des délimiteurs, par exemple. a | b | c ou séparer les valeurs de cookie. Le codage délimité rend le décodage des valeurs particulièrement facile et rapide.

L'erreur que vous voyez est ASP.NET, car les en-têtes ressemblent à une attaque XSS.

Answer 2

Stocker des données sérialisées dans un cookie est une très, très mauvaise idée. Puisque les utilisateurs ont un contrôle total sur les données des cookies, il est trop facile pour eux d’utiliser ce mécanisme pour vous envoyer des données malveillantes. En d'autres termes: toute faiblesse de votre code de désérialisation devient instantanément exploitable (ou au moins un moyen de bloquer quelque chose).

Au lieu de cela, ne conservez que l'identifiant le plus simple possible dans vos cookies, d'un type dont le format puisse être facilement validé (par exemple, un GUID). Ensuite, stockez vos données sérialisées côté serveur (dans une base de données, un fichier XML sur le système de fichiers ou autre) et récupérez-les à l'aide de cet identifiant.

Modifier: dans ce scénario également, assurez-vous que votre identifiant est suffisamment aléatoire pour que les utilisateurs puissent deviner les identifiants les uns des autres, et vous imiter vous-même en modifiant simplement un peu leur propre identifiant. Encore une fois, les GUID (ou identificateurs de session ASP.NET) fonctionnent très bien à cette fin.

Deuxième édition après clarification du scénario par le propriétaire de la question: pourquoi utiliser vos propres cookies dans ce cas? Si vous conservez une référence à l'objet d'origine ou à votre objet léger dans l'état de session (objet Session), ASP.NET se chargera de tous les détails de l'implémentation de manière très efficace.

Answer 3

Regardez dans le État d'affichage . Peut-être aimeriez-vous conserver les données dans les post-retours dans ViewState au lieu d'utiliser des cookies. Sinon, vous devriez probablement stocker le code XML sur le serveur et un identifiant unique pour ces données dans le cookie.

Answer 4

Vous pourriez envisager d'utiliser l'état de session pour stocker la valeur . Vous pouvez le configurer pour utiliser un cookie pour stocker l'identifiant de session. Ceci est également plus sûr, car la valeur n'est ni visible ni modifiable par l'utilisateur.

Une autre alternative consiste à utiliser un mécanisme de mise en cache distribué pour stocker la valeur. Mon favori actuel est Memcached .