لسنوات طويلة، اعتبرت المصادقة الثنائية (MFA) خط الدفاع الأخير والحصن المنيع لحماية الحسابات الرقمية من الاختراق. ومع ذلك، تشهد الساحة الأمنية اليوم تحولاً جذرياً؛ حيث لم يعد المهاجمون بحاجة إلى تخمين كلمات المرور أو حتى تجاوز رموز التحقق المؤقتة (OTP). بدلاً من ذلك، يتجه القراصنة إلى سرقة 'مفاتيح المملكة' الجاهزة مباشرة: ملفات تعريف ارتباط الجلسة (Session Cookies). يُعرف هذا النمط المتقدم من الهجمات باسم سرقة الجلسات النشطة (Session Hijacking) أو هجمات Pass-the-Cookie.
عندما تفتتح جلسة عمل على أي موقع ويب، يقوم الخادم بإنشاء معرف فريد لجلساتك ويخزنه في متصفحك كملف تعريف ارتباط. وطالما أن هذا الملف موجود وصالح، فإن الموقع سيعاملك كشخص مسجل الدخول دون مطالبتك بإعادة إدخال كلمة المرور أو رمز الأمان. إذا تمكن المهاجم من استنساخ هذا الملف ونقله إلى متصفحه الخاص، فإنه يحصل على وصول فوري وكامل إلى حسابك، متجاوزاً كافة تدابير الحماية الثنائية في ثوانٍ معدودة. في هذا التحليل الفني العميق، سنفكك آليات هذه الهجمات، وكيفية عمل البرمجيات الخبيثة المتخصصة فيها، وأحدث التقنيات الدفاعية للتصدي لها.
التشريح الفني للجلسة الرقمية: كيف يعمل بروتوكول HTTP؟
لتفهم كيف يتم اختطاف الجلسة، يجب أولاً فهم البنية التحتية التي تقوم عليها. بروتوكول نقل النص الفائق (HTTP) هو بروتوكول 'عديم الحالة' (Stateless Protocol). هذا يعني أن خادم الويب يعامل كل طلب يصل إليه كحدث منفصل تماماً ومستقل عن الطلبات السابقة. لولا وجود آلية لحفظ الحالة، لتعين عليك تسجيل الدخول في كل مرة تضغط فيها على رابط داخلي أو تنتقل من صفحة إلى أخرى داخل نفس الموقع.
لحل هذه المعضلة، تم ابتكار 'ملفات تعريف ارتباط الجلسة' (Session Cookies). عند إدخال بيانات الاعتماد وتجاوز المصادقة بنجاح، يقوم الخادم بتوليد رمز عشوائي مشفر ذي إنتروبيا (عشوائية) عالية يُعرف بـ Session ID. يُرسل هذا الرمز إلى المتصفح ويُخزن محلياً. مع كل طلب لاحق يرسله المتصفح إلى الخادم، يتم تضمين هذا الرمز تلقائياً في ترويسة الطلب (HTTP Header). يقوم الخادم بمطابقة هذا الرمز بقاعدة البيانات النشطة لديه، وإذا تطابق، يمنحك حق الوصول فوراً.
دورة حياة ملف تعريف الارتباط الآمن
تعتمد أمنية هذه العملية على سرية معرف الجلسة. صممت منظمة OWASP معايير صارمة لإدارة الجلسات لتفادي التهديدات الأمنية. تشمل هذه المعايير سمات أمان محددة يجب تطبيقها على ملفات تعريف الارتباط الحساسة:
- HttpOnly: تمنع هذه السمة البرمجيات النصية لجانب العميل (مثل JavaScript) من الوصول إلى ملف تعريف الارتباط، مما يشكل حماية أساسية ضد هجمات حقن النصوص البرمجية (XSS).
- Secure: تضمن هذه السمة إرسال ملف تعريف الارتباط فقط عبر قنوات مشفرة باستخدام بروتوكول HTTPS، مما يمنع اعتراضه في الشبكات المحلية غير الآمنة.
- SameSite: تتحكم في إرسال ملفات تعريف الارتباط مع طلبات الجهات الخارجية، وهي خط دفاعي ممتاز ضد هجمات تزوير الطلبات عبر المواقع (CSRF).
متجهات الهجوم: كيف يسرق المهاجمون ملفات الجلسة؟
على الرغم من وجود هذه السمات الأمنية، يمتلك المهاجمون ترسانة من الطرق المتطورة للالتفاف عليها وسرقة الجلسات النشطة. تتنوع هذه الأساليب بين البرمجيات الخبيثة المحلية والهندسة الاجتماعية المتقدمة.
1. برمجيات سرقة المعلومات (Infostealers)
تعتبر برمجيات سرقة المعلومات (مثل RedLine, Vidar, Lumma, Racoon) التهديد الأكبر والأكثر انتشاراً اليوم. لا تستهدف هذه البرمجيات تدمير النظام، بل تعمل بصمت تام لجمع البيانات الحساسة وخاصة ملفات تعريف ارتباط الجلسات المخزنة في المتصفحات.
تخزن متصفحات الويب الحديثة القائمة على مشروع Chromium (مثل Google Chrome و Microsoft Edge) ملفات تعريف الارتباط في قاعدة بيانات محلية من نوع SQLite تقع عادةً في مسار مستخدم النظام الفرعي. على نظام التشغيل Windows، تكون هذه البيانات مشفرة باستخدام واجهة برمجة تطبيقات حماية البيانات (DPAPI) الخاصة بنظام التشغيل. المشكلة هنا هي أن أي برمجية خبيثة تعمل بصلاحيات المستخدم الحالي على الجهاز يمكنها استدعاء دوال DPAPI وفك تشفير قاعدة البيانات هذه بسهولة تامة. تقوم البرمجية الخبيثة بضغط ملفات الكوكيز وفك تشفيرها، ثم إرسالها إلى خادم التحكم والسيطرة (C2) الخاص بالمهاجم كملف نصي بسيط أو بتنسيق JSON جاهز للاستيراد.
2. هجمات وسيط المنتصف العكسي (Adversary-in-the-Middle - AitM)
في هذا السيناريو، لا يحتاج المهاجم إلى زرع برمجية خبيثة على جهاز الضحية. بدلاً من ذلك، يستخدم تقنيات متطورة للهندسة الاجتماعية بالاستعانة بأدوات مثل Evilginx. تعمل هذه الأدوات كخادم وكيل عكسي (Reverse Proxy) يقع بين المستخدم والموقع الحقيقي (مثل Microsoft 365 أو Google).
عندما يزور المستخدم رابط التصيد، يرى صفحة تسجيل دخول مطابقة تماماً للموقع الأصلي. يكتب المستخدم اسمه وكلمة مروره، فيقوم الوكيل العكسي بتمريرها فوراً إلى الموقع الحقيقي. يطلب الموقع الحقيقي رمز المصادقة الثنائية (MFA)، فيدخله المستخدم في صفحة التصيد، ويمررها الوكيل العكسي مجدداً للموقع الحقيقي. بمجرد نجاح العملية، يصدر الموقع الحقيقي ملف تعريف ارتباط الجلسة (Session Cookie) ويرسله للوكيل العكسي ليمرره للمستخدم. هنا، يقوم الوكيل العكسي بحفظ نسخة من هذا الملف الثمين لديه. الآن، يمتلك المهاجم جلسة عمل كاملة ومصادق عليها بالكامل دون أن يثير أي إنذار أمني.
3. البرمجة النصية العابرة للمواقع (Cross-Site Scripting - XSS)
إذا فشل مطورو الموقع في تصفية مدخلات المستخدمين بشكل صحيح، يمكن للمهاجم حقن كود JavaScript خبيث في صفحات الموقع. عندما يزور مستخدم آخر هذه الصفحة، يتم تنفيذ الكود في متصفحه. إذا لم تكن سمة HttpOnly مفعلة على ملف تعريف ارتباط الجلسة، يمكن للكود قراءته ببساطة عبر الأمر document.cookie وإرساله مباشرة إلى خادم خارجي يسيطر عليه المهاجم.
التحليل الفني لآلية التشفير المحتالة: تجاوز DPAPI على Windows
لفهم مدى سهولة عمل برمجيات Infostealers، دعنا نلقي نظرة فنية على كيفية قيام المتصفحات بتأمين البيانات محلياً وكيف يتم اختراقها. تستخدم المتصفحات آلية تشفير تعتمد على مفتاح رئيسي (Master Key) يتم إنشاؤه وتشفيره بواسطة نظام التشغيل عبر دالة CryptProtectData (جزء من Windows DPAPI). يتم تخزين هذا المفتاح المشفر داخل ملف يسمى Local State في مجلد بيانات المتصفح.
عندما يبدأ متصفح Chrome العمل، يقوم بقراءة ملف Local State، ويفك تشفير المفتاح الرئيسي باستخدام دالة DPAPI المقابلة CryptUnprotectData. ثم يتم استخدام هذا المفتاح الذي تم فك تشفيره لفك تشفير حقول الكوكيز المحفوظة في قاعدة بيانات Cookies (وهي قاعدة بيانات SQLite مشفرة بخوارزمية AES-256-GCM).
بما أن البرمجية الخبيثة (Infostealer) تعمل تحت سياق نفس المستخدم الذي قام بتسجيل الدخول إلى نظام التشغيل، فإن نظام التشغيل يعتبر طلب فك التشفير الصادر عن البرمجية الخبيثة طلباً مشروعاً! تقوم البرمجية بالخطوات التالية برمجياً:
- البحث عن مسار ملف
Local Stateوقراءته لاستخراج المفتاح الرئيسي المشفر. - استدعاء دالة
CryptUnprotectDataلفك تشفير المفتاح الرئيسي. - فتح ملف قاعدة بيانات SQLite الخاص بملفات تعريف الارتباط
Cookies. - استخدام المفتاح الرئيسي الذي تم فك تشفيره لفك تشفير كل حقل فريد داخل قاعدة البيانات (خاصة حقول
encrypted_value). - تصدير النتائج التي تحتوي على أسماء النطاقات، وقيم الكوكيز، وتواريخ انتهائها، وإرسالها فوراً إلى المهاجم.
استراتيجيات الدفاع المتقدمة: الانتقال إلى نموذج صفر ثقة (Zero Trust)
بما أن الطرق التقليدية مثل كلمات المرور القوية والمصادقة الثنائية المستندة إلى التطبيقات (مثل Google Authenticator) أو الرسائل النصية (SMS) تفشل تماماً أمام هجمات سرقة الجلسات، كان لا بد من ابتكار حلول أمنية متقدمة تعيد صياغة مفهوم الثقة الرقمية.
1. المصادقة المقاومة للتصيد باستخدام FIDO2 و WebAuthn
تعتبر مفاتيح الأمان الفيزيائية القائمة على معيار FIDO2 (مثل مفاتيح Yubico YubiKey) خط الدفاع الأكثر فعالية ضد هجمات AitM (الوكيل العكسي). على عكس رموز OTP، يرتبط بروتوكول FIDO2 تشفيرياً بنطاق الموقع (Domain) المتصفح حالياً.
عندما يحاول المستخدم تسجيل الدخول إلى موقع تصيد مصمم ليبدو مثل Google باستخدام مفتاح YubiKey، يتواصل المتصفح مع المفتاح الفيزيائي ويمده بنطاق الموقع الحالي (مثلاً login-google-fake.com). يلاحظ المفتاح الفيزيائي أن هذا النطاق لا يطابق المفتاح العام المسجل لديه لنطاق Google الحقيقي (accounts.google.com)، فيرفض إصدار التوقيع الرقمي للتسجيل. بالتالي، يفشل المهاجم في الحصول على أي جلسة صالحة.
2. ربط الجلسة بالجهاز (Device-Bound Session Credentials - DBSC)
في خطوة ثورية للحد من هجمات سرقة ملفات الارتباط، تعمل Google ومجتمع الويب على تطوير مبادرة أمنية جديدة تسمى DBSC. تتوفر تفاصيل هذه المبادرة في مشروع Google DBSC GitHub.
تعتمد هذه التقنية على ربط جلسة الويب بمفتاح تشفير خاص يتم إنشاؤه وتخزينه بأمان داخل شريحة الأمان الفيزيائية للجهاز (مثل TPM - Trusted Platform Module). بدلاً من إرسال ملف تعريف ارتباط ثابت مع كل طلب، يتطلب الخادم من المتصفح إثبات حيازته للمفتاح الخاص الموجود في الـ TPM عبر توقيع تحدي رقمي (Challenge-Response) فريد لكل طلب أو على فترات زمنية قصيرة جداً. إذا قام المهاجم بسرقة ملف تعريف الارتباط ونقله إلى جهاز آخر، فلن يتمكن من استخدامه لأن جهاز المهاجم يفتقر إلى المفتاح الخاص المحمي في شريحة TPM للجهاز الأصلي، مما يجعل ملف الكوكيز المسروق عديم الفائدة تماماً.
3. التقييم المستمر للوصول (Continuous Access Evaluation - CAE)
تستخدم المؤسسات الكبرى بروتوكولات متقدمة مثل CAE (التي تتبناها منصات مثل Microsoft Azure AD). بدلاً من الاعتماد على صلاحية ملف تعريف الارتباط التي قد تستمر لأيام، يقوم النظام بمراقبة سياق الجلسة باستمرار. إذا تم رصد تغيير مفاجئ في عنوان الـ IP، أو محاولة وصول من دولة مختلفة تماماً في وقت قصير (مستحيل فيزيائياً)، أو تم اكتشاف سلوك غير معتاد، يتم إبطال الجلسة فوراً وإجبار المستخدم على إعادة المصادقة باستخدام وسيلة قوية.
مقارنة تقنية: كفاءة وسائل المصادقة ضد التهديدات المتقدمة
يوضح الجدول التالي مدى صمود وسائل المصادقة المختلفة أمام تقنيات الهجوم المعاصرة:
| وسيلة المصادقة | مقاومة هجمات الهندسة الاجتماعية والتصيد التقليدي | مقاومة هجمات الوكيل العكسي (AitM) | مقاومة برمجيات سرقة المعلومات (Infostealers) | مستوى تعقيد التطبيق للمستخدم |
|---|---|---|---|---|
| اسم المستخدم + كلمة المرور فقط | ضعيفة جداً | منعدمة | منعدمة | سهل جداً |
| الرموز عبر الرسائل النصية (SMS OTP) | متوسطة (يمكن هندستها) | منعدمة (يتم اعتراضها) | منعدمة (بعد توليد الجلسة) | سهل |
| تطبيقات المصادقة (Google/Microsoft Authenticator) | جيدة | منعدمة (يتم اعتراض الرمز بالوقت الحقيقي) | منعدمة (بعد توليد الجلسة) | متوسط |
| مفاتيح الأمان الفيزيائية (FIDO2 / WebAuthn) | ممتازة (مقاومة بالكامل) | ممتازة (مقاومة بالكامل) | منعدمة (إذا تمت السرقة بعد تسجيل الدخول بنجاح) | متوسط إلى مرتفع |
| ربط الجلسة بالجهاز (DBSC / Token Binding) | ممتازة (بالتكامل مع FIDO2) | ممتازة | ممتازة (الملف المسروق لا يعمل على جهاز آخر) | تلقائي بالكامل (لا يتطلب تدخل المستخدم) |
خطوات عملية لتأمين أجهزتك وحساباتك من سرقة الجلسات
لحماية نفسك أو مؤسستك من هذه الهجمات المعقدة، يجب اتباع نهج دفاعي متعدد الطبقات يركز على حماية المتصفح، والحد من انتشار البرمجيات الخبيثة، وإدارة الجلسات بذكاء.
أولاً: حماية المتصفح ونظام التشغيل
- تفعيل ميزة الحماية المحسنة في المتصفح: توفر متصفحات مثل Chrome و Edge أوضاع حماية متقدمة تقوم بفحص الملفات المحملة والروابط بشكل فوري باستخدام السحابة الأمنية للشركة المطورة، مما يمنع تنزيل برمجيات Infostealers قبل تشغيلها.
- استخدام برامج فحص متخصصة: لا تكتفي بمضاد الفيروسات التقليدي. استخدم أدوات متخصصة في كشف البرمجيات الضارة المستعصية وبرمجيات التجسس مثل Malwarebytes بشكل دوري لفحص الذاكرة العشوائية وملفات النظام الحساسة.
- تجنب حفظ كلمات المرور والجلسات في المتصفح الافتراضي: يفضل استخدام مدير كلمات مرور خارجي مخصص ومشفر (مثل Bitwarden أو 1Password) يحتوي على تشفير قوي ومستقل عن نظام التشغيل ولا يسهل الوصول إليه عبر دوال DPAPI البسيطة.
ثانياً: النظافة الرقمية وإدارة الجلسات
- تسجيل الخروج النشط: عند الانتهاء من استخدام حساباتك الحساسة (خاصة الحسابات البنكية أو حسابات العمل)، لا تكتفِ بإغلاق علامة تبويب المتصفح. اضغط دائماً على زر 'تسجيل الخروج' (Log out). هذا الإجراء يرسل أمراً فورياً لخادم الويب لإبطال معرف الجلسة (Session ID) في قاعدة بياناته، مما يجعل ملف تعريف الارتباط المخزن في متصفحك بلا أي قيمة لو سُرق لاحقاً.
- مراقبة الأجهزة النشطة باستمرار: قم بزيارة صفحات الأمان في حساباتك (مثل صفحة 'الأجهزة النشطة' في Google أو Microsoft) بشكل دوري، وقم بإنهاء أي جلسة مشبوهة أو قديمة لم تعد تستخدمها.
- تقييد صلاحيات التطبيقات والإضافات: تشكل إضافات المتصفح (Browser Extensions) خطراً داهماً؛ حيث يمتلك الكثير منها صلاحية قراءة وتعديل البيانات على جميع المواقع التي تزورها. تخلص من أي إضافات غير ضرورية، وتأكد من موثوقية المطورين للإضافات المتبقية.
الأسئلة الشائعة حول سرقة الجلسات وملفات تعريف الارتباط
هل يحميني وضع التصفح المتخفي (Incognito Mode) من سرقة الجلسات؟
يحميك وضع التصفح المتخفي جزئياً فقط من الهجمات المحلية؛ حيث يتم تدمير ملفات تعريف الارتباط بمجرد إغلاق نافذة التصفح المتخفي. ومع ذلك، إذا أصيب جهازك ببرمجية خبيثة (Infostealer) أثناء فتحك لجلسة متخفية، يمكن للبرمجية سرقة الملف من الذاكرة العشوائية (RAM) أو من المجلد المؤقت قبل إغلاقه. كما أن وضع التصفح المتخفي لا يحميك مطلقاً من هجمات وسيط المنتصف العكسي (AitM) والتصيد المتقدم.
هل يمكن للمهاجم استخدام الكوكيز المسروق حتى لو قمت بتغيير كلمة المرور؟
في كثير من الأنظمة المصممة بشكل سيء، نعم، يظل ملف تعريف الارتباط صالحاً حتى تاريخ انتهائه الأصلي حتى بعد تغيير كلمة المرور. ومع ذلك، فإن المنصات الكبرى والمؤمنة جيداً (مثل Google و Microsoft) تقوم تلقائياً بإبطال جميع الجلسات النشطة وملفات تعريف الارتباط المرتبطة بالحساب بمجرد تغيير كلمة المرور أو تسجيل الخروج من جميع الأجهزة. لذلك، إذا شككت في تعرض جهازك للاختراق، فإن أول خطوة يجب فعلها هي تغيير كلمة المرور فوراً من جهاز آخر نظيف لفرض إبطال الجلسات المسروقة.
هل تمنع المصادقة الثنائية (MFA) هجمات Pass-the-Cookie؟
لا، المصادقة الثنائية التقليدية (مثل رموز SMS وتطبيقات OTP) لا تمنع هذه الهجمات. تطلب هذه الوسائل التحقق عند 'إنشاء' الجلسة لأول مرة. بمجرد إنشاء الجلسة وتوليد ملف تعريف الارتباط، يعامل الخادم أي طلب يحمل هذا الملف على أنه طلب موثوق ومصادق عليه بالفعل دون طلب رمز التحقق مجدداً. الوسيلة الوحيدة من وسائل MFA التي تمنع هذه الهجمات هي تلك التي تمنع إنشاء الجلسة من الأساس عبر روابط التصيد (مثل FIDO2 YubiKey)، أو التقنيات المستقبلية التي تربط الجلسة بالجهاز في كل طلب (DBSC).
الخلاصة: إعادة رسم حدود الدفاع الرقمي
تثبت هجمات سرقة الجلسات النشطة أن الأمن السيبراني هو سباق تسلح مستمر لا ينتهي. إن الاعتماد على التدابير الأمنية الثابتة والتقليدية لم يعد كافياً لحماية الأصول الرقمية الثمينة للأفراد أو الشركات. يتطلب المشهد الأمني الحالي الانتقال الفوري نحو مبادئ صفر ثقة (Zero Trust)، والتي تفترض دائماً أن الشبكة أو الجهاز قد يكون مخترقاً بالفعل.
من خلال الجمع بين الوعي الأمني المتقدم، واستخدام مفاتيح الأمان الفيزيائية المقاومة للتصيد، وتبني المعايير التقنية الحديثة مثل ربط الجلسة بالأجهزة، يمكننا تحويل بيئتنا الرقمية إلى حصون منيعة تصمد أمام أكثر الهجمات تعقيداً وضراوة.
التعليقات
أضف تعليقاً