الخلاصة

  • يضع draft-ietf-httpapi-privacy-06 الحد الحاسم قبل استجابة 3xx: قد يرسل العميل مفتاح API أو Cookie أو bearer token في الطلب الواضح الأول قبل أن يرد الخادم.
  • تعمل HSTS وسجل HTTPS في DNS وإغلاق المنفذ 80 وقيد السياق الآمن والافتراض HTTPS-only في لحظات مختلفة؛ لا يثبت عنوان النهاية أن أياً منها حمى الطلب الأول.
  • إذا وصلت بيانات اعتماد عبر قناة غير مشفرة، يلزم رفض موحد لا يكشف صلاحيتها، ثم تصنيف الانكشاف واتخاذ قرار الإلغاء. وافق IESG على المسودة وأدخلها RFC Editor Queue، لكنها لم تكن RFC منشوراً في 1 أكتوبر 2026.

يمكن للحادث الأمني أن ينجح وظيفياً.

يُكتب عنوان الأساس http:// بدلاً من https://. تبني المكتبة طلباً موثقاً، وترسل السر، وتتلقى إعادة توجيه، ثم تعيد الطلب داخل TLS. يرى النظام نتيجة صحيحة ويحسب العملية ناجحة. أما من راقب الوصلة الأولى فقد حصل على السر قبل أن يبدأ التشفير.

تكمن قوة المراجعة 06 في ترتيبها الزمني. إعادة التوجيه استجابة، والاستجابة لا تأتي إلا بعد وصول طلب إلى جهة ما. تحمي جلسة HTTPS الثانية ما يليها، ولا تستطيع استدعاء البايتات التي مرت قبلها.

النجاح النهائي يمحو بداية القصة

في الويب الموجّه للبشر قد تكون إعادة التوجيه جسراً عملياً من اسم مضيف عارٍ إلى صفحة مشفرة. أما برنامج API فيملك URI مضبوطاً وسلطة قابلة لإعادة الاستخدام. لا يحتاج إلى المجاملة نفسها؛ يحتاج إلى فشل ظاهر قبل أن يُسلسل السر في نقل غير آمن.

بدأ الرصد الميداني في مايو 2024 من خطأ من حرف واحد، واختبر عدداً من الخدمات المعروفة آنذاك. تلك النتائج لقطة تاريخية وليست تعداداً لنشر الخدمات في 2026، وبعض السلوكيات تغيرت. لكن الآلية ثابتة: نجاح التكامل قد يخفي إرسال السر مرتين، مرة مكشوفة ومرة مشفرة.

لذلك يجب حفظ سلسلة إيصالات: URI المقصود، نتيجة DNS وسجل HTTPS، حالة HSTS المخزنة، أول اتصال فعلي، ما إذا كانت بايتات الاعتماد قد خرجت، أول استجابة، جلسة TLS التالية، قرار الانكشاف، الإلغاء، التفويض، ثم أثر العمل. لا يختصرها علم أخضر واحد.

آخر موعد للحماية يسبق أول إرسال

تمكّن HSTS في RFC 6797 المضيف من إلزام اتصالات مستقبلية آمنة، لكنها تُتعلم عبر اتصال HTTPS سابق وتعتمد على حفظ العميل للحالة. إرسال الخادم للرأس لا يثبت أن عميل API يحتفظ به مثل المتصفح.

تنقل سجلات HTTPS في RFC 9460 المعلومة إلى مرحلة اكتشاف الخدمة. مع ذلك، يجب على العميل أن يستعلم ويفسر، وقد يحجب من يسيطر على الطريق أو DNS الإجابة عن عميل جديد. الجمع بين السجل وHSTS يقلل الاحتمال ولا يصنع ضماناً مطلقاً.

إغلاق المنفذ 80 يمنع الخادم الحقيقي من استلام السر عبره. لكنه لا يمنع مهاجماً نشطاً من تقمص ذلك الخادم وقبول الاتصال. يبقى الضابط النهائي لدى العميل: لا تُرفق بيانات الاعتماد قبل اختيار نقل آمن.

يمكن أن تحمل بيانات الاعتماد قيداً ذاتياً. تمنع خاصية Secure في RFC 6265 إرسال Cookie عبر سياق غير آمن. ويوفر RFC 8959 صيغة secret-token للتعبير عن الاستخدام المتوقع. أما اسم حقل خاص مثل مفتاح API فلا ينفذ سياسة بمجرد دلالته البشرية.

403 علامة حادث وليست آلة زمن

حين يتعذر إغلاق HTTP، توصي المسودة بإرجاع 403 لكل طلب غير مشفر يحتوي بيانات اعتماد، سواء كانت صحيحة أم لا. يسمح RFC 9110 بالرفض لأسباب لا تتعلق بكفاية الاعتماد. اختلاف الرمز أو النص أو التوقيت بحسب الصحة يمنح المهاجم وسيلة لاختبار القيم.

الرفض الموحد لا يعيد السر. المفتاح أو bearer token المرسل مباشرة سلطة قابلة للنسخ، ولذلك ينبغي اعتباره معرضاً للاختراق. قد يكشف التوقيع أو MAC قيمة مشتقة لا السر الأصلي؛ عندها تُفحص تغطية الرسالة وnonce والربط وإمكان الإعادة بصورة مستقلة.

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

الموافقة على الوثيقة ليست دليلاً على التنفيذ

يسجل Datatracker الوثيقة ضمن مجموعة HTTPAPI وبهدف Best Current Practice. ويبين السجل التاريخي موافقة IESG وانتقالها إلى RFC Editor Queue في 5 يونيو 2026. في 1 أكتوبر بقيت المراجعة 06 المؤرخة 11 مايو بلا رقم RFC.

هذا دليل مراجعة مؤسسية، لا دليل التزام SDK بعينه. يذكر ملف shepherd عدم تقديم تقارير تنفيذ محددة. يوثق مستودع العمل تطور النص، لكنه لا يخبرنا بما يرسله عميل جديد على السلك.

ويضيف RFC 7258 سبباً أوسع: المراقبة الواسعة هجوم. حتى دون رمز سري، قد تنكشف المسارات والمعرفات والنية التشغيلية. وجود bearer token يجعل المراقبة قابلة للتحول إلى سلطة تنفيذ.

دفتر أدلة يبدأ من أول بايت

يُحفظ URI الدقيق، وإصدار المكتبة، وسياسة إعادة التوجيه، ووقت إرفاق الاعتماد، ومفتاح الوضع غير الآمن المنفصل، وDNS وHTTPS RR، ومصدر HSTS وعمره وحفظه، وأول scheme وعنوان ومنفذ وطرف، وفئة الاعتماد دون السر، وأول status وLocation، والطرف الموثق في TLS، وتصنيف الانكشاف، والحجر أو التدوير أو الإلغاء وانتشاره، والتفويض، ومعرف الالتزام، والنتيجة الخارجية.

لا يتحول الغياب إلى نجاح: hsts=none وhttps_rr=unavailable وexposure=possible وrevocation=pending حالات ضرورية. لا يجوز لمسار HTTPS النهائي أن يطغى على محاولة HTTP الأولى.

تدعم المواصفة الأولية الدنيا قاعدة مشتركة رفيعة: لا سر قابل لإعادة الاستخدام في نقل غير آمن. تطلب أولوية الشفرة العاملة فحص أول بايت حقيقي. تكشف مرآة السياسة سلطة الإعدادات الافتراضية. وتفصل طبقات الواقع بين الضبط والاكتشاف والانكشاف والاستجابة والتفويض والأثر.

المصادر