تخزين بيانات XML في ملف تعريف الارتباط

Question

أحاول تخزين كائن XML متسلسل في ملف تعريف الارتباط، ولكن يظهر لي خطأ مثل هذا:

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

أعرف المشكلة من حالات مماثلة عندما تحاول تخزين شيء يشبه كود جافا سكريبت في حقل إدخال النموذج.

ما هي أفضل الممارسات هنا؟هل هناك طريقة (مثل مشكلة النموذج التي وصفتها) لقمع هذا التحذير من إطار عمل asp.net، أو هل يجب أن أقوم بإجراء تسلسل JSON بدلاً من ذلك أو ربما يجب أن أقوم بإجراء تسلسل ثنائي له؟ما الممارسة الشائعة عند تخزين البيانات المتسلسلة في ملف تعريف الارتباط؟

يحرر:شكرا على ملاحظاتك.السبب وراء رغبتي في تخزين المزيد من البيانات في ملف تعريف الارتباط أكثر من المعرف هو أن الكائن الذي أحتاجه حقًا يستغرق حوالي ثانيتين لاستعادته من خدمة ليس لدي سيطرة عليها.لقد قمت بإنشاء كائن خفيف الوزن "KundeContext" للاحتفاظ ببعض خصائص الكائن الكامل، ولكن يتم استخدام هذه الخصائص بنسبة 90% من الوقت.بهذه الطريقة لا يتعين علي سوى الاتصال بالخدمة البطيئة في 10% من صفحاتي.إذا قمت فقط بتخزين المعرف، فلا يزال يتعين علي الاتصال بالخدمة في جميع صفحاتي تقريبًا.

يمكنني تخزين جميع السلاسل والنصوص بشكل منفصل ولكن الكائن يحتوي على كائنات أخرى خفيفة الوزن مثل "معلومات الاتصال" و"العنوان" التي قد يكون من الصعب تخزينها يدويًا لكل خاصية من خصائصها.

Answer 1

لن أقوم بتخزين البيانات بتنسيق XML في ملف تعريف الارتباط - هناك حد لحجم ملف تعريف الارتباط للمبتدئين (كان 4K لـ الجميع الرؤوس بما في ذلك ملف تعريف الارتباط).اختر استراتيجية ترميز أقل تفصيلاً مثل المحددات بدلاً من ذلك، على سبيل المثال.a|b|c أو قيم ملفات تعريف ارتباط منفصلة.يجعل التشفير المحدد من السهل والسريع فك تشفير القيم.

الخطأ الذي تراه هو أن ASP.NET يشكو من أن الرؤوس تبدو وكأنها هجوم XSS.

Answer 2

يعد تخزين البيانات المتسلسلة في ملف تعريف الارتباط فكرة سيئة للغاية.وبما أن المستخدمين يتمتعون بالتحكم الكامل في بيانات ملفات تعريف الارتباط، فمن السهل جدًا عليهم استخدام هذه الآلية لتزويدك ببيانات ضارة.بعبارة أخرى: أي يصبح الضعف في رمز إلغاء التسلسل الخاص بك قابلاً للاستغلال على الفور (أو على الأقل وسيلة لتعطل شيء ما).

وبدلاً من ذلك، احتفظ فقط بأبسط معرف ممكن في ملفات تعريف الارتباط الخاصة بك، من النوع الذي يمكن التحقق من صحة تنسيقه بسهولة (على سبيل المثال، GUID).بعد ذلك، قم بتخزين جانب خادم البيانات المتسلسلة (في قاعدة بيانات، أو ملف XML على نظام الملفات، أو أي شيء آخر) واستردها باستخدام هذا المعرف.

يحرر:أيضًا، في هذا السيناريو، تأكد من أن المعرف الخاص بك عشوائي بما يكفي ليجعل من غير الممكن للمستخدمين تخمين معرفات بعضهم البعض، وانتحال شخصية بعضهم البعض ببساطة عن طريق تغيير المعرف الخاص بهم قليلاً.مرة أخرى، تعمل المعرفات الفريدة العمومية (أو معرفات جلسة ASP.NET) بشكل جيد جدًا لهذا الغرض.

التعديل الثاني بعد توضيح السيناريو من قبل صاحب السؤال:لماذا تستخدم ملفات تعريف الارتباط الخاصة بك على الإطلاق في هذه الحالة؟إذا احتفظت بمرجع إلى الكائن الأصلي أو الكائن الخفيف في حالة الجلسة (كائن الجلسة)، فسوف يعتني ASP.NET بجميع تفاصيل التنفيذ نيابةً عنك بطريقة فعالة جدًا.

Answer 3

انظر في حالة العرض.ربما ترغب في الاحتفاظ بالبيانات عبر عمليات إعادة النشر في ViewState بدلاً من استخدام ملفات تعريف الارتباط.بخلاف ذلك، ربما يتعين عليك تخزين ملف XML على الخادم ومعرفًا فريدًا لتلك البيانات في ملف تعريف الارتباط بدلاً من ذلك.

Answer 4

قد تنظر في استخدام حالة الجلسة لتخزين القيمة.يمكنك تكوينه لاستخدام ملف تعريف الارتباط لتخزين معرف الجلسة.وهذا أيضًا أكثر أمانًا، لأن القيمة ليست مرئية أو قابلة للتغيير من جانب المستخدم.

البديل الآخر هو استخدام آلية التخزين المؤقت الموزعة لتخزين القيمة.مفضلتي الحالية هي ميمكاشد.