جعلت المصادقة الثنائية وpasskeys سرقة كلمة المرور أقل حسمًا. لذلك اتجه المهاجمون إلى ما يحدث بعد تسجيل الدخول: جلسة المتصفح. قد تجعل session cookie مسروقة المجرم يبدو كأنه مصادق عليه أصلًا، حتى عندما يكون الحساب محميًا بقوة. لهذا تعد Device-Bound Session Credentials، أو DBSC، في Chrome خبرًا تقنيًا جيدًا بالمعنى العملي: ليست زرًا سحريًا، بل معالجة هندسية لثغرة حقيقية في البروتوكول والمتصفح والجهاز.

جلسة ويب مرتبطة بشريحة أمان في الحاسوب وتحدي من الخادم السياق الأخير جاء من تقرير Ars Technica، ومسودة W3C، وشرح WICG، ووثائق Google Workspace عن session binding لمنع cookie theft. الفكرة بسيطة: عندما ينشئ موقع مدعوم جلسة، يولد المتصفح مفتاحًا تشفيريًا ينبغي أن يبقى على الجهاز الأصلي. لاحقًا يستطيع الخادم طلب إثبات امتلاك هذا المفتاح. إذا نسخ infostealer ملف cookie إلى جهاز آخر، فلا ينبغي أن يكون cookie وحده كافيًا.

المشكلة

session cookie أداة راحة. بعد الدخول، لا يطلب الموقع كلمة المرور والعامل الثاني في كل صفحة. يرسل المتصفح cookie ويعدّه الخادم دليلًا على الجلسة نفسها. المشكلة أن هذا يشبه bearer token: من يحمله يستخدمه. تضيف DBSC شرطًا آخر: تحديث أو قبول بعض cookies يحتاج إلى إثبات من المتصفح بأنه ما زال يملك private key الخاص بتلك الجلسة.

هذا مهم لأن اقتصاد الهجوم تغير. التصيد بكلمات المرور ما زال موجودًا، لكن passkeys ومفاتيح الأمان وMFA القوية تجعله أقل موثوقية ضد الحسابات المهمة. سرقة الجلسة تتجاوز ذلك التقدم. malware والإضافات الخبيثة وأدوات adversary-in-the-middle والسجلات السيئة الحماية يمكن أن تحول متصفحًا مسجل الدخول إلى مصدر tokens. DBSC تخفض قيمة نسخ هذه tokens خارج الجهاز.

كيف تعمل ببساطة

يخبر الخادم المتصفح بتسجيل جلسة آمنة. ينشئ المتصفح زوج مفاتيح لتلك الجلسة. يحفظ private key، عندما يمكن، في مكون محمي داخل الجهاز. تشير مواد Chrome العامة إلى TPM في Windows، وتناقش التحليلات Secure Enclave على منصات Apple. قد يختلف التنفيذ، لكن الهدف واحد: ألا يكون المفتاح الخاص ملفًا عاديًا قابلًا للتصدير.

أثناء التسجيل والتحديثات اللاحقة، يوقع المتصفح challenge. لا يحتاج الخادم إلى هوية عتادية دائمة. يذكر نص WICG أن TPM certificate chain لا ترسل إلى الخادم لأنها تسمح بعملية fingerprinting دقيقة. ينبغي أن يعرف الخادم فقط أن هذا المتصفح ما زال يملك مفتاح الجلسة.

هذا ليس بديلًا لـpasskey. passkey تحمي فعل تسجيل الدخول. DBSC تحمي استمرار الجلسة بعد تسجيل الدخول. الطبقتان تتكاملان: واحدة تحمي الباب، والأخرى تقلل قيمة التصريح المسروق بعد عبور الباب.

لماذا هو تحسن حقيقي

كثير من إجراءات الأمان تعتمد على قرار المستخدم في أسوأ لحظة: لا تضغط الرابط، انتبه للنطاق المزيف، ارفض إشعارًا مريبًا. قوة DBSC أن الفحص الأساسي آلي. إذا كان لدى المهاجم cookie فقط، فليس لديه private key اللازم للرد على challenge من الخادم.

بالنسبة للشركات، قد يكون الأثر كبيرًا. جلسة مسروقة في بريد شركة أو CRM أو cloud console أو لوحة مالية أو أداة إدارة قد تفتح وثائق وبيانات عملاء وإعدادات. تعرض Google Workspace session binding كتحكم ضد cookie theft: الجلسة مفيدة على الجهاز المدار وأقل فائدة بكثير بعد نسخها. إذا انتشر النمط، تصبح عمليات infostealer أقل ربحية.

الحدود

DBSC لا تجعل malware على الجهاز نفسه غير مؤذية. يمكنها العمل عبر المتصفح الحقيقي، انتظار tokens جديدة، إساءة استخدام الإضافات، أو استخدام البيئة المحمية كـsigning oracle. يذكر WICG أن الوصول المستمر إلى user agent مخترق ليس شيئًا تمنعه DBSC بالكامل. الوعد الواقعي أضيق: وصول مؤقت لا ينبغي أن يتحول تلقائيًا إلى جلسة بعيدة طويلة بعد إزالة malware.

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

الخصوصية وfingerprinting

القلق من fingerprinting مشروع. هوية TPM أو Secure Enclave ثابتة على الويب ستكون خطرًا كبيرًا. تحاول مسودات DBSC تجنب ذلك: مفاتيح منفصلة للجلسات، وعدم قدرة المواقع على ربط مفتاحين بالجهاز نفسه، وعدم إرسال سلسلة شهادة TPM إلى الخادم. كما تقيد التحديثات الخلفية بسياق الطلب، وإمكانية الوصول إلى cookies، وحالة الموقع النشطة.

هذه الوعود تحتاج مراجعة مستمرة من موردي المتصفحات والباحثين والهيئات المعيارية. الخبر الجيد ليس الثقة العمياء في العتاد، بل أن التصميم العام يعترف بالخطر. الشروط المعقولة هي مفاتيح per-site أو per-session، وعدم تسريب hardware identity ثابتة، وضوابط مؤسسة واضحة، واسترداد مفهوم، ومراجعة مستقلة.

ماذا الآن

ذكرت Ars أن دعمًا ظهر في إصدارات حديثة من Chrome على Windows وmacOS، مع توافر محدود. يوضح WICG وW3C أن العمل ما زال ضمن التقييس، وليس قاعدة عامة لكل الويب. على المسؤولين متابعة وثائق Google Workspace، وسؤال الموردين عن session binding والسجلات والاسترداد والخصوصية، وتحديث خطط الاستجابة لسرقة الجلسات.

المستخدم العادي لا يحتاج إلى زر سحري. حافظ على تحديث المتصفح، واستمر في استخدام passkeys أو MFA قوية، واحذف الإضافات المشكوك فيها، وتعامل مع اختراق الجهاز بجدية. إذا نجحت DBSC، سيكون أفضل أثر هادئًا: cookies مسروقة أقل قابلية لإعادة الاستخدام، حلقات دخول أقل، وفشل افتراضي أكثر للمهاجم.

الخلاصة

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

المصادر

تقرير Ars Technica بقلم Dan Goodin في 11 أغسطس 2026؛ W3C Editor's Draft عن Device Bound Session Credentials؛ شرح WICG ومستودع DBSC؛ مساعدة Google Workspace حول session binding؛ تحليل Scott Helme؛ شرح Corbado عن DBSC وpasskeys وأمن الجلسات؛ Hacker News item 49268757 كنقاش حول TPM وSecure Enclave وpasskeys وfingerprinting.