كيف يخترق الهاكر حسابك دون كلمة مرور؟

شرح Session Hijacking (سرقة الجلسات والـCookies) مع أمثلة واقعية ونصائح حماية تقنية.

صورة توضيحية لعملية سرقة الكوكيز (Cookie Hijacking)

مقدمة

في عالم الويب الحديث، ليست كلمة المرور وحدها هدف المهاجم؛ أحياناً يكفي سرقة Session Token ليحاكي المهاجم جلسة المستخدم الشرعية. تُعرَف هذه التقنية بـ Session Hijacking أو Cookie Hijacking. سنتعرّف على أسلوب الهجوم، أمثلة حقيقية من تويتر وفيسبوك، ثم نستعرض أبرز طرق الحماية.

ما هو Session Hijacking؟

كل جلسة (Session) تُمثِّل اتصالاً بين المستخدم والخادم بعد تسجيل الدخول. يُنشئ الخادم رمزاً فريداً (Session ID أو Token) يُخزَّن عادة في Cookie. إذا حصل الهاكر على هذا الرمز، يستطيع تنفيذ أوامر باسم المستخدم دون كلمة المرور.

طرق الحصول على رمز الجلسة:

• ثغرات XSS لسرقة الكوكيز عبر JavaScript.
• التنصت عبر الشبكة في حال غياب HTTPS.
• ثغرات في واجهات الـ API تكشف access tokens.
• الوصول لأدوات الدعم الفني الداخلية التي تستعمل رموز جلسات الموظفين.

أنواع الهجمات

• Session Fixation: إجبار الضحية على استخدام معرف جلسة يحدده المهاجم مسبقاً.
• Session Sidejacking: التقاط الجلسة عبر شبكة غير مشفّرة.
• XSS: حقن سكربت لسرقة Cookies المستخدم.
• Man-in-the-Browser: برمجية خبيثة على جهاز الضحية تلتقط الرموز مباشرة.

أمثلة حقيقية من أرض الواقع

1. حادثة Twitter عام 2020

في يوليو 2020، استغلّ مهاجمون ثغرة داخلية في نظام الدعم لدى تويتر. عبر الهندسة الاجتماعية لموظفي الدعم، حصلوا على وصول إلى أدوات إدارية ومن خلالها سيطروا على حسابات شخصيات مثل Elon Musk وBarack Obama. لم يحتجوا كلمات المرور، بل استخدموا جلسات داخلية صالحة. هذه الحادثة أبرز مثال على أن اختراق الجلسة قد يأتي من الداخل لا من المستخدم.

2. ثغرة Facebook “View As” سنة 2018

تسببت ميزة “View As” في كشف Access Tokens لمهاجمين بسبب خطأ في الكود، ما أجبر فيسبوك على إعادة تسجيل الخروج لعشرات الملايين من المستخدمين. كان ذلك مثالاً عملياً على أن رمز الجلسة قد يصبح مدخلاً كاملاً للحساب حتى دون معرفة كلمة السر.

كيف تحمي تطبيقك ومستخدميك؟

1. تفعيل HTTPS وHSTS

تأكد أن كل الصفحات تعمل عبر HTTPS فقط وفعّل HSTS لمنع أي اتصال غير مشفر.

2. إعداد الكوكيز بشكل آمن

Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

• HttpOnly: يمنع وصول JavaScript للكوكي.
• Secure: يُرسل فقط عبر HTTPS.
• SameSite: يحد من إرسال الكوكي عبر المواقع الأخرى (يحمي من CSRF).

3. تقليل مدة الجلسة وإعادة التحقق

قلل مدة الصلاحية واطلب إعادة إدخال كلمة المرور قبل العمليات الحساسة.

4. مراقبة الجلسات وتنبيه المستخدم

أظهر الأجهزة النشطة وأتح إمكانية “تسجيل الخروج من كل الجلسات” كما تفعل Gmail وFacebook.

5. منع XSS باستخدام CSP

فلترة المدخلات وتطبيق Content Security Policy تحد من تنفيذ الأكواد الخبيثة.

6. حماية أدوات الدعم الفني

طبّق مبدأ أقل صلاحية، فعّل MFA، وراقب نشاط الموظفين لتجنّب تكرار سيناريو تويتر.

خطوات الاستجابة عند الاشتباه باختراق الجلسات

1. إلغاء جميع الجلسات (Invalidate Sessions) وإجبار تسجيل الدخول من جديد.
2. تحليل سجلات الدخول لعناوين IP الغريبة والأنشطة غير الاعتيادية.
3. إغلاق الثغرات الأمنية (XSS, exposed tokens, API bugs).
4. إبلاغ المستخدمين بالحادثة بشفافية.

قائمة فحص سريعة (Security Checklist)

• هل HTTPS مفعل في كل النطاقات؟
• هل Cookies تحمل HttpOnly وSecure وSameSite؟
• هل مدة الجلسة قصيرة ويتم تدوير الرموز؟
• هل تمت مراجعة XSS/CSP؟
• هل أدوات الدعم تستخدم MFA وتسجيل مراقب؟

الخلاصة

سرقة الجلسات (Session Hijacking) لا تحتاج معرفة كلمة المرور لتكون كارثية. الحماية تبدأ من HTTPS وتهيئة الكوكيز، وتنتهي بتأمين أدوات الدعم الداخلية ومراقبة السلوك. تطبيق هذه الخطوات يقلّل 90% من فرص الاستغلال.

المراجع

• OWASP — Session Management Cheat Sheet
• OWASP — Cookie Security (HttpOnly, Secure, SameSite)
• Twitter Security Blog (2020 Incident)
• Facebook Newsroom — View As Vulnerability Report (2018)