بوابات الدفع الإقليمية مثل PayTabs وHyperPay وTelr، المنتشرة في دول الخليج ومصر والأردن، توقّع كل إشعار ويب هوك باستخدام HMAC-SHA256: يحصل التاجر على مفتاح سري عند إعداد التكامل، ويرافق كل إشعار وارد توقيع يجب إعادة حسابه محليًا ومقارنته بما وصل. إذا لم يتطابق التوقيع، فالإشعار لم يصل فعلًا من بوابة الدفع، ولا ينبغي التعامل معه كتأكيد دفع حقيقي.
لماذا نحتاج مفتاحًا سريًا لا مجرد تجزئة
التجزئة العادية مثل SHA-256 تثبت فقط أن البيانات لم تتلف أثناء النقل — لا من أرسلها. لو اكتفى الخادم بتجزئة محتوى الويب هوك ومقارنته بتجزئة مرفقة في الطلب، لاستطاع أي مهاجم تلفيق حمولة مزيفة وإرفاق تجزئة مطابقة. يحل HMAC هذه المشكلة بدمج مفتاح سري لا يعرفه سوى المرسل والمستقبل: بدونه يستحيل عمليًا إنتاج توقيع صحيح حتى لو عرف المهاجم بالضبط أي دالة تجزئة تُستخدم.
لماذا هذا ليس مجرد "تجزئة المفتاح زائد الرسالة"
ضمّ المفتاح والرسالة ببساطة قبل التجزئة (مثل hash(المفتاح + الرسالة)) عرضة لهجمات إطالة الطول في بعض دوال التجزئة — قد يتمكن المهاجم من إضافة بيانات وحساب تجزئة صحيحة جديدة دون معرفة المفتاح كاملًا. يستخدم HMAC بنية خاصة بتجزئة مزدوجة وحشو داخلي/خارجي تغلق هذا النوع من الهجمات بالكامل.
أين يظهر HMAC أيضًا
إلى جانب توقيع الويب هوك، يُستخدم HMAC لمصادقة طلبات API، وهو اللبنة الأساسية داخل خوارزمية TOTP — نفس الخوارزمية التي تولّد الرموز المكوّنة من ستة أرقام في تطبيقات المصادقة.
لماذا نحتاج هذا
- التحقق من صحة الويب هوك القادم من بوابات الدفع أو خدمات خارجية أخرى.
- توقيع طلبات API دون إرسال المفتاح السري نفسه عبر الشبكة أبدًا.
- فهم الآلية الداخلية لرموز TOTP ورموز الجلسات.
المقارنة في زمن ثابت
مقارنة التوقيع المستلَم بالمتوقَّع باستخدام عامل المساواة العادي === غير آمنة: هذا العامل يتوقف عادة عند أول بايت مختلف، ويكشف زمن المقارنة للمهاجم عدد البايتات الأولى التي خمّنها بشكل صحيح. معالجات الويب هوك الموثوقة تستخدم دائمًا دالة مقارنة بزمن ثابت — مثل hash_equals في PHP — تفحص كل بايت بصرف النظر عن موضع أول اختلاف.