جوجل تنهي سرقة الجلسات وتطرح ميزة DBSC رسميًا لجميع مستخدمي كروم

مقدمة تحليلية

في 29 مايو 2026، أعلنت شركة Google عن الإطلاق الرسمي والمستدام لميزة Device Bound Session Credentials المعروفة اختصارًا بـ DBSC لجميع مستخدمي متصفح Chrome. هذا التحديث لا يمثل مجرد ميزة أمنية إضافية، بل هو إعادة صياغة جذرية لكيفية حماية الهوية الرقمية على الويب. تأتي هذه الخطوة بعد مرحلة تجريبية ناجحة بدأت في أبريل من العام نفسه، وتهدف بشكل أساسي إلى معالجة واحدة من أخطر الثغرات الأمنية في الفضاء الرقمي اليوم: سرقة جلسات العمل عبر ملفات تعريف الارتباط (Session Cookie Theft)، والتي تُعد الأداة المفضلة لدى المهاجمين لتجاوز بروتوكولات التحقق الثنائي (MFA) واختراق الحسابات الحساسة دون إثارة أي إنذارات أمنية. تدرك Google أن أنظمة المصادقة الحالية، مهما بلغت قوتها، تظل عرضة للفشل بمجرد خروج رمز الجلسة (Session Token) من نطاق جهاز المستخدم. من خلال تمكين DBSC افتراضيًا لجميع عملاء Google Workspace ومستخدمي الحسابات الشخصية، تسعى الشركة إلى سد هذه الثغرة نهائيًا. الأمر الأكثر أهمية هنا هو أن مديري الأنظمة (Administrators) في بيئات العمل لن يتمكنوا من تعطيل هذه الميزة، مما يوضح رغبة Google الصارمة في فرض معيار أمني موحد لا يقبل التنازل، والانتقال من وضع الدفاع القائم على الكشف والاستجابة إلى الوقاية الاستباقية المطلقة.

التحليل التقني

تعتمد آلية عمل تقنية Device Bound Session Credentials (DBSC) على مفهوم الربط التشفيري لجلسة المستخدم بقطعة عتاد مادية (Hardware-bound cryptography) موجودة داخل الجهاز نفسه. بدلاً من الاعتماد على ملفات تعريف ارتباط نصية يمكن نسخها ونقلها بسهولة، تقوم DBSC بالخطوات التالية:

• الاستفادة من رقاقات الأمان المدمجة في الأجهزة، مثل وحدة النظام الأساسي الموثوق به Trusted Platform Module (TPM) على الأجهزة العاملة بنظام التشغيل Windows، والـ Secure Enclave على أجهزة macOS.
• توليد زوج من المفاتيح التشفيرية الفريدة (مفتاح عام ومفتاح خاص Public/Private Key Pair) محليًا داخل رقاقة الأمان عند بدء جلسة جديدة.
• الاحتفاظ بالمفتاح الخاص (Private Key) بشكل آمن ومحمي تمامًا داخل رقاقة العتاد، بحيث يستحيل على أي برمجية خبيثة، حتى وإن كانت تمتلك صلاحيات مسؤول النظام، استخراجه أو قراءته.
• إرسال المفتاح العام (Public Key) إلى خوادم الهوية الخاصة بـ Google لتوثيق الجلسة وربطها بهذا المفتاح بالتحديد.
• تحدي المتصفح بشكل دوري لإثبات حيازته للمفتاح الخاص عبر توقيع تحديات تشفيرية (Cryptographic Challenges) لا يمكن فك رموزها إلا بواسطة الشريحة المادية للجهاز الأصلي.

هذا التصميم يغير قواعد اللعبة بالكامل. في السيناريوهات التقليدية، عندما تصاب الأجهزة ببرمجيات سرقة المعلومات (Infostealers)، تقوم هذه البرمجيات بالوصول إلى مجلد بيانات المتصفح، ونسخ ملفات تعريف الارتباط النشطة، وإرسالها إلى خوادم المهاجمين (C2). بمجرد حصول المهاجم على هذه الملفات، يمكنه زرعها في متصفحه الخاص والوصول الفوري إلى الحساب الضحية متجاوزًا كلمات المرور والمصادقة الثنائية. أما في بيئة مفعلة بها DBSC، فإن ملف تعريف الارتباط المسروق يصبح بلا أي قيمة تشفيرية بمجرد محاولة تشغيله على جهاز آخر، نظرًا لعدم قدرة جهاز المهاجم على تقديم التوقيع الرقمي المطلوب والمرتبط بشريحة TPM للجهاز الأصلي.

السياق وتأثير السوق

تأتي هذه الخطوة استجابة لتصاعد غير مسبوق في هجمات سرقة الجلسات التي تقودها عصابات الجريمة الإلكترونية المتخصصة في برمجيات سارقي المعلومات مثل Lumma وRhadamanthys وRedLine. في السنوات الأخيرة، استغل مطورو البرمجيات الخبيثة ثغرات معقدة ونقاط نهاية غير موثقة، مثل واجهة برمجة تطبيقات Google OAuth "MultiLogin"، لإعادة توليد ملفات تعريف ارتباط جديدة حتى بعد انتهاء صلاحية الملفات القديمة المسروقة، مما منحهم وصولاً دائمًا ومستمرًا لحسابات الضحايا. الردود السابقة من Google وشركات الأمن الأخرى كانت تركز على الجوانب السلوكية والتحذيرية، مثل نصح المستخدمين بتفعيل ميزة التصفح الآمن المحسن (Enhanced Safe Browsing) وإزالة البرامج الضارة يدويًا. ومع ذلك، أثبتت هذه الأساليب عدم كفايتها أمام التطور السريع لتقنيات الهندسة الاجتماعية والبرمجيات الخبيثة المتخفية. يمثل إطلاق DBSC نقلة نوعية تضع حدًا لهذه الفئة من الهجمات عبر تحويل حماية المتصفح من برمجية قابلة للاختراق إلى حماية مدعومة بالعتاد الصلب. هذا التطور سيجبر مطوري البرمجيات الخبيثة على إعادة النظر في نماذج عملهم، حيث ستفقد قواعد البيانات الضخمة لملفات تعريف الارتباط المسروقة والمعروضة للبيع في أسواق الويب المظلم (Dark Web) قيمتها التجارية بشكل كبير.

رؤية Glitch4Techs

من منظورنا التحليلي في Glitch4Techs، نرى أن مبادرة Google لطرح DBSC هي واحدة من أكثر الخطوات الأمنية تأثيرًا في هذا العقد، ولكنها لا تخلو من تحديات وسيناريوهات التفافية يجب الانتباه إليها. أولاً، النجاح الكامل لهذه التقنية يعتمد على جودة العتاد؛ فرغم أن معظم الحواسيب الحديثة مجهزة برقاقات TPM أو Secure Enclave، إلا أن الأجهزة الأقدم أو البيئات الافتراضية قد تواجه صعوبات في التوافق، مما يترك فجوات أمنية للمستخدمين الذين يعملون على عتاد متقادم. ثانيًا، يجب أن ندرك أن المهاجمين لن يستسلموا بسهولة. عندما تُغلق أمامهم ميزة سرقة ملفات تعريف الارتباط الثابتة، فإنهم سيتحولون حتمًا إلى تقنيات أكثر تعقيدًا مثل هجمات الخصم في المنتصف النشطة (Adversary-in-the-Middle - AiTM) أو استخدام برمجيات التحكم عن بعد (Remote Access Trojans - RATs) التي تتيح لهم تنفيذ العمليات مباشرة من داخل جهاز الضحية الفعلي وأثناء جلسته النشطة المصادق عليها بالفعل بـ DBSC. هذا يعني أن تقنية DBSC تحمي من تسريب الهوية ولكنها لا تمنع التحكم في الهوية إذا كان الجهاز نفسه مخترقًا بالكامل على مستوى نظام التشغيل. في النهاية، نتوقع في Glitch4Techs أن تصبح تقنية DBSC معيارًا صناعيًا مفتوحًا تتبناه متصفحات أخرى مثل Microsoft Edge وApple Safari ومطوري خوادم الويب الخارجيين. إن ربط الهوية الرقمية بالهوية المادية للجهاز هو المستقبل الحتمي للأمان الرقمي، وعلى المؤسسات البدء فورًا في تحديث بنيتها التحتية لدعم هذا المعيار وتقليل اعتمادها على المصادقة القائمة على البرمجيات وحدها.