الخلاصة

  • تلزم RFC 9111 الذاكرة المخبأة التي ترى استجابة بلا خطأ لطلب غير آمن بإبطال URI الهدف، لكن هذا الواجب يطبق على الذواكر التي مر بها الطلب.
  • الادعاء بتطهير عالمي يحتاج إلى دليل مستقل على تغطية المسارات، وهويات URI المرتبطة، والمفاتيح المشتقة داخل التطبيق.

لنتصور حادثة افتراضية بوضوح. يرسل عميل طلب PUT، فيعيد الخادم الأصلي 204 No Content، وتعلن لوحة التحكم فوراً اكتمال التطهير العالمي. مرّت الكتابة عبر ذاكرة تطبيق مخبأة وبوابة إقليمية واحدة. ومع ذلك، تواصل نقطة طرفية خارج مسار الطلب تقديم صفحة مجموعة بُنيت من الكائن القديم. لا تكشف الاستجابة 204 تلك النقطة ولا المفتاح المشتق الخاص بالمجموعة.

ليست هذه ثغرة في HTTP، بل حد فاصل بين قاعدة بروتوكول وادعاء تشغيلي. تعرف RFC 9110 الطريقة الآمنة بأن دلالتها المحددة للقراءة أساساً، وتعد GET وHEAD وOPTIONS وTRACE طرقاً آمنة. أما الطرق القادرة على تغيير الحالة فتعامل بصورة مختلفة. تنص RFC 9111 على أن الذاكرة المخبأة يجب أن تمرر الطلب غير الآمن إلى الخادم الأصلي، ولا يجوز لها إنشاء استجابة قبل تمرير الطلب وتلقي الرد المقابل.

تنشئ الاستجابة بعد ذلك واجباً محدداً. عندما تتلقى الذاكرة المخبأة استجابة بلا خطأ لطريقة غير آمنة، يجب أن تبطل URI الهدف. وتعني «بلا خطأ» هنا حالة من فئة 2xx أو 3xx. قد يعني الإبطال إزالة الاستجابات المخزنة المطابقة، أو وسمها بأنها غير صالحة بحيث تصبح إعادة التحقق إلزامية قبل استخدامها. تمنع القاعدة إعادة الاستخدام من دون فحص جديد؛ ولا تشهد باختفاء كل نسخة في النظام.

تسمح RFC 9111 أيضاً بإبطال URI أخرى. وقد تكون قيم Location وContent-Location مرشحة إذا شاركت URI الهدف أصلها. هذه صلاحية مفيدة، لكنها ليست آلية شاملة لاكتشاف التبعيات. لا يجوز للذاكرة المخبأة أن تبطل، بموجب هذه القاعدة، URI مرشحاً من أصل مختلف. كما لا يلزمها استنتاج كل صفحة منتج أو قائمة أو نتيجة بحث أو جزء محسوب مسبقاً أو مفتاح بديل اشتقه التطبيق من الكائن المعدل.

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

ينشأ الخطأ من دمج ثلاث عبارات. «قبل الخادم الأصلي الكتابة» عبارة عن الاستجابة. «أبطلت ذاكرة مرّ بها الطلب URI الهدف» عبارة عن فعل محلي مطلوب. «سيرى كل قارئ الحالة الجديدة» عبارة عن الطوبولوجيا واشتقاق المفاتيح والتحقق. لا تثبت الأولى تحقق الثانية في كل طبقة، ولا تكفي العبارتان لإثبات الثالثة.

يمكن سد الفجوة بإيصال لمسار الإبطال. هذا تركيب رقابي تحريري نقترحه هنا، وليس كائناً يعرفه IETF. يربط الإيصال الطلب غير الآمن واستجابته بنسخ الذاكرة التي حملتهما؛ ويسجل URI الهدف بعد توحيده وفعل الإبطال المحلي؛ ويميز بين إبطال الهدف الإلزامي ومعالجة Location أو Content-Location الاختيارية؛ ويرفق خريطة التطبيق للقوائم والبحث والأجزاء والمفاتيح البديلة؛ ويحفظ نتائج اختبارات تتجاوز الذاكرة المخبأة من كل مسار تقديم مهم.

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

المصادر