اختبار إدارة الجلسات

لماذا يهم

في نظر الخادم، من يرسل معرّف جلسة صالحاً هو المستخدم المسجّل الدخول، بلا كلمة مرور ولا عامل تحقق ثانٍ. لذا فإن المعرّف الذي يمكن توقّعه أو زرعه أو تسريبه، أو الذي لا ينتهي أبداً، يحوّل تسجيل دخول قوياً إلى تسجيل دخول ضعيف.

ولا تظهر هذه العيوب في الاختبار الوظيفي، لأن رحلة المستخدم نفسه تعمل. ولا تكشفها إلا اختبارات مصممة لها، وأغلبها رخيص: ملفّان شخصيان للمتصفح وأدوات المطوّر وحساب اختبار. ويخصص دليل OWASP لاختبار أمان الويب (WSTG) فئة كاملة لاختبارات إدارة الجلسات، وهذا الدرس يحوّل أهمها إلى شروط اختبار تنفّذها في كل إصدار.

دورة حياة الجلسة نموذجاً للحالات

في درس ملفات تعريف الارتباط والجلسات في HTTP تتبّعت جلسة واحدة يدوياً. أما خطة الاختبار الأمني فيجب أن تغطي كل طريقة تبدأ بها الجلسة وتتغير وتنتهي، ونموذج الحالات، كما في اختبار انتقالات الحالة، يجعل ذلك مرئياً: لا جلسة، ثم جلسة مجهولة الهوية (تنشئها تطبيقات كثيرة قبل تسجيل الدخول)، ثم مسجّل الدخول، ثم خامل، ثم منتهية. وكل انتقال شرط اختبار.

وقاعدة واحدة تغطي النموذج كله: عند تسجيل الدخول، وعند كل تغيير في الصلاحيات، وعند كل طريقة تنتهي بها الجلسة، يجب أن يتوقف المعرّف القديم عن العمل على الخادم؛ ولا يبقى المعرّف نفسه إلا في الانتقال بين «مسجّل الدخول» و«خامل». والفحص واحد دائماً: احتفظ بنسخة من المعرّف القديم، وأعد إرساله بعد الانتقال، وتوقّع صفحة الدخول أو 401، لا بيانات المستخدم أبداً. أما القيم المتوقعة، مثل المهلتين والأحداث التي تُنهي الجلسات الأخرى، فتأتي من سياسة الجلسات لدى الفريق.

جرّبها: مولّد انتقالات الحالات

عشوائية المعرّف: ابحث عن البنية

تطلب ورقة OWASP المرجعية لإدارة الجلسات (Session Management Cheat Sheet) معرّفات يولّدها مولّد عشوائي آمن تشفيرياً بإنتروبيا لا تقل عن ⁦64⁩ بت، بينما يطلب الإصدار ⁦5.0⁩ من معيار OWASP للتحقق من أمان التطبيقات (ASVS) ⁦128⁩ بت على الأقل، فاعتمد الحد الأدنى الذي تتبنّاه سياسة فريقك. لا يمكنك إثبات العشوائية بالنظر، لكنك تستطيع أن تجد البنية التي تنفيها. سجّل الدخول نحو ⁦20⁩ مرة بحساب اختبار وبضع مرات بحساب آخر، ودوّن كل معرّف مع وقته، ثم رتّب المعرّفات بعضها تحت بعض.

• الطول لا يعطي إلا حداً أعلى: ⁦32⁩ محرفاً ست عشرياً تحمل ⁦128⁩ بت على الأكثر. فإذا لم يتغير ⁦24⁩ منها أبداً، فالمحارف ⁦8⁩ الباقية تحمل ⁦32⁩ بت على الأكثر، أي أقل من الحد الأدنى.
• البادئة التي تشترك فيها كل القيم، أو الجزء الذي يزيد بواحد عند كل تسجيل دخول، عدّاد وليس عشوائية.
• فكّ ترميز القيمة كـBase64، وحوّل الأرقام الطويلة كطوابع زمنية Unix (عدد الثواني أو أجزاء الألف من الثانية منذ ⁦1⁩ يناير ⁦1970⁩ بالتوقيت العالمي UTC): فوجود رقم مستخدم أو بريد إلكتروني أو وقت الدخول داخلها يعني أن المعرّف مُركَّب لا عشوائي.
• يجب أن يعطي تسجيل الدخول الثاني للمستخدم نفسه قيمة مختلفة تماماً، وألا يظهر المعرّف أبداً في العناوين (URL) أو مصدر الصفحة أو رسائل الخطأ.
• هذه الفحوص تكشف البنية لكنها لا تثبت غيابها. فالتحليل الإحصائي لعيّنة كبيرة، بأداة مثل Sequencer في Burp Suite، عمل المتخصصين؛ وأقوى دليل أن مدير الجلسات المدمج في إطار العمل هو من يولّد المعرّف، وهو ما توصي به OWASP بدلاً من حلّ مصنوع داخلياً.

جرّبها: مفكّك ترميز Base64 جرّبها: محوّل الطوابع الزمنية

مثال تطبيقي: اختبار تثبيت الجلسة

في تثبيت الجلسة يزرع المهاجم معرّفاً بدلاً من أن يسرقه: يحصل على معرّف صالح قبل الدخول، ثم يوصله إلى متصفح الضحية، مثلاً عبر رابط يحمله في العنوان أو ملف تعريف ارتباط يُضبط من نطاق فرعي شقيق، وينتظر تسجيل الدخول. فإذا أبقى التطبيق ذلك المعرّف، صارت نسخة المهاجم مسجّلة الدخول.

الإعداد: بوابة موظفين https://hr.example في بيئة اختبار، وحساب اختبار واحد، وملفّان شخصيان للمتصفح (browser profiles): A للمهاجم وB للموظف. لا تختبر إلا أنظمة تملكها أو لديك إذن مكتوب باختبارها. يُظهر التتبّع زيارة A، ثم دخول B بعد ضبط ملف تعريف الارتباط يدوياً، ثم إعادة الإرسال من A.

• في A افتح صفحة الدخول وانسخ قيمة sid السابقة للدخول. وفي B اضبط sid على تلك القيمة من لوحة التخزين في أدوات المطوّر، ثم سجّل الدخول.
• المتوقع: تضبط استجابة الدخول قيمة sid جديدة، وإعادة تحميل /dashboard في A تنتهي بصفحة الدخول. فإن رأى A لوحة تحكم الموظف فالجلسة مثبَّتة: اقترح الخطورة حرج (Critical).
• كرّر الاختبار بقيمة لم يصدرها الخادم قط، مثل sid=tester-made-0001. مدير الجلسات الصارم (strict) يتجاهلها ويصدر قيمته، أما الذي يقبلها فتسميه OWASP متساهلاً (permissive). أبلغ عن ذلك حتى لو ظل التجديد يحمي تسجيل الدخول.
• كرّر الاختبار عند كل تغيير في الصلاحيات: إعادة المصادقة قبل إجراء حساس، وتبديل الدور أو المؤسسة، ودخول مستخدم آخر من المتصفح نفسه. وحين تنتقل الجلسة في ملف تعريف ارتباط، يجب تجاهل أي معرّف في العنوان، مثل ?sid= أو ;jsessionid=.

GET /login HTTP/1.1
Host: hr.example

HTTP/1.1 200 OK
Set-Cookie: sid=Pq7Lm2Vx9Rt4Kw8N; Path=/; Secure; HttpOnly; SameSite=Lax

POST /login HTTP/1.1
Host: hr.example
Cookie: sid=Pq7Lm2Vx9Rt4Kw8N

HTTP/1.1 303 See Other
Location: /dashboard
Set-Cookie: sid=Zc4Hn8Tq1Wy6Bd3F; Path=/; Secure; HttpOnly; SameSite=Lax

GET /dashboard HTTP/1.1
Host: hr.example
Cookie: sid=Pq7Lm2Vx9Rt4Kw8N

HTTP/1.1 302 Found
Location: /login

جرّبها: مولّد أوامر cURL

المهلات وتسجيل الخروج: كل طريقة يجب أن تنتهي بها الجلسة

تعرف من قبل كيف تختبر المهلتين بالقيم الحدّية، وكيف تعيد إرسال المعرّف بعد تسجيل الخروج. وعلى المستوى الأمني اختبر أيضاً ما يُبقي الجلسة حية دون قصد، وكل حدث يجب أن ينهيها. ودوّن وقت كل طلب: ساعة الخادم هي التي تحكم لا الصفحة.

• حركة الخلفية: اترك صفحة تستطلع الخادم دورياً (polling)، كعدّاد الإشعارات، خاملة إلى ما بعد الحد. فإن عُدّ الاستطلاع نشاطاً فلن تنتهي الجلسة بالخمول أبداً؛ اسأل هل هذا مقصود.
• نوافذ التحذير: يجب أن يمدّد زر «البقاء مسجّلاً الدخول» الجلسة على الخادم، وأن يُنهيها تجاهل التحذير هناك، لا أن يخفي الصفحة فقط. ولا يمدّد أي نشاط المهلة المطلقة.
• التبويبات والأجهزة: تسجيل الخروج في تبويب واحد يُنهي الجلسة في كل التبويبات، و«تسجيل الخروج من جميع الأجهزة» يُنهي الجلسة في ملف شخصي ثانٍ للمتصفح أيضاً.
• تغيير كلمة المرور: يتوقع معيار ASVS خياراً لإنهاء كل الجلسات الأخرى بعد تغيير أي عامل مصادقة، مثل تغيير كلمة المرور، بما في ذلك التغيير عبر استعادة كلمة المرور، أو تحديث إعدادات المصادقة متعددة العوامل (MFA). ويتوقع أيضاً أن تنتهي كل جلسات الحساب المعطَّل أو المحذوف؛ واسأل ماذا تقول السياسة عن الأدوار المسحوبة.
• كل بيانات الاعتماد: يجب أن يتوقف عن العمل عند تسجيل الخروج أيضاً ملف تعريف ارتباط «تذكّرني» (ملف دائم يعيد تسجيل دخول المستخدم دون كلمة المرور)، ورمز التحديث (refresh token)، وهو رمز طويل العمر يُستخدم للحصول على رموز وصول جديدة، ورمز الوصول (access token) في تطبيقات الصفحة الواحدة. أعد إرسال كل واحد منها.
• بعد تسجيل الخروج قد يعرض زر «رجوع» صفحة من سجل المتصفح. هذه مسألة تخزين مؤقت؛ أعد التحميل أو انقر أي شيء، ويجب أن يجيب الخادم بصفحة الدخول.

السمات على كل ملف تعريف ارتباط يحمل الجلسة

تعرف الحد الأدنى لملف تعريف ارتباط الجلسة: Secure وHttpOnly وSameSite صريحة، بلا Domain واسع، وبلا Expires أو Max-Age. والسؤال الأمني هو التغطية: هل يستوفيه كل ملف تعريف ارتباط يستطيع التصرف باسم المستخدم، في كل استجابة تضبطه؟

• ملفات تعريف الارتباط التي تحمل قدرة الجلسة: معرّف الجلسة، وملف «تذكّرني»، ورمز تحديث محفوظ في ملف تعريف ارتباط، وأي ملف تعريف ارتباط ثانٍ للجلسة من إطار عمل آخر أو من مكوّن الدخول الموحّد (SSO).
• الاستجابات التي تضبطها: تسجيل الدخول، والتجديد بعد تغيير الصلاحيات، وتحديث الرمز، والدخول مع «تذكّرني». فالتجديد الذي تكتبه شيفرة أخرى قد يُسقط سمات.
• بادئات الأسماء: لا تقبل المتصفحات ملفاً باسم __Host-sid إلا من صفحة HTTPS ومع Secure وPath=/ وبلا Domain، ولا تقبل ملفاً يبدأ بـ__Secure- إلا من صفحة HTTPS ومع Secure. فالاستجابة التي تُسقط سمة تُرفض عندئذ، ويظهر العيب خروجاً غير متوقع من الجلسة. كما تمنع البادئة __Host- نطاقاً فرعياً شقيقاً من زرع ملف الجلسة، فتسدّ أحد طرق التثبيت.
• بيئة اختبار بلا HTTPS لا تستطيع إظهار عمل Secure؛ افحص مرة واحدة في بيئة مهيّأة مثل بيئة الإنتاج.
• تقلّل السمات سرقة ملف تعريف الارتباط وإساءة استخدامه، لكنها لا تصلح معرّفاً يمكن توقّعه، ولا تجديداً مفقوداً، ولا تسجيل خروج يترك جلسة الخادم حية.

جرّبها: محلّل ملفات تعريف الارتباط (Cookies)

أسئلة شائعة

المراجع

• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• OWASP Cheat Sheet Series: Session ManagementOWASP Foundationإنتروبيا معرّف الجلسة وسمات ملف تعريف الارتباط والانتهاء والتجديد بعد تسجيل الدخول ومعالجة تسجيل الخروج.
• OWASP Application Security Verification Standard (ASVS)OWASP Foundationقائمة تحقق بمتطلبات أمنية قابلة للتحقق لتطبيقات الويب، مصنّفة في ثلاثة مستويات ضمان.
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)عمر ملف تعريف الارتباط ونطاقه وسمات Secure/HttpOnly/SameSite وآثارها الأمنية.