بدأت Google إتاحة تقنية Device Bound Session Credentials (DBSC) للعامة لمستخدمي Windows على متصفح Chrome 146، بعد الإعلان عنها للمرة الأولى في أبريل 2024، على أن تتوسع إلى macOS في إصدار قادم من Chrome. تستهدف التقنية واحدة من أكثر مشكلات أمن الجلسات شيوعاً: سرقة ملفات الارتباط التي تتيح للمهاجمين الوصول إلى الحسابات من دون الحاجة إلى كلمات المرور.
تحدث سرقة الجلسات عادةً عندما يُنزّل المستخدم برمجية خبيثة من دون قصد. وبعد تشغيلها، تستطيع البرمجية استخراج ملفات الارتباط الحالية من المتصفح أو انتظار تسجيل المستخدم الدخول إلى حسابات جديدة، ثم إرسال هذه الرموز إلى خادم يسيطر عليه المهاجم. وتشير Google إلى أن عائلات برمجيات سرقة المعلومات، مثل LummaC2، أصبحت أكثر تطوراً في جمع بيانات الاعتماد.
وتزداد خطورة هذه الملفات بسبب امتداد فترة صلاحية بعضها؛ إذ يمكن للمهاجمين استخدامها للوصول غير المصرح به إلى الحسابات، ثم تجميعها أو تداولها أو بيعها بين الجهات الإجرامية. كما أن البرمجيات الخبيثة المتقدمة، بعد وصولها إلى الجهاز، تستطيع قراءة الملفات والذاكرة التي تخزن فيها المتصفحات ملفات ارتباط المصادقة. لذلك ترى Google أنه لا توجد طريقة موثوقة لمنع استخراج ملفات الارتباط بالاعتماد على البرمجيات وحدها، بصرف النظر عن نظام التشغيل.
ربط الجلسة بمفتاح لا يغادر الجهاز
تغيّر DBSC هذا النموذج من خلال ربط جلسة المصادقة تشفيرياً بجهاز محدد. وتستخدم التقنية وحدات أمان مدعومة بالعتاد، مثل وحدة النظام الأساسي الموثوق TPM في Windows وSecure Enclave في macOS، لإنشاء زوج فريد من المفاتيح العامة والخاصة. ولا يمكن تصدير المفتاح الخاص من الجهاز.
ولا يصدر الخادم ملفات ارتباط جديدة قصيرة العمر إلا بعد أن يثبت Chrome امتلاكه المفتاح الخاص المرتبط بالجلسة. وبما أن المهاجم لا يستطيع سرقة هذا المفتاح، فإن أي ملفات ارتباط يتم استخراجها سرعان ما تنتهي صلاحيتها وتصبح غير مفيدة للوصول إلى الحسابات. وتقول Google إنها رصدت انخفاضاً كبيراً في سرقة الجلسات المحمية بـDBSC منذ طرح نسخة مبكرة من البروتوكول خلال العام الماضي.
يمكن للمواقع، الكبيرة والصغيرة، تبني الجلسات المرتبطة بالعتاد عبر إضافة نقاط نهاية مخصصة للتسجيل والتحديث إلى أنظمتها الخلفية، مع الحفاظ على توافق الواجهة الأمامية الحالية. ويتولى المتصفح عمليات التشفير المعقدة وتدوير ملفات الارتباط في الخلفية، بينما يواصل تطبيق الويب استخدام ملفات الارتباط القياسية للوصول إلى خدماته.
حماية الجلسات من دون تتبع المستخدم
صُممت DBSC مع مراعاة الخصوصية. إذ تستند كل جلسة إلى مفتاح منفصل، ما يمنع المواقع من استخدام هذه الاعتمادات لربط نشاط المستخدم بين جلسات مختلفة أو بين مواقع متعددة على الجهاز نفسه. كما لا يرسل البروتوكول إلى الخادم معرفات الجهاز أو بيانات التصديق، باستثناء المفتاح العام الخاص بالجلسة واللازم لإثبات حيازة المفتاح الخاص.
وبحسب Google، يحد هذا التبادل من المعلومات من مخاطر استخدام التقنية للتتبع بين المواقع أو لبناء بصمة تعريفية للجهاز.
معيار مفتوح وتطوير مستمر
صُممت DBSC منذ البداية بوصفها معياراً مفتوحاً للويب من خلال مسار W3C واعتماد مجموعة عمل أمن تطبيقات الويب. وتعاونت Google مع Microsoft في تصميم المعيار، كما شاركت منصات ويب عديدة، من بينها Okta، في تجربتي Origin Trials خلال العام الماضي وقدمت ملاحظات استناداً إلى الاختبارات والاستخدام.
وتوفر Google للمطورين دليلاً للتنفيذ، إلى جانب مواصفات البروتوكول ومستودع GitHub وصفحة للإبلاغ عن الأخطاء أو اقتراح الميزات.
وتشمل مجالات التطوير المقبلة:
- تأمين الهوية الموحدة: توسيع DBSC لدعم الربط بين أصول مختلفة، بحيث تظل جلسة الطرف المعتمد مرتبطة بمفتاح الجهاز الأصلي المستخدم لدى مزود الهوية طوال عملية تسجيل الدخول الموحد.
- قدرات تسجيل متقدمة: ربط الجلسات بمواد مفاتيح موثوقة موجودة مسبقاً، مثل شهادات mTLS أو مفاتيح الأمان العتادية، بدلاً من إنشاء مفتاح جديد عند تسجيل الدخول.
- دعم أجهزة أوسع: دراسة إضافة مفاتيح قائمة على البرمجيات لحماية الأجهزة التي لا تتضمن عتاداً أمنياً مخصصاً.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.