--- url: 'https://www.corbado.com/ar/blog/device-bound-session-credentials-dbsc' title: 'شرح Device Bound Session Credentials (DBSC)' description: 'تعرف على كيفية منع Device Bound Session Credentials (DBSC) لاختطاف الجلسة وسرقة ملفات تعريف الارتباط. تعرف على حالة دعم المتصفح وأمان المؤسسات.' lang: 'ar' author: 'Vincent Delitz' date: '2026-06-15T13:57:06.365Z' lastModified: '2026-06-16T06:06:12.030Z' keywords: 'Device Bound Session Credentials, DBSC, منع اختطاف الجلسة, حماية سرقة ملفات تعريف الارتباط, ربط جلسة TPM' category: 'Authentication' --- # شرح Device Bound Session Credentials (DBSC) **حالة دعم المتصفح** > **الأحدث (أبريل 2026):** يطلق Chrome 146 > [DBSC في التوفر العام على نظام Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)، > لينقل الميزة من مرحلة التجربة الأصلية (Origin Trial). دعم نظام macOS (باستخدام > [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) قادم في إصدار Chrome القادم. أعلنت Google > أيضاً عن خارطة طريق عامة للهوية الموحدة (ارتباطات الدخول الموحد (SSO) عبر الأصول)، > والتسجيل المتقدم (mTLS / مفاتيح الأجهزة)، والمفاتيح المستندة إلى البرامج للأجهزة التي لا > تحتوي على أجهزة أمان. | المتصفح | Windows | macOS | Linux | Android | iOS | الحالة | | ----------- | ------------------------------ | ------------------------ | --------------- | --------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ متوفر عام (Chrome 146، TPM) | 🚧 قادم (Secure Enclave) | ❌ | ❌ | ❌ | [متوفر عام على Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (أبريل 2026)، macOS في إصدار قادم | | **Edge** | ⏸️ انتهت التجربة | ❌ | ❌ | ❌ | ❌ | انتهت التجربة الأصلية في أكتوبر 2025، لم يتم الإعلان عن التوفر العام | | **Safari** | غير متوفر | 🔄 قيد التقييم | غير متوفر | غير متوفر | 🔄 قيد التقييم | WebKit قيد المناقشة، لم يتم الإعلان عن التنفيذ | | **Firefox** | 🔄 قيد المراقبة | 🔄 قيد المراقبة | 🔄 قيد المراقبة | 🔄 قيد المراقبة | 🔄 قيد المراقبة | قيد التقييم، لا يوجد التزام بالتنفيذ | **الأسطورة:** ✅ متوفر بشكل عام | 🚧 معلن / قيد التطوير | ⏸️ انتهت التجربة | 🔄 قيد التقييم/المراقبة | ❌ غير متوفر بعد **ملاحظة:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) متوفر بشكل عام على نظام Windows مع TPM اعتباراً من Chrome 146 (أبريل 2026). يتم حالياً طرح دعم macOS عبر [Secure Enclave](https://www.corbado.com/glossary/secure-enclave). تتضمن خارطة طريق Google المعلنة أيضاً مفاتيح مستندة إلى البرامج لتوسيع الحماية للأجهزة التي لا تحتوي على أجهزة أمان مخصصة. **المزايا الرئيسية: DBSC مقابل النموذج الحالي** | **الميزة** | **نموذج ملف تعريف الارتباط الحالي** | **نموذج DBSC** | | -------------------- | ------------------------------------- | -------------------------------------------- | | **نوع الرمز المميز** | حامل (الامتلاك = الوصول) | مرتبط (الامتلاك + المفتاح = الوصول) | | **عواقب السرقة** | الاستيلاء الكامل على الحساب | رمز مميز عديم الفائدة (لا يمكن تحديثه) | | **مدة الجلسة** | قصيرة (للأمان) | طويلة / غير محدودة (آمنة حسب التصميم) | | **احتكاك المستخدم** | مرتفع (تسجيل دخول متكرر) | منخفض (أمان غير مرئي) | | **تجاوز MFA** | عرضة للخطر (تمرير ملف تعريف الارتباط) | مقاوم (الجهاز مطلوب) | | **الإبطال** | بطيء (انتظار انتهاء الصلاحية) | في الوقت الفعلي تقريباً (فشل التحديث التالي) | ## Key Facts - يربط **DBSC** جلسات الويب بمفتاح تشفير محفوظ في الجهاز، مما يجعل ملفات تعريف الارتباط المسروقة عديمة الفائدة لأنه لا يمكن تحديثها من جهاز آخر. - يخزن المتصفح مفتاحاً خاصاً غير قابل للتصدير في **TPM**، ويوقع تحديات الخادم كل 5 دقائق لإثبات امتلاك الجهاز دون تفاعل المستخدم. - على عكس **ربط الرمز المميز (Token Binding)**، الذي فشل بسبب تعقيد البنية التحتية لطبقة TLS، يعمل DBSC في طبقة تطبيق HTTP ويعمل بشفافية مع موازنات الأحمال الحالية وشبكات CDN. - **يطلق Chrome 146 ميزة DBSC للتوفر العام على نظام Windows (أبريل 2026)**، مع دعم macOS Secure Enclave القادم في إصدار قادم. تغطي خارطة طريق Google المنشورة أيضاً الهوية الموحدة (ارتباطات SSO عبر الأصول)، والتسجيل المتقدم (mTLS / مفاتيح الأجهزة)، والمفاتيح المستندة إلى البرامج للأجهزة التي لا تحتوي على أجهزة أمان. لا يزال متصفحا Safari وFirefox قيد التقييم؛ وانتهت التجربة الأصلية لمتصفح Edge في أكتوبر 2025 دون الإعلان عن التوفر العام. ## 1. مقدمة: شرح Device Bound Session Credentials (DBSC) تأسست بنية الشبكة العالمية للمعلومات (الويب) على مبدأ انعدام الحالة (statelessness). عندما تم تصميم HTTP لأول مرة، لم يكن يحتفظ بمعلومات حول المستخدمين بين الطلبات. لحل ذلك، تم اختراع "ملف تعريف الارتباط" (cookie) - وهو جزء صغير من البيانات يتم إرساله من موقع الويب وتخزينه على كمبيوتر المستخدم، ليتم إرساله مرة أخرى إلى موقع الويب مع كل طلب لاحق. لعقود من الزمن، كانت هذه الآلية بمثابة الأساس لإدارة الجلسات. عندما يقوم المستخدم بتسجيل الدخول، يتحقق الخادم من بيانات الاعتماد الخاصة به ويصدر ملف تعريف ارتباط. يعمل ملف تعريف الارتباط هذا كـ "رمز مميز للحامل" (bearer token). في العالم المادي، أداة الحامل هي مستند يمنح حامله الحقوق أو الأصول التي يمثلها؛ إذا كنت تحمل السند، فأنت تملك السند. وبالمثل، في العالم الرقمي لبروتوكول HTTP، إذا كنت تحمل ملف تعريف الارتباط، فأنت المستخدم. تعتبر قدرة الحامل هذه في نفس الوقت أكبر فائدة للويب وأعمق نقاط ضعفه. يعتمد أمان الجلسة بأكملها - وبالتالي هوية المستخدم وبياناته وأصوله المالية - كلياً على سرية سلسلة ملف تعريف الارتباط هذه. إذا تمكن جهة ضارة من نسخ تلك السلسلة، فيمكنها انتحال شخصية المستخدم من أي جهاز في أي مكان في العالم، متجاوزة عمليات التحقق من المصادقة الأولية تماماً. أدت هذه الثغرة الأمنية المحددة إلى ظهور اقتصاد سري على مستوى صناعي لـ "سرقة ملفات تعريف الارتباط" و "اختطاف الجلسة". مع نجاح الصناعة في تعزيز أمان "الباب الأمامي" للمصادقة من خلال اعتماد معايير FIDO (الهوية السريعة عبر الإنترنت) ومفاتيح المرور، يحول المهاجمون تركيزهم إلى "الباب الخلفي": الجلسة النشطة. أصبح تصيد كلمة المرور أكثر صعوبة، لكن سرقة ملف تعريف ارتباط الجلسة تظل فعالة بشكل خطير. تتمثل استجابة الصناعة لهذا التهديد المتصاعد في **Device Bound Session Credentials (DBSC)**. يمثل [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) تحولاً نموذجياً في كيفية الحفاظ على جلسات الويب. ويقترح الانتقال بعيداً عن الرموز المميزة البسيطة للحامل نحو نموذج تكون فيه الجلسة [مرتبطة تشفيرياً بالجهاز](https://www.w3.org/TR/dbsc/). مع [إطلاق Chrome 146 (أبريل 2026) لـ DBSC في التوفر العام على نظام Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)، انتقل المعيار من إمكانية تجريبية إلى إمكانية إنتاج يمكن لفرق الويب نشرها اليوم. يستخدم Chrome وحدات TPM على نظام Windows ويقوم بطرح دعم لـ Secure Enclave على macOS تالياً؛ والمواصفات نفسها محايدة بخصوص تخزين المفاتيح، حيث تتطلب فقط أن تكون "قوية ضد التهديد الموصوف." هذا يجعل ملفات تعريف الارتباط المسروقة أقل قيمة بكثير. لا يمكن تحديثها من جهاز آخر بدون المفتاح المرتبط. تقدم هذه المقالة تحليلاً شاملاً لـ [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc)، مصمماً لمهندسي الأمان ومديري المنتجات والمطورين. وتستكشف البنية التقنية، والآثار التجارية لـ "الأمان بدون احتكاك"، والعلاقة مع المعايير الناشئة مثل الإشارات المشتركة (CAEP/RISC)، وكيف يمكن للمؤسسات الاستعداد لهذا المستقبل باستخدام منصات مثل Corbado. **الأسئلة الرئيسية التي تجيب عليها هذه المقالة** 1. لماذا تفشل إدارة الجلسات الحالية في منع الاستيلاء على الحسابات؟ 2. كيف يختلف DBSC عن ملفات تعريف الارتباط "الآمنة" (Secure) الحالية وعلامات HttpOnly؟ 3. كيف يعمل DBSC ومفاتيح المرور معاً لمقاومة أقوى للتصيد الاحتيالي؟ 4. ماذا حدث لربط الرمز المميز (Token Binding)، ولماذا ينجح DBSC حيث فشل؟ 5. ما هي الآثار التجارية وعائد الاستثمار لمديري المنتجات؟ 6. ما هي المتصفحات وأنظمة التشغيل التي تدعم DBSC اليوم؟ 7. كيف يمكن للمؤسسات تنفيذ DBSC دون البناء من الصفر؟ 8. ما هي العلاقة بين DBSC وDPoP و[OAuth 2.0](https://www.corbado.com/glossary/oauth2)؟ 9. كيف يتكامل DBSC مع الإشارات المشتركة (CAEP/RISC) للاستجابة للتهديدات في الوقت الفعلي؟ ## 2. فهم المشاكل والحلول الأساسية للتنقل عبر تعقيدات هذا المعيار الجديد، يجب أن نفهم أولاً المشاكل الأساسية في إدارة الجلسات الحالية وكيف يقدم DBSC حلولاً لها. يمثل كل مجال من هذه المجالات ثغرة أمنية حرجة أو قيداً يعالجه DBSC. ### 2.1 فشل إدارة الجلسة الحالية الفشل الأساسي لإدارة الجلسة الحالية هو "قابلية نقل" الثقة. عندما يصدر الخادم ملف تعريف ارتباط لجلسة، فإنه في الأساس يصدر جواز سفر يعمل لأي شخص يحمله. بينما قامت المتصفحات بتنفيذ دفاعات مثل [علامات HttpOnly و Secure](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (التي تمنع وصول JavaScript وتضمن النقل عبر HTTPS)، إلا أن هذه الدفاعات تحمي فقط ضد نواقل استخراج معينة مثل البرمجة عبر المواقع (XSS) أو استنشاق الشبكة. وهي لا توفر أي حماية ضد البرامج الضارة التي تعمل على الجهاز المضيف. "سارقو المعلومات" (Infostealers) هم برامج ضارة مصممة خصيصاً لـ تحديد موقع ملف تخزين ملف تعريف الارتباط للمتصفح على القرص، وفك تشفيره (غالباً باستخدام بيانات اعتماد مستوى نظام التشغيل الخاصة بالمستخدم نفسه)، وتسريب المحتويات إلى خادم قيادة وسيطرة. بمجرد أن يمتلك المهاجم ملف تعريف الارتباط، يمكنه إجراء [هجوم تمرير ملف تعريف الارتباط](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)، عن طريق إدخال الرمز المسروق في متصفحه الخاص لاختطاف الجلسة. يفترض الخادم، عند رؤية ملف تعريف ارتباط صالح، أن الطلب شرعي. ### 2.2 ميزة التشفير لـ DBSC على ملفات تعريف الارتباط الآمنة التقليدية يقدم DBSC عاملاً ثانياً للمصادقة في حلقة صيانة الجلسة نفسها. على عكس ملف تعريف الارتباط الآمن القياسي، وهو سر ثابت، تتكون جلسة DBSC من رمز مميز للحامل قصير الأجل وإثبات تشفيري للامتلاك. ينشئ المتصفح زوج مفاتيح (عام/خاص) يتم تخزينه بأمان على الجهاز. يربط الخادم الجلسة بالمفتاح العام. بشكل دوري، يجب أن يثبت المتصفح أنه لا يزال يحتفظ بالمفتاح الخاص من خلال توقيع تحدي من الخادم. تتطلب [المواصفات تخزين المفاتيح](https://www.w3.org/TR/dbsc/) بحيث تكون "قوية ضد التهديد الموصوف". يستخدم Chrome تقنية TPM على نظام Windows عند توفرها. إذا قام مهاجم بسرقة ملف تعريف الارتباط من جهاز مختلف، فلن يتمكن من تحديثه لأنه لا يستطيع إنشاء التوقيع التشفيري المطلوب. يتم تقليل جانب "الحامل" إلى نافذة قصيرة جداً، بينما يوفر جانب "الربط" استمرارية طويلة الأمد. ### 2.3 التآزر بين مفاتيح المرور و DBSC مفاتيح المرور و DBSC هما تقنيتان متكاملتان تؤمنان مراحل مختلفة من دورة حياة المستخدم. تحل مفاتيح المرور (FIDO2) مشكلة _المصادقة_ من خلال إثبات الهوية لبدء جلسة بدون كلمات مرور، وبالتالي القضاء على تصيد بيانات الاعتماد. يعالج DBSC مشكلة _ما بعد المصادقة_ مما يجعل اختطاف الجلسة عبر سرقة ملف تعريف الارتباط أصعب بكثير. يؤطر [تحالف FIDO تقنية DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) كتقنية تكميلية "ترفع المستوى" ضد اختطاف الجلسات. معاً، يقللان من سطح الهجوم عبر دورة حياة تسجيل الدخول والجلسة، على الرغم من أن DBSC لا يحمي من البرامج الضارة ذات الوصول المستمر للجهاز أو هجمات الرجل في المتصفح في الوقت الفعلي على نفس الجهاز. | التقنيات | التصيد الاحتيالي عن بُعد | حشو بيانات الاعتماد | سرقة الرموز المميزة | | ------------------------------- | ------------------------ | ------------------- | ------------------- | | **مفاتيح المرور** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **مفاتيح المرور + DBSC / DPoP** | ✅ | ✅ | ✅ | **كيف تعمل مفاتيح المرور و DBSC معاً** | **الجانب** | **مفاتيح المرور** | **DBSC** | **الفائدة المجمعة** | | ------------------ | --------------------------------------- | ---------------------------------------------- | --------------------------------------------------- | | **النطاق** | المصادقة (تسجيل الدخول) | إدارة الجلسة | حماية شاملة من البداية للنهاية | | **التهديد المخفف** | تصيد كلمات المرور، حشو بيانات الاعتماد | اختطاف الجلسة عن بُعد، سرقة ملف تعريف الارتباط | رفع مستوى الحماية بشكل كبير ضد الاستيلاء على الحساب | | **تجربة المستخدم** | تسجيل الدخول بدون كلمة مرور | حماية شفافة للجلسة | تجربة سلسة وآمنة | | **تخزين المفاتيح** | مرتبطة بالجهاز أو بيانات اعتماد متزامنة | مرتبطة بالجهاز (HSM عند توفرها) | مصادقة مرنة، ربط صارم للجلسة | | **النشر** | تحل محل كلمات المرور | تحسين الجلسات الحالية | تحسينات أمنية تدريجية | ### 2.4 التعلم من فشل Token Binding ليست DBSC هي المحاولة الأولى لحل هذه المشكلة. كان "Token Binding" (ربط الرمز المميز) معياراً سابقاً حاول ربط ملفات تعريف الارتباط باتصال TLS (أمان طبقة النقل) الأساسي. بينما كان سليماً من الناحية التشفيرية، فشل Token Binding في كسب التبني بسبب اعتماده الكبير على طبقة TLS. في الويب الحديث، غالباً ما يتم إنهاء اتصالات TLS في موازنات الأحمال أو شبكات CDN أو الوكلاء العكسيين، بينما يقع منطق التطبيق في الخوادم خلفها. ثبت أن نشر معلومات Token Binding عبر طبقات الشبكة المعقدة هذه كان صعباً للغاية. يتعلم DBSC من هذا الفشل عن طريق [العمل بالكامل في طبقة التطبيق (HTTP)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). لا يعتمد على اتصال الشبكة الأساسي، مما يجعله متوافقاً مع موازنات الأحمال والوكلاء والبنية التحتية السحابية الحالية. ### 2.5 الآثار التجارية وفرص عائد الاستثمار بالنسبة لقادة المنتجات، يوفر DBSC فرصة لتحسين الأمان مع تحسين تجربة المستخدم (UX) في نفس الوقت. تقليدياً، يعني الأمان العالي انتهاء صلاحية الجلسة لفترات قصيرة، مما يجبر المستخدمين على تسجيل الدخول بشكل متكرر (احتكاك). من خلال ربط الجلسة بالجهاز، يتم تقليل خطر سرقة ملف تعريف الارتباط _عن بُعد_ بشكل كبير. يمكن للشركات التفكير في فترات جلسة أطول، مع العلم أن ملفات تعريف الارتباط المسروقة لا يمكن تحديثها من جهاز آخر. ومع ذلك، لا تحمي DBSC من سرقة الجهاز أو البرامج الضارة المستمرة على الجهاز أو الإساءة من قبل مستخدم ضار، لذلك يجب أن تعكس سياسات عمر الجلسة هذه المخاطر المتبقية. ## 3. مشهد التهديد: تصنيع سرقة ملفات تعريف الارتباط لفهم الحاجة الملحة وراء DBSC، يجب على المرء أن يدرك مدى تعقيد مشهد التهديد الحديث. تخرجت سرقة ملفات تعريف ارتباط الجلسات من خدعة قراصنة متخصصة إلى صناعة قابلة للتطوير ومؤتمتة. ### 3.1 صعود سارقي المعلومات ```mermaid graph TD A[المستخدم ينزل
برمجيات خبيثة] -->|تنفيذ| B[تنشيط برنامج سرقة المعلومات
على الجهاز] B --> C[يحدد موقع بيانات المتصفح] C --> D[تخزين ملفات تعريف الارتباط
لـ Chrome/Edge/Firefox] C --> E[قاعدة بيانات كلمات المرور] C --> F[محافظ التشفير] D --> G[يفك التشفير باستخدام
بيانات اعتماد نظام التشغيل] E --> G F --> G G --> H[ينشئ ملف سجل
بالبيانات المسروقة] H --> I[يسرب إلى خادم C2] I --> J[سوق الويب المظلم] J --> K[المهاجم يشتري السجل] K --> L[يستورد ملف تعريف الارتباط إلى
متصفحه الخاص] L --> M[يتجاوز المصادقة متعددة العوامل MFA] M --> N[اكتمل
الاستيلاء على الحساب] style A fill:#ff6b6b,color:#fff style B fill:#ff6b6b,color:#fff style N fill:#ff6b6b,color:#fff style J fill:#495057,color:#fff style M fill:#ffd43b,color:#000 ``` أدت البرامج الضارة كخدمة (MaaS) إلى خفض حاجز الدخول لمجرمي الإنترنت. "سارقو المعلومات" (Infostealers) مثل RedLine و Raccoon و Vidar و Taurus هي سلالات برامج ضارة متاحة تجارياً مصممة بهدف أساسي واحد: استخراج البيانات من متصفحات الويب. يتم توزيع أدوات السرقة هذه عبر رسائل التصيد الاحتيالي، أو البرامج المقرصنة، أو الإعلانات الضارة. بمجرد تثبيتها، فإنها تستهدف مسارات الملفات المحددة حيث تخزن متصفحات مثل Chrome وEdge وFirefox بياناتها. - **الهدف:** قاعدة بيانات ملفات تعريف الارتباط (عادةً ملف [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide)) وقاعدة بيانات بيانات تسجيل الدخول (كلمات المرور المحفوظة). - **الآلية:** تقوم المتصفحات بتشفير قواعد البيانات هذه باستخدام واجهات برمجة تطبيقات حماية البيانات (DPAPI على Windows) المرتبطة بتسجيل دخول المستخدم لنظام التشغيل. نظراً لأن البرامج الضارة تعمل _بصفة المستخدم_، يمكنها بسهولة طلب فك تشفير هذه الملفات. - **المخرجات:** تولد البرامج الضارة "سجلاً" (log) - وهو ملف مضغوط يحتوي على ملفات تعريف الارتباط التي تم فك تشفيرها، وكلمات المرور، ومعلومات النظام، وأحياناً مفاتيح محافظ التشفير. ### 3.2 سوق "السجلات" يتم تجميع هذه السجلات وبيعها في [الأسواق](https://www.corbado.com/passkeys-for-e-commerce) على الويب المظلم مثل سوق التكوين (Genesis Market) (قبل إغلاقه) والسوق الروسية (Russian Market). يمكن للمشترين البحث عن سجلات تحتوي على ملفات تعريف ارتباط نشطة لأهداف عالية القيمة محددة: "Salesforce" أو "Gmail" أو "Bank of America" أو "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console". **التجاوز:** تكمن قيمة سجل ملف تعريف الارتباط في قدرته على تجاوز المصادقة متعددة العوامل (MFA). تحدث معظم تحديات [MFA](https://www.corbado.com/ar/blog/passkey-fallback-recovery) (الرسائل القصيرة، TOTP، الإشعارات المباشرة) فقط أثناء حدث _تسجيل الدخول_. بمجرد إنشاء الجلسة وإصدار ملف تعريف الارتباط، يفترض الخادم أن المستخدم موثوق به. إن إدخال المهاجم لملف تعريف ارتباط صالح للجلسة [ينزلق مباشرة عبر بوابة MFA](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc)، ويظهر للخادم كالمستخدم الذي يعود إلى علامة تبويب نشطة. ### 3.3 تهديد Google Workspace و Microsoft Entra تعتبر حزم الإنتاجية السحابية أهدافاً رئيسية. يمكن أن يمنح ملف تعريف ارتباط جلسة مسروق لـ Google Workspace أو حساب Microsoft Entra ID (المعروف سابقاً باسم Azure AD) المهاجم إمكانية الوصول إلى البريد الإلكتروني للشركة والمستندات والأنظمة الداخلية. أبلغت [معلومات التهديدات الخاصة بشركة Google](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) عن زيادة هائلة في سرقة ملفات تعريف الارتباط كناقل أساسي للوصول إلى حسابات Google، حيث سمته صراحةً كمحرك لاستثمارها في DBSC. ويشيرون إلى أنه عندما يفرضون تمكين التحقق بخطوتين (2SV) ومفاتيح المرور، فقد غيّر المهاجمون تكتيكاتهم ببساطة من تصيد بيانات الاعتماد (والذي يوقفه [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / مفاتيح المرور) إلى سرقة ملفات تعريف الارتباط (والتي لا يوقفها [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / مفاتيح المرور في الغالب). ### 3.4 حدود "البصمة الرقمية للجهاز" تاريخياً، حاولت محركات المخاطر اكتشاف سرقة الجلسات من خلال تحليل البصمات الرقمية للجهاز، والنظر إلى سلسلة وكيل المستخدم (User-Agent)، ودقة الشاشة، والخطوط المثبتة، وعنوان IP. إذا ظهر ملف تعريف ارتباط جلسة فجأة من عنوان IP جديد ببصمة مختلفة قليلاً، فقد يقوم الخادم بإبطاله. **المشكلة:** تعمل مبادرات الخصوصية في المتصفحات (مثل منع التتبع الذكي في Safari وPrivacy Sandbox في Chrome) بنشاط على تقليل إنتروبيا هذه البصمات لـ وقف تتبع الإعلانات. هذا يجعل أخذ البصمات "الجيدة" لأغراض الأمان صعباً بشكل متزايد. علاوة على ذلك، يستخدم المهاجمون الآن متصفحات "مضادة للاكتشاف" تتيح لهم تزييف هذه البصمات بشكل مثالي لتتطابق مع الملف الشخصي للضحية، مما يجعل الكشف الإرشادي غير فعال. يستبدل DBSC لعبة التخمين الاحتمالية هذه بإثبات تشفيري حتمي. ## 4. البنية التقنية: كيف يعمل DBSC يقدم [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) [واجهة برمجة تطبيقات وبروتوكول قياسي](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) لإنشاء جلسات مرتبطة بمفتاح على جهاز العميل. تتطلب المواصفة أن يكون تخزين المفاتيح "قوياً ضد التهديد الموصوف" لكنها غير محددة بشأن التنفيذ. يستخدم Chrome تقنية TPM على Windows عند توفرها. يفصل هذا القسم الآليات كما هو محدد في مسودة عمل W3C ووثائق Chrome. ### 4.1 المكونات الأساسية | **المكون** | **الوصف** | **الدور في DBSC** | | --------------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **وكيل المستخدم (المتصفح)** | تطبيق العميل (Chrome وEdge وما إلى ذلك). | يدير زوج المفاتيح، ويتعامل مع تفاعل HSM، ويعترض طلبات الشبكة لإرفاق الأدلة. | | **الطرف المعتمد (الخادم)** | تطبيق الويب (مثل بوابة الخدمات المصرفية). | يصدر التحديات، ويتحقق من التوقيعات، ويدير دورة حياة الجلسة. | | **تخزين المفاتيح** | التخزين الآمن (TPM، Secure Enclave، أو غيره) | يخزن المفتاح الخاص. يستخدم Chrome تقنية TPM على نظام Windows عند توفرها؛ المواصفة غير محددة بشأن آلية التنفيذ. | | **ملف تعريف ارتباط الجلسة** | ملف تعريف ارتباط HTTP قياسي. | يُستخدم كرمز حامل، ولكن بعمر افتراضي قصير جداً (مثلاً 5-10 دقائق). | | **إثبات الحيازة** | توقيع تشفيري. | JWT يرسله المتصفح لإثبات أنه لا يزال يمتلك المفتاح الخاص. | ### 4.2 دورة حياة بروتوكول DBSC تسمح دورة حياة DBSC بانتقال سلس من جلسة قياسية إلى جلسة مرتبطة، مما يضمن التوافق مع الإصدارات السابقة والتحسين التدريجي. ```mermaid sequenceDiagram participant User participant Browser participant HSM as HSM (TPM/Secure Enclave) participant Server Note over User,Server: المرحلة 1: المصادقة والربط User->>Browser: تسجيل الدخول ببيانات الاعتماد/مفتاح المرور Browser->>Server: طلب المصادقة Server->>Browser: نجاح + ترويسة تسجيل DBSC Browser->>HSM: إنشاء زوج مفاتيح HSM->>Browser: مفتاح عام/خاص (خاص غير قابل للتصدير) Browser->>Server: تسجيل المفتاح العام (JWT موقع) Server->>Server: ربط الجلسة بالمفتاح العام Server->>Browser: ملف تعريف ارتباط قصير الأجل (5 دقائق) Note over User,Server: المرحلة 2: الاستخدام العادي loop كل طلب خلال 5 دقائق Browser->>Server: طلب بملف تعريف الارتباط Server->>Browser: استجابة end Note over User,Server: المرحلة 3: التحديث (بعد انتهاء الصلاحية) Browser->>Server: طلب بملف تعريف ارتباط منتهي الصلاحية Server->>Browser: 401 + رقم تحدي Browser->>HSM: توقيع التحدي HSM->>Browser: توقيع Browser->>Server: إثبات التوقيع Server->>Server: تحقق باستخدام المفتاح العام المخزن Server->>Browser: ملف تعريف ارتباط قصير الأجل جديد Browser->>Server: إعادة محاولة الطلب الأصلي Server->>Browser: استجابة بالنجاح ``` #### 4.2.1 المرحلة 1: البدء والربط تبدأ عملية الربط فور مصادقة المستخدم باستخدام طرق قياسية (كلمة المرور، مفتاح المرور، وما إلى ذلك). 1. **إشارة الخادم:** عند تسجيل الدخول بنجاح، يقوم الخادم بتعيين ملف تعريف ارتباط الجلسة (كالمعتاد) ولكنه يضيف ترويسة محددة تشير إلى دعم DBSC. ``` HTTP HTTP/1.1 200 OK Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register" ``` - تخبر ترويسة Secure-Session-Registration المتصفح: "أنا أدعم خوارزميات ES256 و RS256. يرجى تسجيل جلسة مرتبطة في نقطة النهاية /auth/dbsc/register." 2. **إنشاء المفتاح:** يحلل المتصفح هذه الترويسة. ويولد زوج مفاتيح غير متماثل جديد (مثل، Elliptic Curve P-256)، مخزناً بأمان على الجهاز. - **ملاحظة التنفيذ:** يستخدم Chrome تقنية TPM على نظام Windows عند توفرها؛ المواصفة محايدة بخصوص آلية التخزين، وتتطلب فقط أن تكون "قوية ضد التهديد الموصوف." - **نطاق الخصوصية:** يتم تحديد نطاق المفتاح لأصل الويب (مثل bank.com). يضمن المتصفح عدم استخدام هذا المفتاح مطلقاً لـ retailer.com، مما يمنع التتبع عبر المواقع. 3. **طلب التسجيل:** يرسل المتصفح طلباً إلى مسار التسجيل المحدد. يتضمن هذا الطلب **المفتاح العام** المولد حديثاً داخل JSON Web Token (JWT)، موقعاً بواسطة المفتاح الخاص (تصديق موقع ذاتياً). ``` HTTP POST /auth/dbsc/register HTTP/1.1 Content-Type: application/jwt \.\.\ ``` 4. **ربط الجلسة:** يتحقق الخادم من التوقيع للتأكد من أن المفتاح العام يعمل. ثم يقوم بتحديث قاعدة البيانات الخاصة به لربط جلسة المستخدم (session_id=xyz123) بهذا المفتاح العام المحدد. من هذه اللحظة فصاعداً، تصبح الجلسة "مرتبطة". #### 4.2.2 المرحلة 2: حلقة ملف تعريف الارتباط قصير الأجل لتحقيق التوازن بين الأمان والأداء (يمكن أن تضيف عمليات المفاتيح الآمنة زمن انتقال)، يستخدم DBSC نظاماً مزدوج الرموز. 1. **الإصدار:** يصدر الخادم ملف تعريف ارتباط _جديد_، قصير الأجل (على سبيل المثال، صالح لمدة 5 دقائق). لنطلق على هذا access_token. 2. **الاستخدام:** يستخدم المتصفح هذا الـ access_token لجميع الطلبات العادية (جلب الصور، مكالمات API، التنقل بين الصفحات). طالما كان ملف تعريف الارتباط صالحاً، لا يتم تنفيذ أي عمليات تشفيرية. يضمن هذا بقاء التصفح سريعاً. 3. **انتهاء الصلاحية:** بعد 5 دقائق، تنتهي صلاحية access_token. #### 4.2.3 المرحلة 3: التحديث (إثبات الحيازة) هذا هو قلب الآلية الأمنية. عندما تنتهي صلاحية ملف تعريف الارتباط قصير الأجل، يتم منع مهاجم على جهاز مختلف، ولكن يمكن للمستخدم الشرعي (الذي لديه حق الوصول إلى المفتاح المرتبط) الاستمرار. 1. **الاكتشاف:** يحاول المتصفح إجراء طلب. يلاحظ أن ملف تعريف الارتباط قد انتهت صلاحيته (أو أن الخادم يرجع 401 أو ترويسة Secure-Session-Challenge محددة). 2. **الاعتراض:** يقوم المتصفح _بإيقاف_ طلب الشبكة مؤقتاً. ولا يظهر أي خطأ للمستخدم. 3. **طلب التحديث:** يستدعي المتصفح نقطة نهاية التحديث المحددة في تكوين الجلسة تلقائياً. - يرسل الخادم **تحدي** تشفيري (رقم عشوائي nonce). - يستخدم المتصفح المفتاح المرتبط لتوقيع هذا التحدي. - يثبت التوقيع امتلاك المفتاح الخاص. 4. **التقديم:** يرسل المتصفح التحدي الموقع مرة أخرى إلى الخادم. ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **التحقق من الصحة:** يستخدم الخادم المفتاح العام المخزن للتحقق من التوقيع. - _إذا كان صالحاً:_ يعرف الخادم أن الطلب قادم من نفس الجهاز المادي الذي بدأ الجلسة. ويصدر access_token قصير الأجل _جديد_ (صالح لمدة 5 دقائق أخرى). - _إذا كان غير صالح:_ يتم رفض الطلب. ويتم إنهاء الجلسة. 6. **الاستئناف:** يأخذ المتصفح ملف تعريف الارتباط الجديد ويعيد محاولة الطلب الأصلي المتوقف مؤقتاً بشفافية. الـ [مستخدم لا يعاني من أي انقطاع](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 الفروق الدقيقة في التنفيذ #### 4.3.1 دفاع "الرفع والتحويل" ```mermaid graph LR subgraph "جهاز الضحية" A[جلسة المستخدم
مع DBSC] B[المفتاح الخاص لـ
HSM/TPM] C[ملف تعريف الارتباط +
معرف الجلسة] A --> B A --> C B -.->|غير قابل للتصدير| X[لا يمكن استخراج
المفتاح الخاص] end subgraph "سيناريو الهجوم" D[برنامج RedLine Stealer
يصيب الجهاز] D --> E[يسرق ملف تعريف الارتباط
ومعرف الجلسة] E --> F[يصدر إلى
المهاجم] end subgraph "جهاز المهاجم" G[يستورد ملف تعريف
الارتباط المسروق] H[يحاول
استخدام الجلسة] I[يطلب الخادم
تحديث DBSC] J[لا يستطيع توقيع
التحدي] K[رفض الجلسة] G --> H H --> I I --> J J --> K end C -.->|مسروق| E F --> G style D fill:#ff6b6b,color:#fff style K fill:#51cf66,color:#fff style B fill:#4c6ef5,color:#fff style X fill:#51cf66,color:#fff style J fill:#ff6b6b,color:#fff ``` تخيل مهاجماً أصاب جهاز الكمبيوتر الخاص بالمستخدم ببرنامج RedLine Stealer. يسرق `access_token` و `session_id`. ويقوم باستيرادها إلى متصفحه الخاص. - **السيناريو أ (خلال 5 دقائق):** قد يحصل المهاجم على وصول لبضع دقائق حتى تنتهي صلاحية الرمز المميز قصير الأجل. - **السيناريو ب (بعد انتهاء الصلاحية):** يحاول متصفح المهاجم (على جهاز مختلف) استخدام الرمز المميز. يرفضه الخادم ويطالب بتحديثه. يرى متصفح المهاجم ترويسات DBSC ولكنه لا يستطيع إجراء التحديث لأنه لا يمتلك المفتاح الخاص المرتبط. يفشل الهجوم. #### 4.3.2 النطاق والخصوصية الخصوصية هي هدف تصميمي مركزي لـ DBSC. الـ [مواصفات W3C](https://www.w3.org/TR/dbsc/) تحظر صراحة استخدام المعرفات العالمية التي قد تتتبع المستخدمين عبر المواقع. - **مفاتيح لكل أصل:** يقوم المتصفح بإنشاء زوج مفاتيح فريد لكل موقع. يرى google.com المفتاح A؛ ويرى amazon.com المفتاح B. لا يوجد أي ارتباط بينهما. - **مسح بيانات المستخدم:** إذا قام المستخدم بمسح ملفات تعريف الارتباط/بيانات الموقع، يقوم المتصفح أيضاً بحذف مفاتيح DBSC المرتبطة. وهذا يضمن عدم إمكانية استخدام DBSC كـ "ملف تعريف ارتباط فائق" (super-cookie) لـ إحياء الهويات المحذوفة. #### 4.3.3 اعتبارات جانب الخادم يتطلب تنفيذ DBSC من الخادم الحفاظ على حالة حول المفاتيح العامة. - **مخطط قاعدة البيانات:** يجب تحديث جدول الجلسات لتخزين `public_key` و `last_challenge` بجانب `user_id` و `session_expiry`. - **الأداء:** تتضمن عملية التحديث تحققاً تشفيرياً (مثل التحقق من توقيع ECDSA). رغم سرعتها، إلا أنها تستهلك وحدة المعالجة المركزية (CPU) أكثر من التحقق من سلسلة بسيطة. ومع ذلك، نظراً لأن عمليات التحديث تحدث فقط كل بضع دقائق (وليس في كل طلب)، فإن العبء يكون ضئيلاً. ## 5. الآثار التجارية وتطوير المنتجات بالإضافة إلى المواصفات التقنية، يحمل DBSC آثاراً مهمة لاستراتيجية الأعمال، وخرائط طريق المنتجات، ومواقف الامتثال. ### 5.1 عائد الاستثمار للأمان بدون احتكاك غالباً ما يُنظر إلى المبادرات الأمنية على أنها مراكز تكلفة أو مولدات احتكاك. يقلب DBSC هذه السردية. يوضح الرسم البياني التالي كيف يخلق ربط الجهاز سلسلة من الفوائد التجارية: - **تقليل الاحتيال:** من خلال إبطال ناقل الاستيلاء على الحساب (ATO) الأساسي، يمكن للشركات توفير ملايين الدولارات في خسائر الاحتيال. - **تكاليف الدعم:** استرداد الحسابات مكلف. [يؤدي منع الاختراق في المقام الأول](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) إلى تقليل هذا العبء التشغيلي بشكل مباشر. - **تحسين التحويل:** في [التجارة الإلكترونية](https://www.corbado.com/passkeys-for-e-commerce)، تمثل كل مطالبة تسجيل دخول نقطة تسرب محتملة. يسمح DBSC بسياسات قوية لـ "إبقائي مسجل الدخول"، مما يمكّن من الدفع الفوري دون مطالبات بكلمات المرور. ### 5.2 الامتثال و "أحدث ما توصلت إليه التكنولوجيا" تتطلب الأطر التنظيمية مثل القانون العام لحماية البيانات (GDPR) في أوروبا من المؤسسات تنفيذ "تدابير فنية وتنظيمية مناسبة" لضمان الأمان. - **أمان يمكن الدفاع عنه:** مع تحول DBSC إلى معيار، من المرجح أن يُفسر على أنه "أحدث ما توصلت إليه التكنولوجيا" لإدارة الجلسات. في حالة حدوث خرق، فإن إثبات تنفيذ DBSC يمكن أن يكون دفاعاً قوياً ضد ادعاءات الإهمال. - **المعايير المصرفية (PSD2):** يتطلب التوجيه الخاص بخدمات [الدفع](https://www.corbado.com/passkeys-for-payment) 2 "مصادقة قوية للعملاء" (SCA). بينما يركز [SCA](https://www.corbado.com/ar/blog/psd2-passkeys) على تسجيل الدخول، فإن الربط الديناميكي للجلسة بالجهاز يتماشى تماماً مع أهداف التوجيه المتمثلة في ربط المصادقة بمبالغ ومدفوع لأمرهم محددين. ### 5.3 ضمان عالي مقابل ضمان متوسط تسلط [تقارير تحالف FIDO](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) الضوء على مفهوم "مستويات الضمان". - **ضمان متوسط:** يستخدم مفاتيح مرور متزامنة (مثل تلك الموجودة في [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)). رائع لتطبيقات المستهلكين، قابل للاسترداد، سهل الاستخدام. - **ضمان عالي:** يتطلب مفاتيح مرتبطة بالجهاز. هذا هو المكان الذي يتألق فيه DBSC. بالنسبة للموارد المؤسسية (بوابات الموارد البشرية، مستودعات الأكواد) أو [الخدمات المصرفية](https://www.corbado.com/passkeys-for-banking) عالية القيمة، قد تفرض المؤسسة سياسة تسمح _فقط_ بالوصول من جلسات مرتبطة بجهاز مُدار محدد. يوفر DBSC آلية الإنفاذ الفني لهذه السياسة. ## 6. DBSC مقابل البدائل لتقدير DBSC بشكل كامل، يجب أن نقارنها مع تقنيات أخرى حاولت حل مشاكل مشابهة. ```mermaid graph RL subgraph "ملفات تعريف الارتباط التقليدية" TC1[رمز حامل فقط] TC2[عرضة للسرقة] TC3[جلسات طويلة = مخاطر] TC1 --> TC2 TC2 --> TC3 end subgraph "ربط الرمز المميز Token Binding" TB1[ربط طبقة TLS] TB2[❌ فشل: بنية تحتية معقدة] TB3[انكسار عند موازنات الأحمال] TB1 --> TB2 TB2 --> TB3 end subgraph "DPoP" DP1[ربط الرمز المميز لـ OAuth] DP2[✅ حماية API] DP3[ليس لجلسات المتصفح] DP1 --> DP2 DP2 --> DP3 end subgraph "DBSC" D1[ربط طبقة HTTP] D2[✅ حماية مفتاح الجهاز] D3[✅ يعمل مع CDNs/موازنات الأحمال] D4[✅ جلسات المتصفح] D1 --> D2 D2 --> D3 D3 --> D4 end style TC2 fill:#ff6b6b,color:#fff style TB2 fill:#ff6b6b,color:#fff style D2 fill:#51cf66,color:#fff style D3 fill:#51cf66,color:#fff style D4 fill:#51cf66,color:#fff style DP2 fill:#51cf66,color:#fff ``` ### 6.1 DBSC مقابل ربط الرمز المميز (Token Binding) كما ذكرنا، حاول Token Binding ربط الجلسة بطبقة TLS. - **ربط الرمز المميز:** تطلب دعماً من العميل، والخادم، _و_ كل قفزة بينهما (موازنات الأحمال، أجهزة إنهاء TLS). وكان ينكسر عندما يتم إنهاء الاتصال و إعادة تشفيره. - **DBSC:** [يعمل في طبقة تطبيق HTTP](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). وهو يمر عبر موازنات الأحمال بشفافية كترويسات/ملفات تعريف ارتباط قياسية. ومن الأسهل بكثير نشره في البنى السحابية الحديثة (AWS/GCP/Azure) حيث يتم التعامل مع TLS غالباً بواسطة شبكة الحافة لمزود السحابة. ### 6.2 DBSC مقابل DPoP (إثبات إثبات الحيازة) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) هو معيار الرموز المميزة لـ OAuth "المقيدة بالمرسل". يربط كلاً من رموز الوصول _و_ رموز التحديث بمفتاح عام—وهو أمر بالغ الأهمية لأن رموز التحديث هي في حد ذاتها بيانات اعتماد حامل طويلة الأجل. يتضمن كل طلب API إثبات DPoP: [JWT](https://www.corbado.com/ar/glossary/jwks) موقع بطريقة HTTP وعنوان URL وطابع زمني ومعرف فريد. تفرض مواصفات الضمان العالي مثل [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) رموزاً مقيدة بالمرسل؛ وDPoP هي الطريقة الموصى بها عندما لا يكون mTLS متاحاً. **الفرق الرئيسي:** تعيش مفاتيح DPoP في سياق التطبيق. أفضل الممارسات هي استخدام واجهات برمجة تطبيقات نظام التشغيل للتخزين غير القابل للاستخراج، ولكن هذا غير مفروض—حيث تحتفظ العديد من التطبيقات بالمفاتيح في ذاكرة يمكن الوصول إليها عبر JavaScript. إذا تمكن مهاجم من تنفيذ تعليمات برمجية عشوائية (XSS، برامج ضارة)، فيمكنه الوصول إلى مفاتيح DPoP أو إنشاء أدلة عند الطلب. يوقف DPoP إعادة تشغيل الرموز المميزة _بين عملاء مختلفين_، ولكنه لا يمكنه حماية سياق متصفح مخترق. ينقل DBSC إثبات الحيازة إلى المتصفح والأجهزة. يعيش المفتاح الخاص في TPM أو معزل آمن (Secure Enclave) لا يمكن لـ JavaScript قراءته أو تصديره. يتعامل المتصفح مع البروتوكول وينتج توقيعات دون تعريض المفاتيح لرمز التطبيق. حتى لو تم اختراق تطبيق الويب بالكامل، لا يمكن للمهاجم صياغة أدلة جديدة لملفات تعريف الارتباط المسروقة على جهاز آخر. | الجانب | DPoP | DBSC | | --------------------- | ---------------------------------------------------------- | ------------------------------- | | **الهدف** | رموز الوصول + التحديث لـ OAuth | ملفات تعريف ارتباط جلسة المتصفح | | **تخزين المفتاح** | سياق التطبيق (أفضل ممارسة: APIs لنظام التشغيل) | مدعوم بالأجهزة (TPM) | | **مقاومة XSS** | ⚠️ تعتمد على التنفيذ | ✅ مفاتيح غير قابلة للتصدير | | **الاستخدام الأساسي** | التطبيقات الأصلية، تطبيقات الصفحة الواحدة (SPAs)، FAPI 2.0 | جلسات الويب التي تواجه المستخدم | **التآزر:** كما [يشير تحالف FIDO](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)، تقضي مفاتيح المرور على التصيد الاحتيالي عند تسجيل الدخول، بينما تحمي DBSC/DPoP الرموز المميزة لما بعد المصادقة. تجمع بنية حديثة بينهما: DPoP لواجهات برمجة تطبيقات OAuth (خاصةً [الخدمات المصرفية](https://www.corbado.com/passkeys-for-banking) المفتوحة الخاضعة للتنظيم)، وDBSC لجلسات المتصفح. وهما معاً يغلقان ناقل الهجوم "الرفع والتحويل" (lift and shift) عبر كامل دورة حياة الجلسة. ### 6.3 DBSC مقابل ملفات تعريف الارتباط قصيرة الأجل (بمفردها) يؤدي تقصير فترات صلاحية ملفات تعريف الارتباط (مثلاً، إلى 15 دقيقة) إلى تحسين الأمان ولكنه يدمر تجربة المستخدم. يُجبر المستخدمون على تسجيل الدخول باستمرار. يسمح DBSC بـ _فعالية_ أمان ملف تعريف ارتباط لمدة 5 دقائق مع _تجربة مستخدم_ لمدة 30 يوماً. ## 7. الإشارات المشتركة والاستجابة الديناميكية (CAEP/RISC) ```mermaid %%{init: { "theme": "default", "themeVariables": { "actorBkg": "#ffffff", "actorBorder": "#000000", "noteBkgColor": "#f1f3f5", "noteTextColor": "#000000", "activationBkgColor": "#e0e0e0", "actorColours": { "ST": "#ff6b6b", "IdP": "#4c6ef5" } } }}%% sequenceDiagram participant ST as أدوات الأمان
(CrowdStrike, Defender) participant IdP as موفر الهوية
(Okta, Google, Azure) participant SP1 as موفر الخدمة 1
(Slack) participant SP2 as موفر الخدمة 2
(Salesforce) participant SP3 as موفر الخدمة 3
(تطبيق بنكي) participant Session as جلسة المستخدم
(محمية بـ DBSC) Note over ST,Session: مرحلة اكتشاف التهديد ST->>ST: يكتشف برامج ضارة على
جهاز المستخدم ST->>IdP: إشارة RISC:
"جهاز مخترق" Note over IdP,SP3: مرحلة انتشار الإشارة IdP->>SP1: حدث CAEP:
"جهاز مخترق" IdP->>SP2: حدث CAEP:
"جهاز مخترق" IdP->>SP3: حدث CAEP:
"جهاز مخترق" Note over SP1,Session: مرحلة التنفيذ (مع DBSC) Session->>SP1: محاولة التحديث التالية
(خلال دقائق) SP1-->>Session: x رفض التوقيع Session->>SP2: محاولة التحديث التالية SP2-->>Session: x رفض التوقيع Session->>SP3: محاولة التحديث التالية SP3-->>Session: x رفض التوقيع Note over Session: يمكن إنهاء الجلسات في محاولة التحديث التالية ``` يتم تضخيم إمكانات DBSC عندما يقترن بـ [**إطار عمل الإشارات المشتركة (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/)، تحديداً **ملف تعريف التقييم المستمر للوصول (CAEP)** و **إدارة المخاطر (RISC)**. ملاحظة: إن SSF/CAEP هي إمكانية نظام بيئي ناشئة—تم تحديد النمط المعماري، لكن النشر واسع النطاق عبر البائعين لا يزال في مرحلة النضج. في النموذج القديم، إذا تم اختراق جهاز مستخدم، لم يكن لدى موفر الهوية (IdP) طريقة لإخبار موفر الخدمة (SP) بقتل الجلسة _على الفور_. كان على موفر الخدمة الانتظار حتى تنتهي صلاحية ملف تعريف الارتباط. تدفق DBSC + CAEP المتصور: 1. **المحفز:** تكتشف أداة أمان نقطة النهاية (مثل CrowdStrike أو Microsoft Defender) برامج ضارة على كمبيوتر المستخدم المحمول. 2. **الإشارة:** ترسل أداة الأمان إشارة RISC إلى موفر الهوية (مثل Okta/Google). 3. **الانتشار:** يدفع IdP حدث CAEP إلى التطبيقات المتصلة: "جهاز مخترق." 4. **التنفيذ (DBSC):** في المرة القادمة التي يحاول فيها المتصفح تحديث ملف تعريف ارتباط DBSC قصير الأجل، يرفض الخادم التوقيع ويقتل الجلسة. يتيح [هذا النمط المعماري](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) إبطالاً أسرع—يعتمد زمن الانتقال الفعلي على فترة التحديث الخاصة بالموقع وما إذا كانوا قد نفذوا كلاً من DBSC و SSF. ## 8. دعم المتصفحات والنظام البيئي يعتمد اعتماد DBSC على بائعي المتصفحات. لقد تغير المشهد في عام 2026 مادياً: نقل Chrome ميزة DBSC من التجربة الأصلية (Origin Trial) إلى التوفر العام على Windows في أبريل 2026، وسيأتي macOS بعد ذلك. ولا تزال المتصفحات الأخرى في مرحلة التقييم. ### 8.1 Google Chrome تعد Google هي المحرك الرئيسي لـ DBSC وأول متصفح يقوم بشحنه على نطاق واسع. - **الحالة (أبريل 2026):** [يطلق Chrome 146 ميزة DBSC في التوفر العام على نظام Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)، لتنتهي مرحلة Origin Trial. تم الإعلان عن دعم macOS، باستخدام [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)، في إصدار قادم لـ Chrome. - **الأجهزة:** يستخدم Windows نظام TPM، وسيستخدم macOS نظام Secure Enclave. وصرحت Google بأنها تستكشف أيضاً **مفاتيح مستندة إلى البرامج** لتوسيع حماية DBSC للأجهزة التي لا تحتوي على أجهزة أمان مخصصة. - **خارطة الطريق:** نشر إعلان التوفر العام من Google أيضاً خارطة الطريق للخطوة التالية: - **تأمين الهوية الموحدة:** ارتباطات DBSC عبر الأصول بحيث تظل جلسة الطرف المعتمد (RP) مرتبطة بنفس مفتاح الجهاز مثل جلسة موفر الهوية (IdP)، مع الحفاظ على سلسلة ثقة غير منقطعة عبر [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso). - **التسجيل المتقدم:** ربط جلسات DBSC بمواد رئيسية موثوقة موجودة مسبقاً مثل **شهادات mTLS** أو **مفاتيح الأمان للأجهزة**، بدلاً من إنشاء مفتاح جديد عند تسجيل الدخول. - **دعم أوسع للأجهزة:** مفاتيح مستندة إلى البرامج للأجهزة بدون TPM / Secure Enclave. - **النتائج التشغيلية:** أثناء الطرح، أبلغت Google عن "انخفاض كبير في سرقة الجلسات" للجلسات المحمية بواسطة DBSC. - **حسابات Google:** بشكل منفصل، كانت Google قد طرحت بالفعل حماية بنمط DBSC لـ [ملفات تعريف ارتباط حساب Google على متصفح Chrome لنظام التشغيل Windows](https://support.google.com/chrome/a/answer/2657289)، والتي يتم التحكم فيها عبر سياسة المؤسسة. يحمي هذا Gmail/Workspace وهو الآن جزء من نفس عائلة التكنولوجيا التي تتوفر بشكل عام للويب العام. ### 8.2 Microsoft Edge و Windows تشارك Microsoft بنشاط. - **الحالة:** أجرى Edge [تجربة أصلية لـ DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) على نظام Windows انتهت في أكتوبر 2025. ولم يتم الإعلان عن تجربة بديلة أو توفر عام. - **سياق المؤسسة:** يستخدم Edge [بنية "رمز التحديث الأساسي" (PRT)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) للدخول الموحد (SSO) الخاص بـ Entra/Azure AD، والتي تشبه مفاهيمياً DBSC. تظل PRT آلية خاصة بـ Microsoft؛ لا توجد خطة معلنة لتوحيدها مع معيار الويب DBSC لمواقع الطرف الثالث. ### 8.3 Apple Safari (WebKit) موقف Apple أمر بالغ الأهمية لتغطية الهواتف المحمولة. - **الحالة:** لدى WebKit [مشكلة موقف المعايير](https://github.com/WebKit/standards-positions/issues/281) لتقييم DBSC مع مخاوف ملحوظة تتعلق بقابلية الاستخدام/الخصوصية. لا تذكر ملاحظات إصدار Safari تقنية DBSC. ولا يوجد بيان عام "ينفذ بنشاط". - **الخصوصية أولاً:** القلق الرئيسي لشركة Apple هو إمكانية استخدام DBSC لإنشاء "ملفات تعريف ارتباط فائقة" (super-cookies) (تتبع لا يمكن حذفه). تتناول مواصفات W3C ذلك من خلال ضمان مسح المفاتيح ببيانات الموقع. - **المشاركة:** يشارك WebKit في العملية القياسية، لكن حالة التنفيذ غير واضحة — "قيد المناقشة" بدلاً من "قيد التطوير." ### 8.4 Mozilla Firefox لدى Mozilla [مشكلة موقف المعايير](https://github.com/mozilla/standards-positions/issues/912) لتقييم DBSC مع مخاوف ملحوظة حول التعقيد والخصوصية. لا يوجد التزام عام بالتنفيذ بمجرد استقرار المعيار. ## 9. التوصيات: حماية المستخدمين اليوم نظراً لدعم النظام البيئي الحالي لـ DBSC ومفاتيح المرور، يجب على المؤسسات اتخاذ نهج مرحلي لتنفيذ هذه التقنيات التكميلية. تحدد خارطة الطريق أدناه الإجراءات الفورية والمعالم الاستراتيجية للتخطيط: ### 9.1 الإجراءات الفورية (الآن توفر Chrome 146 بشكل عام) 1. **نشر مفاتيح المرور أولاً**: ابدأ بتنفيذ مفتاح المرور لتأمين طبقة المصادقة. يوفر هذا حماية فورية ضد التصيد الاحتيالي لبيانات الاعتماد وهو المتطلب الأساسي للحصول على قيمة حقيقية من DBSC. 2. **إطلاق نقاط نهاية تسجيل وتحديث DBSC**: مع توفر Chrome 146 العام، أصبح العمل الواقعي الآن هو تكامل الواجهة الخلفية (backend): أضف ترويسات `Secure-Session-Registration` على استجابات تسجيل الدخول ونفذ `/dbsc/register` بالإضافة إلى نقطة نهاية تحديث تتحقق من التحديات الموقعة. لا يحتاج كود الواجهة الأمامية (front-end) إلى التغيير. 3. **تنفيذ جلسات قصيرة الأجل باستخدام رموز التحديث**: إذا لم تكن مستعداً بعد لـ DBSC، فاعتمد النمط المعماري للرموز قصيرة الأجل باستخدام آليات التحديث. يُعد هذا واجهتك الخلفية لـ DBSC مع تحسين الأمان اليوم. ### 9.2 التخطيط الاستراتيجي (الـ 12 شهراً القادمة) 1. **اعتماد نهج هجين**: استخدم ميزة الاكتشاف لتقديم DBSC للمتصفحات القادرة (حالياً Chrome 146+ على Windows، وmacOS Secure Enclave لاحقاً) مع الحفاظ على خيارات الرجوع. يؤدي هذا إلى تعظيم الأمان دون استبعاد المستخدمين على Safari أو Firefox أو Edge. 2. **التحضير لعناصر خارطة الطريق التالية**: أشارت Google صراحةً إلى الهوية الموحدة (ارتباطات [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) عبر الأصول)، والتسجيل المتقدم (mTLS / مفاتيح الأجهزة) والمفاتيح المستندة إلى البرامج لتغطية أوسع للأجهزة. إذا كنت تدير طبقة [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) أو IdP، فابدأ في التخطيط للربط عبر الأصول الآن. 3. **التكامل مع موفري الهوية**: إذا كنت تستخدم Okta أو [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) أو مزودي IdPs مشابهين، فاعمل معهم لتمكين دعم DBSC في حزم تطوير البرمجيات (SDKs) الخاصة بهم. شارك العديد منهم في التجارب الأصلية ويقومون الآن بشحن قدرات DBSC بنشاط بعد توفر Chrome بشكل عام. ### 9.3 أفضل ممارسات التنفيذ - **البدء بالأهداف ذات القيمة العالية**: إعطاء الأولوية لـ DBSC للوحات الإدارة، والمعاملات المالية، والوصول إلى البيانات الحساسة. - **استخدام الحلول المدارة**: فكر في الأنظمة الأساسية مثل Corbado التي تتعامل مع تعقيد تنفيذ DBSC وتوافق المتصفحات. - **القياس والتكرار**: تتبع المقاييس مثل محاولات اختطاف الجلسات، وتذاكر الدعم، واحتكاك المستخدم لإثبات عائد الاستثمار (ROI). - **التحضير للامتثال**: قم بتوثيق تنفيذ DBSC الخاص بك حيث سيصبح على الأرجح متطلباً للامتثال للتعامل مع البيانات الحساسة. ## 10. كيف يمكن لـ Corbado المساعدة: جسر نحو المستقبل إن تنفيذ DBSC من الصفر هو عبء هندسي ثقيل. فهو يتطلب خبرة تشفيرية، ومعرفة عميقة باختلافات المتصفحات، وبنية تحتية قوية من جانب الخادم لإدارة المفاتيح والتحديات. هنا حيث تعمل منصة **Corbado** كأداة تمكين. ### 10.1 الأساس: مفاتيح المرور لا يمكنك بناء جلسة ذات ضمان عالٍ على قمة تسجيل دخول ذي ضمان منخفض. إذا سجل المستخدم الدخول بكلمة مرور ضعيفة، فإن الجلسة تكون آمنة فقط بقدر أمان كلمة المرور تلك. يوفر منتج Corbado الأساسي (**مفاتيح المرور المدارة**) هذا الأساس الضروري. من خلال دمج Corbado، يمكن للمؤسسات نشر مفاتيح المرور بسهولة، مما يضمن أن تكون بداية الجلسة مقاومة للتصيد الاحتيالي. ### 10.2 المستقبل: DBSC لاكتشاف الأجهزة الموثوقة ستستفيد Corbado من تقنية DBSC لتعزيز الكشف عن الأجهزة الموثوقة. عندما تكون إشارات DBSC متاحة، فإنها توفر دليلاً تشفيرياً على أن الجلسة تنشأ من جهاز معين مما يسمح لـ Corbado بزيادة مستويات الثقة في المصادقة وفقاً لذلك. - **حل غموض مفتاح المرور المتزامن:** مفاتيح المرور المتزامنة مريحة ولكنها تخلق فجوة في الثقة: عندما يصادق مستخدم باستخدام مفتاح مرور متزامن، لا يمكنك معرفة ما إذا كان جهازه المحمول المعتاد أو جهازاً جديداً تماماً قام بمزامنة بيانات الاعتماد للتو. يغلق DBSC هذه الفجوة. من خلال التحقق مما إذا كان الجهاز يحتوي على ربط DBSC راسخ، يمكن لـ Corbado التحقق من أن الجهاز معروف حقاً وموثوق به، وليس مجرد مزامنة لأول مرة. - **ثقة أعلى للأجهزة المعروفة:** عندما تؤكد إشارات DBSC أن الجهاز قد تم رؤيته من قبل، يمكن لـ Corbado اتخاذ قرارات مخاطرة أكثر ثقة: عدد أقل من مطالبات المصادقة المتدرجة (step-up) للمستخدمين العائدين الشرعيين، وتدقيق أكثر صرامة للجلسات الصادرة من أجهزة غير مألوفة. - **استكمال ذكاء مفتاح المرور:** تتكامل إشارات DBSC مع محرك [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) الحالي الخاص بـ Corbado. يُنشئ الجمع بين المصادقة المستندة إلى مفتاح المرور وربط الأجهزة المستند إلى DBSC سلسلة ثقة كاملة من تسجيل الدخول عبر دورة حياة الجلسة بأكملها. للأسئلة حول كيف تخطط Corbado لدمج DBSC في نظامها الأساسي، [تواصل مع الفريق](https://www.corbado.com/contact). ### 10.3 الرجوع السلس (الواقع "الهجين") بالنسبة للسنوات القليلة القادمة، سيكون الويب هجيناً. سيمتلك بعض المستخدمين متصفحات قادرة على DBSC (Chrome على [Windows 11](https://www.corbado.com/blog/passkeys-windows-11))؛ بينما سيكون الآخرون على أنظمة أقدم. التعامل مع هذا التجزئة أمر صعب. تم تصميم محرك [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) الخاص بـ Corbado للتعامل مع هذا النوع من منطق الرجوع (fallback) لتقديم مفاتيح المرور للأجهزة القادرة وبدائل للأجهزة الأخرى. ينطبق هذا الذكاء نفسه على ربط الجلسات، مما يضمن تحقيق أقصى قدر من الأمان لكل مستخدم وفقاً لإمكانيات جهازه. ## 11. الخلاصة: الطريق نحو المستقبل لـ DBSC يقترب عصر "الرمز المميز للحامل" (Bearer Token) من نهايته. فشلت إدارة الجلسة الحالية بشكل كارثي — حيث يمكن سرقة الرموز المميزة للحامل من خلال عمليات برامج ضارة واسعة النطاق واستخدامها من أي جهاز، مما يتيح عمليات استيلاء على الحسابات تتجاوز حتى أقوى طرق المصادقة. لقد خلقت هذه الثغرة الأساسية اقتصاداً سرياً بقيمة مليارات الدولارات. تُمثل بيانات اعتماد الجلسة المرتبطة بالجهاز (DBSC) الإجابة الناشئة للصناعة. على عكس ملفات تعريف الارتباط الآمنة التقليدية بعلامات HttpOnly وأسرارها الثابتة، يضيف DBSC إثباتاً تشفيرياً للحيازة عبر مفاتيح مرتبطة بالجهاز. هذا يجعل ملفات تعريف الارتباط المسروقة أقل قيمة بكثير. لا يمكن تحديثها من جهاز آخر. حيث فشل Token Binding من خلال المطالبة بتغييرات معقدة في طبقة TLS عبر جميع البنى التحتية، تنجح DBSC بالعمل على طبقة تطبيق HTTP المتوافقة مع موازنات الأحمال الحالية وشبكات CDN. ملاحظة: لدى DBSC مسارات احتياطية موثقة حيث يتخطى المتصفح الربط (عند عدم توفر TPM، أخطاء في الشبكة)، لذلك فهو يقلل بشكل كبير ولكنه لا يلغي مخاطر سرقة ملفات تعريف الارتباط. يرفع التآزر بين DBSC ومفاتيح المرور (Passkeys) مستوى الأمان أمام المهاجمين بشكل كبير عبر رحلة المستخدم. فمفاتيح المرور تقضي على التصيد الاحتيالي عند تسجيل الدخول، بينما تجعل DBSC اختطاف الجلسات عبر سرقة ملفات تعريف الارتباط عن بُعد أمراً أكثر صعوبة - ويشكلان معاً إطار الهوية عالي الضمان (high assurance) الذي يتصوره تحالف FIDO. مع [طرح Chrome 146 لـ DBSC في التوفر العام على نظام Windows في أبريل 2026](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) ودعم macOS Secure Enclave القادم، يكون المعيار قد انتقل من مرحلة التحضير إلى مرحلة الطرح. وتُشير خارطة طريق Google (الهوية الموحدة، تسجيل mTLS / مفاتيح الأجهزة، والمفاتيح المستندة إلى البرمجيات) إلى الـ 12 شهرًا القادمة من التوسع. بالنسبة لمديري المنتجات، تعتبر حالة العمل مقنعة: فـ DBSC تمكن جلسات آمنة "لا نهائية" تقلل بشكل كبير من احتكاك المستخدمين عند تسجيل الدخول وفي الوقت نفسه تقلل خسائر الاحتيال وتكاليف الدعم. ويتجلى العائد على الاستثمار في معدلات تحويل أعلى، وتذاكر إعادة تعيين كلمات مرور أقل، وإزالة حوادث الاستيلاء على الحسابات. بالنسبة للمنظمات التي تستخدم OAuth، فيمكنها استغلال نفس مفهوم ربط المفتاح من خلال DPoP لرموز واجهات برمجة التطبيقات (API tokens)، بينما يُمكّن التكامل مع الإشارات المشتركة (CAEP/RISC) من الاستجابة الفورية للتهديدات - إبطال الجلسات المخترقة فوراً عند محاولة التحديث التالية. التنفيذ لا يتطلب البدء من الصفر. توفر المنصات مثل [Corbado](https://www.corbado.com/features) البنية التحتية لمفاتيح المرور، وتتابع التطورات في DBSC لدمج ربط الأجهزة مع نضوج دعم المتصفحات. يُعد [معيار W3C](https://www.w3.org/TR/dbsc/) مسودة عمل نشطة، و Chrome 146 متاح للعامة على نظام Windows وجاري توفيره على نظام macOS، ولا تزال المتصفحات الأخرى في مرحلة تقييم المعيار. المسار المستقبلي واضح: المنظمات التي تبدأ باعتماد مفاتيح المرور و DBSC اليوم ستكون في الوضع الأفضل للمستقبل الخالي من كلمات المرور والمقاوم للتصيد الاحتيالي. السؤال لا يتعلق بما إذا كنت ستُطبّق جلسات مرتبطة بالجهاز، بل بمدى السرعة التي يمكنك بها نشرها لحماية مستخدميك وعملك. إن مستقبل أمان الويب لن يكون مصادقاً فقط؛ بل سيكون مرتبطاً تشفيرياً بالأجهزة التي نثق بها. ## الأسئلة الشائعة ### كيف يعمل DBSC مع CAEP و RISC لإلغاء الجلسات المخترقة في الوقت الفعلي؟ عندما تكتشف أدوات أمان نقاط النهاية مثل CrowdStrike وجود برامج ضارة، فإنها ترسل إشارة RISC إلى مزود الهوية (Identity Provider)، والذي يرسل حدث 'جهاز مخترق' (Device Compromised) من نوع CAEP إلى التطبيقات المتصلة. عند محاولة التحديث التالية لـ DBSC (في غضون دقائق)، ترفض تلك التطبيقات توقيع الجلسة وتقطع الوصول. ولا يزال النشر المشترك عبر مورّدي CAEP/RISC في مرحلة النضوج. ### ما الفرق بين DBSC و DPoP في حماية جلسات تطبيقات الويب؟ تقوم DPoP (RFC 9449) بربط رموز الوصول (access tokens) ورموز التحديث (refresh tokens) لـ OAuth بمفتاح عام في طبقة التطبيق، مما يحمي أساسًا استدعاءات واجهات برمجة التطبيقات (API) في التطبيقات الأصلية (native apps) وتطبيقات الصفحة الواحدة (SPAs). أما DBSC فتقوم بربط ملفات تعريف ارتباط (cookies) جلسة المتصفح بمفاتيح TPM مدعومة بالأجهزة بحيث لا يمكن لـ JavaScript قراءتها أو تصديرها، مما يحمي الجلسات الخاصة بالمستخدم حتى لو تم اختراق تطبيق الويب نفسه بواسطة البرمجة عبر المواقع (XSS) أو البرامج الضارة. ### لماذا تسمح DBSC بفترات جلسة أطول دون زيادة المخاطر الأمنية؟ يتطلب التصميم الآمن التقليدي انتهاء فترات الجلسات (session timeouts) بوقت قصير للحد من الضرر إذا سُرق ملف تعريف ارتباط وأُعيد تشغيله عن بُعد. وتقوم DBSC بربط إمكانية التحديث بالمفتاح الخاص للجهاز الأصلي، لذا فإن أي ملف تعريف ارتباط مسروق يُستخدم من جهاز آخر سيفشل في اختبار التحدي التشفيري. وبهذا يمكن أن تكون الجلسات فعلية ولأجل غير مسمى لأن هجمات إعادة التشغيل عن بُعد قد تم تحييدها. ### ما هو عائد الاستثمار (ROI) الذي يمكن أن تتوقعه الشركات من نشر DBSC؟ تقوم DBSC بتحييد سرقة ملفات تعريف الارتباط بصفتها الناقل الأساسي في عمليات الاستيلاء على الحسابات، مما يقلل بشكل مباشر من خسائر الاحتيال وتكاليف دعم استعادة الحسابات. فالجلسات الطويلة الآمنة تقضي على المطالبات المتكررة بتسجيل الدخول، مما يحسن معدلات التحويل في التجارة الإلكترونية ويقلل من معدلات الانسحاب. ويصنف تحالف FIDO (FIDO Alliance) تقنية DBSC كأداة ترفع من مستوى الأمان وتقلل الاحتكاك لدى المستخدم في الوقت نفسه.