12
لماذا يوجد خيار «تذكرني» عند تسجيل الدخول؟ وكيف تؤدي سرقة الـ Session إلى الاستيلاء على حسابك؟
عند تسجيل الدخول إلى معظم المواقع، يظهر خيار "تذكرني / Remember me". للوهلة الأولى يبدو الأمر مجرد وسيلة لتجنب كتابة كلمة المرور مراراً، لكن خلف هذا الخيار تعمل آلية برمجية مرتبطة بإدارة جلسة المستخدم (Session) وملفات (Cookies).
فهم هذه الآلية، كما توضح معايير OWASP الأمنية، مهم جداً؛ لأن امتلاك مهاجم لـ Session صالحة قد يمنحه القدرة على التصرف كأنه أنت، حتى لو كانت كلمة مرورك قوية وحسابك محمياً بالمصادقة الثنائية (2FA).
ما هي الـ Session أصلًا؟
بروتوكول HTTP بطبيعته لا يتذكر المستخدم بين الطلبات. عندما ترسل بيانات الدخول (اسم المستخدم وكلمة المرور)، يتحقق الخادم منها. بعد نجاح العملية، يحتاج الموقع إلى طريقة يعرف بها أن النقرات التالية قادمة منك.
لذلك ينشئ الموقع "جلسة" (Session) مرتبطة بحسابك، ويعطي المتصفح رمزاً أو معرفاً يوضع غالباً في Cookie. في الطلبات التالية، يرسل المتصفح هذا الـ Cookie تلقائياً، فيعرف الخادم هويتك دون طلب كلمة المرور مجدداً.
ما الفرق بين الدخول العادي وخيار "تذكرني"؟
- في الدخول العادي: يتم إنشاء Session Cookie، وهو غير مصمم للبقاء. بمجرد إغلاقك للمتصفح، تختفي الجلسة وتحتاج لتسجيل الدخول مجدداً.
- مع خيار "تذكرني": ينشئ الموقع Persistent Cookie لها مدة صلاحية أطول (أيام أو أشهر). هذا يسمح للموقع بالتعرف عليك حتى بعد إغلاق المتصفح وفتحه لاحقاً.
ملاحظة هامة: التصميم الصحيح لا يخزن كلمة مرورك في الـ Cookie أبداً، بل يخزن رمزاً عشوائياً (Token) يمكن للخادم من خلاله التعرف على جلستك.
أين تكمن المشكلة الأمنية؟ (Session Hijacking)
المشكلة أن هذا الرمز (Token) يصبح بمثابة "مفتاح مؤقت" لحسابك.
إذا حصل مهاجم على Session Cookie صالحة، يستطيع إرسال طلبات إلى الموقع باستخدامها، وسيتعامل الخادم معها على أنها صادرة منك شخصياً. وكلما كان عمر الجلسة أطول (بسبب خيار تذكرني)، كانت نافذة الاستغلال المتاحة للمهاجم أكبر.
كيف يمكن أن تصل الـ Session إلى المهاجم؟
لا يعني وجود خيار "تذكرني" أن الموقع مخترق، ولكن هناك عدة سيناريوهات لسرقة الجلسات:
1. ثغرات XSS: إذا كان الموقع مصاباً بثغرة Cross-Site Scripting، يمكن لكود جافاسكريبت خبيث قراءة الـ Cookie الخاص بك (عبر document.cookie) وسرقته.
2. الاتصال غير الآمن (HTTP): إذا أُرسل الـ Cookie عبر اتصال غير مشفر، يمكن للمهاجم الموجود على نفس الشبكة اعتراض البيانات.
3. البرمجيات الخبيثة (Malware): إصابة جهازك ببرمجية خبيثة قادرة على الوصول لبيانات المتصفح مباشرة (وهذا من أكثر السيناريوهات شيوعاً وخطورة).
4. Session Fixation: المهاجم لا يسرق جلستك، بل يجبرك على تسجيل الدخول باستخدام Session ID يعرفه هو مسبقاً.
5. التخزين السيء: قيام الموقع بتخزين الـ Token في أماكن مكشوفة مثل الـ URL أو سجلات التصفح.
ماذا عن المصادقة الثنائية (2FA)؟
هنا توجد نقطة مفصلية: الـ 2FA يحمي "عملية المصادقة" نفسها. بينما الجلسة (Session) الصالحة تعني للخادم أن عملية المصادقة قد تمت وانتهت بالفعل.
لذلك، إذا حصل المهاجم على Token صالح، فلن يطلب منه الموقع إدخال كود الـ 2FA، وسيتمكن من الدخول مباشرة.
كيف تُحمي التطبيقات من هذه الهجمات؟ (جانب المطورين)
التطبيق الآمن يعتمد على طبقات حماية متعددة وفقاً لتوصيات OWASP:
- خاصية HttpOnly: تمنع أكواد الجافاسكريبت من قراءة الـ Cookie، مما يقلل من خطورة ثغرات XSS.
- خاصية Secure: تجعل المتصفح يرسل الـ Cookie عبر اتصال HTTPS المشفر فقط.
- خاصية SameSite: تساعد في تقليل إرسال الجلسات في الطلبات القادمة من مواقع خارجية، كطبقة حماية ضد هجمات CSRF.
- تغيير الـ Session بعد الدخول: إنشاء جلسة جديدة كلياً بعد نجاح تسجيل الدخول لضرب هجمات Session Fixation.
- تسجيل الخروج الصحيح (Logout): لا يكفي حذف الـ Cookie من المتصفح، بل يجب أن يقوم الخادم (Server) بإبطال الجلسة من قواعد بياناته.
