الخلاصة

  • يفحص Content-Digest محتوى الرسالة الفعلي، بينما يفحص Repr-Digest بيانات التمثيل المحدد كاملة. التطابق لا يحدد من اختار تلك البايتات.
  • يفصل السجل الصالح للقرار بين نطاق البايتات وسياسة الخوارزمية وإعادة الحساب وتغطية التوقيع وسلطة المفتاح والزمن ومنع الإعادة والتحقق المهني والفعل النهائي.

كانت الإشارة الخضراء صحيحة ضمن نطاق ضيق

أعادت الخدمة الحساب فوجدت القيمة نفسها. هذه نتيجة صحيحة، لكن الاستنتاج التالي لم يكن صحيحاً: لا تعني المساواة أن الملف مأذون بتنفيذه.

عندما يختار طرف واحد الجسم وقيمة الملخّص، لا يحتاج إلى مهاجمة SHA-256. يحسب تجزئة جسمه الخبيث ثم يرسل الاثنين. يكرر المستلم العملية ويحصل طبيعياً على النتيجة ذاتها. ثبت الاتساق بين مدخلين، ولم تثبت هوية صاحبهما.

لهذا تكون عبارة verified=true غامضة وخطرة. ينبغي أن يكتب النظام content_digest_matched أو signature_verified أو key_authorized. اسم النتيجة يحدد ما لا يجوز للدليل تجاوزه.

لا بد من تحديد البايتات قبل اختيار الخوارزمية

تعرّف RFC 9530 حقل Content-Digest لمحتوى رسالة HTTP المنقول فعلياً، وحقل Repr-Digest لبيانات التمثيل المحدد كلها. وقد تفصل بينهما ترميزات المحتوى والاستجابات الجزئية والطرائق وبيانات التمثيل الوصفية.

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

لذلك يأتي سؤال الثابت المطلوب قبل سؤال SHA-256 أو SHA-512: أهو المحتوى المنقول أم التمثيل الدلالي؟ وعلى أي جانب من الترميز أو إعادة البناء؟ وقد أبطلت RFC 9530 سابقتها RFC 3230 بعدما فُسرت كلمة «instance» بصورة متباينة، خصوصاً بين المحتوى وبيانات التمثيل.

صحة القاموس ليست وثيقة اعتماد

الحقلان قاموسان وفق Structured Fields؛ يحدد المفتاح خوارزمية التجزئة، وتحمل القيمة تسلسل بايتات الملخّص. ويمكن إدراج خوارزميات عدة لتسهيل الانتقال.

نجاح التحليل النحوي لا يقرر القبول. يحتاج المستلم إلى قائمة خوارزميات مسموحة وقاعدة للقيم المتعددة وقرار فشل واضح. يسجل سجل IANA حالة الخوارزميات، وتوصي RFC 9530 بالخوارزميات النشطة في استخدامات كثيرة وتحظر المتقادمة في السياقات التي قد يوجد فيها خصم.

أما Base64 فهو تمثيل للبايتات فقط. الترميز والتجزئة والتوقيع عمليات منفصلة. كذلك لا يفرض Want-Content-Digest أو Want-Repr-Digest التزاماً؛ فهما تفضيلات إرشادية يمكن تجاهلها. إن كان الملخّص إلزامياً فعلى سياسة التطبيق أن تقول ذلك.

توقيع الحقل لا يلغي إعادة حساب الجسم

تستطيع HTTP Message Signatures تغطية Content-Digest والطريقة والهدف وغيرها من المكونات المختارة. وعند تغطية الحقل ترتبط قيمته المعلنة بمفتاح تم التحقق منه.

لكن التوقيع لا يغطي الرسالة كاملة بصورة ضمنية. إن لم يكن الحقل ضمن مدخلات التوقيع فلا تمنح صحة التوقيع أي نتيجة عنه. وإن كان ضمنها، يبقى على المستلم حساب ملخّص المحتوى الذي استلمه فعلاً ومقارنته.

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

حتى التوقيع الصحيح لا يمنح التفويض. يجب معرفة هل المفتاح مسموح له بهذه العملية، وهل شملت التغطية العناصر اللازمة، وهل الزمن مقبول، وهل يمنع nonce أو غيره إعادة الطلب.

الحقل اللاحق يؤخر لحظة القرار

تسمح RFC 9530 بوضع الملخّص في الترويسة أو في الحقل اللاحق. يفيد الخيار الثاني عندما لا تُعرف النتيجة قبل نهاية البث، لكنه يعني أيضاً أن المستلم لا يملك الدليل كاملاً حتى النهاية.

إذا غيّر التطبيق الحالة أثناء القراءة ثم فحص الحقل اللاحق، فقد يصل الفشل بعد فعل لا رجعة فيه. يجب إبقاء البيانات في مرحلة مؤقتة أو معاملة قابلة للتراجع حتى تكتمل الفحوص.

تحمل HTTP/1.1 وHTTP/2 وHTTP/3 الحقول اللاحقة بطرائق مختلفة، وقد تحذفها الوسائط أو تعرضها الأطر البرمجية على نحو مختلف. الاختبار عبر المسار الإنتاجي هو الذي يثبت وصول الحقل قبل التنفيذ.

سلامة البايتات لا تمنحها حداثة

يمكن لنسخة مخبأة أن تحتفظ ببايتاتها وملخّصها الصحيح وهي قديمة. قواعد التخزين المؤقت في RFC 9111 هي التي تحكم الحداثة وإعادة التحقق واستعمال الرد القديم.

ويمكن إعادة طلب موقّع كما هو؛ يمر الجسم والملخّص والتوقيع مرة ثانية. النافذة الزمنية وnonce ومعرّف الطلب وسياسة عدم التكرار هي التي تقرر السماح بالتنفيذ الثاني.

المعنى له بوابة أخرى. قد يطابق الملف مخططه ويمنح صلاحيات خطرة، وقد يطابق البرنامج ملخّص ناشره ويحتوي ثغرة. تحافظ السلامة على الشيء المقدم ولا توافق على أثره.

الاختبار السلبي يرسم الحد

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

وقّع طلباً لا يغطي Content-Digest، ثم غط الحقل وبدّل الجسم. اختبر خوارزميات متعددة ومجهولة ومتقادمة كي لا يسمح ترتيبها بالتخفيض. مرر الطلب عبر الضغط والاستجابات الجزئية وإعادة بناء التمثيل.

وأرسل الحقل لاحقاً عبر كل نسخة HTTP ووسيط، وأعد طلباً صحيحاً، وقدّم نسخة مخبأة قديمة بملخّص مطابق. المطلوب نتائج منفصلة لكل بوابة، لا إشارة خضراء واحدة.