نقطة نهاية خطاف الويب هي حدود إدخال يمكن الوصول إليها خارجيًا. لا يعد نص JSON المعقول دليلاً على أن الموفر قد أرسله، ولا يثبت التوقيع الصالح بالضرورة أنه جديد. حماية منفصلة للنقل، ومصادقة الحمولة، ومعالجة إعادة التشغيل في كل من التصميم واختباراته.
تحقق من نظام التوقيع الفعلي للموفر
استخدم HTTPS وخوارزمية التوقيع الموثقة للموفر. احتفظ بنص الطلب الأولي للتحقق من التوقيع قبل تحليله أو تطبيعه. قم بتخزين السر في نظام سري معتمد وتجنب طباعته في السجلات. إذا فشل التحقق أو كان الرأس المطلوب مفقودًا، فارفض الإدخال دون تطبيق التأثير المطلوب.
دليل التحقق من صحة خطاف الويب الخاص بـ GitHub يوثق توقيع HMAC SHA-256 في X-Hub-Signature-256 ويوصي بإجراء مقارنة آمنة بدلاً من المساواة العادية. هذه حدود تنفيذ مرجعية ملموسة. قد يوقع مقدمو الخدمة الآخرون طوابع زمنية أو رؤوسًا محددة أو سلسلة أساسية مختلفة، لذا لا تنقل وصفة GitHub دون تغيير.
تعامل مع النضارة والهوية بشكل منفصل
أفضل ممارسات خطاف الويب لـ GitHub نوصي باستخدام X-GitHub-Delivery لتحديد عمليات التسليم ولاحظ أن إعادة التسليم المطلوبة تحتفظ بمعرف التسليم الأصلي. احتفظ بسجل إلغاء البيانات المكررة ضمن نطاق الاشتراك أو التثبيت ذي الصلة. يجب أن تؤدي عملية إعادة التسليم إلى إصلاح المعالجة، وليس إنشاء تذكرة ثانية أو تغييرها.
التوقيع الأساسي فقط لا يصادق على رؤوس التسليم العشوائية. يمكن للمهاجم الذي يعيد تشغيل وحدات البايت الموقعة التي تم التقاطها بمعرف تسليم غير موقع تم تغييره أن يتجنب إلغاء البيانات المكررة للمعرف فقط. كما أن الطابع الزمني غير الموقع ليس دليلاً على الحداثة. تعامل مع إرشادات معرف التسليم كعنصر تحكم واحد مع حدود الثقة هذه، وليس ضمان إعادة تشغيل التشفير. لا تخترع رأس الطابع الزمني الموقع على GitHub. عندما يقوم المزود بتوقيع طابع زمني، قم بالتحقق من صحته وفقًا للتسامح الموثق الخاص بالموفر تحديد العنوان القانوني قواعد. عندما لا يكون الأمر كذلك، فإن هوية التسليم وإلغاء البيانات المكررة الخاضعة للرقابة مهمان ولكن لهما حدود: قد لا يكون من الممكن التعرف على الحدث الذي يتم إعادة تشغيله بعد انتهاء صلاحية الاحتفاظ بالهوية. قم بإعداد وحفظ المستندات مع وضع هذا الخطر في الاعتبار.
قارن بين حالتين من حالات إعادة التشغيل
لنفترض أن تسليم GitHub الأصلي يحتوي على توقيع نصي صالح ومعرف تسليم تمت معالجته بالفعل. تحتفظ إعادة التسليم المطلوبة بهذا المعرف، مما يسمح للمستلم بالعثور على حالته المسجلة وتجنب تكرار التأثير. لنفترض الآن أن وحدات البايت الموقعة التي تم التقاطها تصل بمعرف تسليم مختلف غير موقع. لا يزال من الممكن نجاح عملية التحقق من النص لأن هذا الرأس يقع خارج النص الموقع؛ لا يعد إلغاء البيانات المكررة باستخدام المعرف فقط دليلاً تشفيريًا كافيًا للحداثة. هذه حالات تفكير افتراضية، وليست هجمات منفذة أو عمليات تسليم لمقدمي الخدمة.
بالنسبة للمرسل المتعاون الذي يقوم مخططه الموثق بتوثيق هوية الحدث والطابع الزمني مع الحمولة، والتلاعب بالاختبار، والطوابع الزمنية منتهية الصلاحية الموقعة بالفعل، والطوابع الزمنية المستقبلية خارج نطاق التسامح المسموح به والهويات المتكررة. لا تخترع مثل هذا المخطط لمزود لا يقدمه. لا يتم توفير مظروف مخصص أو مفتاح توقيع أو اختبار إعادة التشغيل هنا. قد تساعد بصمات الجسم الدقيقة في التحقيق في التكرارات، لكن الحمولات المتطابقة يمكن أن تمثل أيضًا أحداثًا مشروعة متميزة؛ تحديد الهوية التجارية وقواعد القبول بدلاً من التخلص العشوائي من جميع الهيئات المتساوية.
الحد من نتيجة حدث مقبول
بعد التحقق، تحقق من صحة نوع الحدث والإجراء والمخطط وتعيين المستأجر. قم بربط الاشتراك الموثوق بالمستأجر المقصود بدلاً من قبول معرف المستأجر التعسفي من الجسم. تقبل قائمة الانتظار العمل بهوية مستقرة وتحتفظ بتغييرات التكوين خلف حدود الموافقة العادية. يمكن لخطاف الويب الذي تمت مصادقته الإبلاغ عن حدث دون التصريح بتغيير DNS .
قم بتسجيل نتائج التحقق وهوية التسليم ووقت الاستلام ومرجع آمن للأدلة مع تقليل الاحتفاظ بالحمولة. توقف عن المعالجة عندما تكون حالة ارتباط المستأجر أو التوقيع غامضة. يجب أن يقوم الاسترداد بإعادة تشغيل الحدث الذي تم التحقق منه والذي تم الاحتفاظ به من خلال نفس المسار المحمي، وليس تجاوز التحقق من الصحة لمسح قائمة الانتظار. لا يتحقق هذا الدليل من تكامل EmailAuth webhook أو أي تسليم موفر حقيقي.