ملفات تعريف ارتباط الجلسة: لماذا يصبح الدفاع مدعوماً بالعتاد

كيف تجاوزت سرقة الجلسات الدفاعات القديمة

طوال العقد الماضي، كانت ملفات تعريف الارتباط البطن الرخوة لهوية الويب. أي مهاجم يثبت برنامج infostealer مثل RedLine أو Lumma أو StealC على نقطة طرفية يستطيع تسريب ملفات تعريف ارتباط المصادقة بهدوء وإعادة استخدامها من أي جهاز، متجاوزاً كلمات المرور ومعظم عوامل MFA. تقرير CrowdStrike العالمي 2026 ومذكرة Google Threat Intelligence Group في فبراير 2026 حول التصيد المدعوم بالذكاء الاصطناعي يرصدان أن سرقة الجلسات عبر infostealer تظل من أسرع نواقل الاختراق نمواً، مع تقلص breakout time واحترافية أسواق الجلسات المسروقة.

الدفاعات التقليدية ترد بعد الحدث. كشف الشذوذ، سمعة IP، قطع الجلسات من قبل مزودي الهوية: كلها تستجيب لإساءة استخدام جارية. تغير DBSC هذا النمط بربط الجلسة ذاتها بمفتاح تشفيري غير قابل للتصدير، محفوظ في عتاد الجهاز الأصلي.

ما يفعله DBSC على مستوى البروتوكول

Device Bound Session Credentials مسودة W3C طُورت داخل Web Application Security Working Group، مع Google وMicrosoft كمصممَين رئيسَين، وOkta كمشارك مبكر من جانب الهوية. حين يبدأ خادم جلسة، يولّد المتصفح زوج مفاتيح عام-خاص داخل العتاد الآمن: Trusted Platform Module على Windows أو Secure Enclave على macOS. المفتاح الخاص لا يغادر هذه الحدود العتادية أبداً. بشكل دوري، يتحدى الخادم المتصفح لإثبات حيازته للمفتاح الخاص، ويوقّع المتصفح التحدي باستخدام مادة TPM.

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

نشر Chrome 146 ونطاقه

شحن Chrome 146 ميزة DBSC إلى Windows 10 إصدار 1903 وأحدث، وكل أنظمة Windows 11 المزودة بـ TPM 2.0 أو عتاد متوافق مع Windows Hello. تشير Google إلى أن هذا النطاق يغطي حوالي 85% من تثبيتات Windows Chrome النشطة. دعم macOS مقرر لإصدار Chrome لاحق عبر Secure Enclave، وتستكشف Google تخزين المفاتيح برمجياً كبديل للأجهزة التي لا تملك عتاداً آمناً مخصصاً.

لمسؤولي Workspace، أصدرت Google ميزة beta مرتبطة هي “Prevent cookie theft with session binding”، تتيح لمسؤولي المؤسسات اشتراط جلسات محمية بـ DBSC لتسجيل دخول Google Workspace. في الاختبارات الداخلية وorigin trials السابقة، أبلغت Google عن انخفاض ملموس في سرقة الجلسات على خصائصها، وتذكر The Hacker News رقماً يبلغ 94% من محاولات السرقة المحبوطة في سيناريوهات محكومة.

ما لا يحله DBSC

DBSC ضابط قوي، لكنه ليس إجابة كاملة لإساءة استخدام الاعتمادات. يحمي فقط الجلسات التي تختارها كل من المتصفح والخادم، ما يعني أن الفائدة الواسعة تعتمد على تحديث مزودي الهوية ومنصات SaaS والبنوك لإدارة جلساتهم. التصيد الذي يلتقط الاعتمادات قبل وجود أي جلسة لا يتأثر. والبرمجية الخبيثة التي تختطف عملية المتصفح الجارية، بدلاً من تسريب ملفات تعريف الارتباط، يمكنها أن تنشط داخل الجلسة الشرعية ما دام المستخدم متصلاً. وهجمات remote-control حيث يقود المهاجم جهاز الضحية تتجاوز البروتوكول كلياً.

لذلك يُفهم DBSC طبقةً ضمن دفاع متعدد الطبقات يشمل أيضاً MFA المقاوم للتصيد القائم على FIDO2 وWebAuthn، وكشف نقطة طرفية يركز على سلوك infostealer، وتقليص فترات الجلسات للإجراءات الحساسة.

ما يجب أن تفعله فرق الهوية الآن

خارطة الطريق العملية لعام 2026 من أربع خطوات. أولاً، جرد التطبيقات SaaS والداخلية التي تكشف ملفات تعريف ارتباط طويلة العمر، وأي منها يدعم بالفعل FIDO2 أو WebAuthn لإعادة المصادقة على الإجراءات الحساسة. ثانياً، تتبع إعلانات دعم DBSC من كبار مزودي الهوية، إذ يحدد اعتماد Okta وMicrosoft Entra وGoogle Workspace وPing مدى انتشار الحماية. ثالثاً، تشديد وضع نقاط النهاية ضد infostealers، لأن نموذج التهديد يفترض أن البرمجية الخبيثة قد تكون موجودة. رابعاً، تجريب beta Workspace لربط الجلسات أو ضوابط مكافئة على شريحة محدودة قبل أي تطبيق واسع.

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

ما ينبغي لفرق الهوية فعله الآن

اعتماد النظام البيئي لـ DBSC سيستغرق 12-24 شهراً. هذا الوقت ليس مبرراً للانتظار — بل فرصة لإنجاز العمل التأسيسي الذي يجعل الدفاع القائم على العتاد فعالاً حين يصل. الإجراءات الأربع التالية تبني قيمة أمنية متراكمة بصرف النظر عن موعد توفير مزودي الهوية لدعم DBSC.

1. جرد ملفات تعريف الارتباط للجلسات طويلة الأمد وتقليصها الآن

أكثر تقليل للمخاطر متاح فوراً لا يستلزم أي أدوات جديدة. دقِّق كل تطبيق داخلي وSaaS في تكوينات مهلة الجلسة وحدِّد أيها يُصدر ملفات تعريف ارتباط بمدة أكثر من 8 ساعات. وفقاً لتقرير CrowdStrike العالمي للتهديدات 2026، انخفض الوقت الوسيط بين سرقة ملف تعريف ارتباط infostealer وأول محاولة إعادة استخدام دون 4 ساعات — بمعنى أن ملف ارتباط بمدة 24 ساعة هو عملياً نافذة تحرك جانبي مدتها 24 ساعة لمهاجم حصل على الجهاز. تقليص جلسات التطبيقات عالية الامتيازات إلى 4 ساعات أو أقل يُغلق نافذة الإعادة دون أي تعديلات على مستوى المتصفح. لتطبيقات الخدمات المصرفية والرواتب، 30-60 دقيقة مع إعادة مصادقة على الإجراءات الحساسة هو المعيار المناسب.

2. تسجيل أجهزة Windows في سياسات بيانات اعتماد مدعومة من TPM قبل وصول DBSC

يغطي Chrome 146 نحو 85% من تثبيتات Windows Chrome النشطة المزودة بـ TPM 2.0. قبل أن يُوفر مزود الهوية لديك دعم DBSC، استخدم البنية التحتية ذاتها لـ TPM من أجل ضبط مختلف لكنه مجاور: اشترط أن تمتلك أجهزة Windows التي تصل إلى التطبيقات الحساسة شهادة صحة TPM صالحة عبر سياسات امتثال device لـ Microsoft Entra أو التحقق من endpoint لـ Google BeyondCorp. هذا يُرسّخ نموذج ثقة الجهاز الذي سيمتده DBSC لاحقاً إلى طبقة الجلسة. المؤسسات التي تتخطى ثقة الجهاز اليوم ستواجه خطوتين للتكامل حين يصل DBSC؛ تلك التي تُطبّقه الآن ستواجه خطوة واحدة فقط.

3. تشديد دفاعات نقاط النهاية ضد عائلات infostealers التي تستهدف مصنّفات المتصفح

يُلغي DBSC قيمة إعادة استخدام ملفات تعريف الارتباط المسروقة، لكن فقط للجلسات المسجَّلة. البرمجيات الخبيثة مثل Lumma وRedLine وStealC لا تتخصص في سرقة ملفات تعريف الارتباط فحسب — بل تستخرج أيضاً كلمات مرور محفوظة وبطاقات ائتمان مخزَّنة في المتصفح وملفات محلية. يُعرّف كل من تقرير CrowdStrike العالمي للتهديدات 2026 ومجموعة Google Threat Intelligence هذه الفئة من البرمجيات الخبيثة بوصفها أسرع متجه وصول أولي نمواً. قواعد EDR التي تستهدف تحديداً استخراج مصنّفات المتصفح — وصول عملية غير مألوف إلى مخزن ملفات تعريف الارتباط أو مخزن بيانات الاعتماد في المتصفح — تُقلص نافذة ما بين الإصابة والكشف بصرف النظر عن اعتماد DBSC.

4. تتبع إعلانات دعم DBSC كمعلم إصدار لا كأخبار خلفية

Okta وMicrosoft Entra وGoogle Workspace هم مزودو الهوية الثلاثة الذين سيحدد دعمهم لـ DBSC ما إذا كانت غالبية جلسات المؤسسات ستستفيد من الربط القائم على العتاد. راقب ملاحظات إصدار الأمان وسجلات تغييرات المطورين لكل مزود للبيانات الخاصة ببيانات دعم DBSC — لا الإعلانات التسويقية. حين يُوفر مزود دعم DBSC، تكون نافذة ترحيل مستأجري المؤسسات عادةً 60-90 يوماً. فرق الهوية التي أنجزت جرد الجهاز وقلّصت مدد الجلسات (الخطوتان 1 و2) ستتمكن من تفعيل الجلسات المحمية بـ DBSC في الأسبوع الذي تُطلَق فيه الميزة. مستودع GitHub لمواصفة DBSC التابع لـ W3C Web Application Security Working Group هو المصدر المرجعي لتتبع مراجعات البروتوكول.

الأسئلة الشائعة

المصادر والقراءات الإضافية

• Protecting Cookies with Device Bound Session Credentials — Google Online Security Blog
• Chrome ships device-bound session credentials — Help Net Security
• Google Rolls Out DBSC in Chrome 146 — The Hacker News
• Device Bound Session Credentials — W3C Web Application Security WG
• 2026 CrowdStrike Global Threat Report — CrowdStrike