الخلاصة
- توفّر DNS Cookies حماية محدودة ومقصودة من التضخيم والتزوير وتسميم الذاكرة المؤقتة خارج المسار، عبر ربط طلب بعنوان مصدر وClient Cookie ورد سابق.
- لا يحدد Server Cookie صالح شخصاً أو جهازاً ثابتاً: فقد يشترك مستخدمون في عنوان NAT، ويستلزم تغيّر العنوان تدوير القيمة، ويمكن لمراقب على المسار إعادة استعمال قيمة مرئية خلال مدة صلاحيتها.
- يجب أن يحتفظ التشغيل بسياق العنوان والعمر وطريقة الكوكي ومجال تحقق anycast ونتيجة إعادة المحاولة، فيما تبقى الصلاحيات والفوترة والحصص الفردية مرتبطة بجهة مصادَقة مستقلة وموثّقة.
قد ترى لوحة تشغيل طلباً يحمل Server Cookie صالحاً فتسميه «موثّقاً». ثم تستنتج قاعدة لاحقة أن صاحب الطلب مشترك بعينه، أو تخفف حداً لمعدل الاستعلامات، أو تنسب تكلفة إلى حساب. الاختصار مفهوم: فالخادم أخرج قيمة صعبة التخمين ثم عادت إليه من العنوان المنتظر. لكن ذلك العنوان قد يكون بوابة NAT مشتركة لعشرات أو آلاف المستخدمين، أو مِحلِّلاً عودياً يمثل مؤسسة كاملة.
لا يعني هذا أن الكوكي بلا قيمة. إنه يجيب عن سؤال ضيق: هل توجد دلالة على أن عميلاً يستخدم Client Cookie هذا عند عنوان المصدر هذا قد تلقى سابقاً رداً يتضمن Server Cookie متوقعاً؟ تلك دلالة على مسار العودة وعلى تسلسل المعاملة، لا على اسم مستخدم أو حساب أو حق وصول. وكل قرار يحتاج إلى واحد من هذه الأشياء يجب أن يحصل على دليله من سطح تحكم آخر.
القيمة الصالحة تدعم قرينة لتبادل سابق
تصف RFC 9018 DNS Cookies كآلية أمن معاملات خفيفة ذات حماية محدودة من تضخيم الخدمة والتزوير وتسميم الذاكرة المؤقتة من مهاجم خارج المسار. كلمة «محدودة» ليست تحفظاً لغوياً: النموذج يفترض مهاجماً لا يرى التبادل بين الضحية المفترضة وخدمة DNS، ولذلك يضطر إلى تخمين قيمة لم يتلقها.
لا يؤدي الحقلان الدور نفسه. ينشئ العميل Client Cookie غير قابل للتنبؤ، ويستخدم قيمة مختلفة لكل عنوان IP لخادم مختلف؛ وتوصي RFC 9018 بـ64 بت من الإنتروبيا. هذه ليست بطاقة حساب يصدرها الخادم، بل قيمة ينشئها العميل وتظهر لاحقاً في الرد. أما Server Cookie فهو دليل العودة الذي ينتجه الخادم: يشبه MAC محسوباً من Client Cookie وعنوان IP للعميل وحقول محددة وسر لدى الخادم أو لدى مجموعة تتشارك عنوان anycast.
عندما يعود Server Cookie صالحاً في طلب جديد، يحصل الخادم على تأكيد ضعيف بأن عميلاً عند ذلك العنوان، وبذلك Client Cookie، تلقى رداً سابقاً. قد يكفي هذا لتغيير بعض دفاعات UDP ضد عنوان مصدر مزوّر. لكنه لا يثبت أن الطلب يخص حساباً، ولا أن له حق الاطلاع على مورد محمي، ولا أن الفاتورة ينبغي أن تصل إلى شخص بعينه.
عنوان NAT ليس مستخدماً
يجعل NAT الحد واضحاً فوراً. يستطيع كثير من المنازل أو الأجهزة أو التطبيقات الظهور لخادم DNS تحت عنوان عام واحد. وتقر RFC 9018 بأن العميل خلف NAT قد لا يكتشف تغيّر العنوان العام، بينما يستطيع الخادم رؤية عنوان جهاز NAT وربما تتبعه؛ ومنع ذلك التتبع خارج نطاق الوثيقة.
لذلك يمكن لـServer Cookie صالح أن يدعم قراراً عن إمكان العودة إلى ذلك العنوان العام من دون فصل من يشارك فيه. استخدامه كمفتاح لحصة «لكل شخص» يخلط مستخدمين مختلفين. واستخدامه كهوية للفوترة ينسب المسؤولية إلى خاصية شبكية مؤقتة لا تحملها.
وتنشأ المشكلة المعاكسة مع الحركة وعناوين الخصوصية. من أجل عدم تتبع جهاز بين العناوين، لا يجوز للعميل إعادة استخدام Client Cookie أو Server Cookie بعد تغير عنوان العميل؛ ويجب إنشاء Client Cookie جديد حين يكتشف ذلك. لذا لا تعني عملية تدوير الكوكي بالضرورة مستخدماً جديداً؛ قد تكون السلوك الصحيح لحماية الخصوصية. كما أن الاستمرار في رؤية القيمة نفسها لا يصنع هوية دائمة، فقد يعكس فقط عملية أو اتصالاً لم يتغير بعد.
BADCOOKIE ليس حكماً منفرداً على هجوم
للكوكي غير الصالح تفسيرات عدة متوافقة مع البروتوكول. تذكر RFC 7873 عمر القيمة، وتغير عنوان العميل أو Client Cookie، واختلاف إعداد مجموعة anycast، ومحاولة انتحال. في هذه الحالة يعالج الخادم الطلب كما لو أن Server Cookie غير الصالح غير موجود.
استجابة BADCOOKIE تنظّم الاسترداد، لا تعيّن المخالفة. يعيد العميل الطلب بالقيمة الجديدة التي وفرها الخادم. وإذا عاد BADCOOKIE مع الكوكي الجديد نفسه، يصبح اختلاف الأسرار أو الأساليب داخل مجموعة anycast فرضية معقولة، وتوصي المواصفة بالمحاولة عبر TCP. لا يكفي حدث واحد للتمييز بين الحركة أو الانتهاء الطبيعي أو انحراف النشر أو حركة معادية.
ينبغي أن يحتفظ سجل الحادث بتسلسل الوقائع: القيمة السابقة وعمرها، والعنوان الذي يراه كل جانب، وعضو anycast أو مجال التحقق، والقيمة الجديدة، ونتيجة إعادة المحاولة، ثم أي انتقال إلى TCP. تنبيه بعنوان «cookie غير صالح = هجوم» يلغي هذا المسار التشخيصي وقد يخفي تدويراً غير مكتمل للسر.
ضوابط DNS الأخرى لا تختفي
لا تحل DNS Cookies محل مطابقة الردود. تُلزم RFC 5452 المحلل بمطابقة عناوين المصدر والوجهة ومنفذ الوجهة ومعرّف الاستعلام والاسم والفئة والنوع قبل تطبيق قواعد الثقة، كما تتطلب منافذ مصدر ومعرّفات استعلام غير قابلة للتنبؤ. هذه الضوابط مكملة: كل واحدة منها ترفع كلفة الرد المزوّر من دون أن تصبح هوية تطبيقية.
وموضع الكوكي نفسه موضع معاملات. تعرّف RFC 6891 سجل OPT كحامل لمعلومات التحكم لتسلسل سؤال وجواب واحد؛ لا يحمل بيانات DNS ولا يجوز تخزينه مؤقتاً أو تمريره أو وضعه في ملفات رئيسية، وEDNS تفاوض قفزة بقفزة. لذلك COOKIE خيار للتبادل، لا بطاقة هوية يفترض أن تبقى في سجل مستخدم.
والحد أمام الخصم صريح أيضاً: يستطيع مراقب على المسار يرى DNS غير مشفر أن يلتقط Server Cookie ويعيد استخدامه ضد العميل خلال فترة صلاحيته. يمنع MAC مهاجماً خارج المسار لا يعرف سر الخادم من صنع قيمة حرة، لكنه لا يشفر الكوكي ولا يوثّق جميع من يستطيع الإرسال من المسار المرصود.
التسمية التشغيلية السليمة هي: «Server Cookie صالح لهذا العنوان المصدر وClient Cookie ومجال التحقق والوقت». فإذا احتاج الإجراء إلى هوية، يجب وصل إيصال DNS بجهة مصادقة موثقة مستقلة ودليل صريح على هذا الربط. الكوكي يقوّي نزاهة تسلسل المعاملة؛ ولا ينبغي أن يصبح سجلاً خفياً للأشخاص.
المصادر
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات