القائمة الرئيسية

الصفحات

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

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

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


مقدمة

تُعرف OWASP إدارة الجلسة على النحو التالي:

أحد المكونات الأساسية لأي تطبيق مستند إلى الويب أو واجهة برمجة التطبيقات ذات الحالة هو الآلية التي يتحكم بها ويحافظ على حالة للمستخدم أو الجهاز الذي يتفاعل معها. تقوم إدارة الجلسة بتغيير حالة بروتوكول من stateless  إلى stateful ، وهو أمر بالغ الأهمية للتمييز بين المستخدمين أو الأجهزة المختلفة.


يجب أن يكون التطبيق يحتوي على متطلبات ادارة الجلسة الآتية :

• الجلسات فريدة لكل فرد ولا يمكن تخمينها أو مشاركتها.

• يتم إبطال الجلسات عند عدم الحاجة إليها وتنتهي مهلتها خلال فترات عدم النشاط.


الكوكيز

من أجل تأمين بيانات ملفات تعريف الارتباط ، تم تطوير وسائل للمساعدة في قفل ملفات تعريف الارتباط هذه والحد من سطح هجومها. بمرور الوقت ، أصبحت ملفات تعريف الارتباط آلية تخزين مفضلة لتطبيقات الويب ، لأنها تتيح مرونة كبيرة في الاستخدام والحماية.


فيما يلي قائمة بسمات الكوكيز وتقديم تعريفاتها:

  • Secure: تخبر السمة الآمنة المتصفح بإرسال الكوكيز فقط إذا تم إرسال الطلب عبر قناة آمنة مثل HTTPS. سيساعد هذا في حماية ملف تعريف الارتباط من المرور في الطلبات غير المشفرة.
  • HttpOnly: تُستخدم السمة HttpOnly للمساعدة في منع الهجمات مثل تسرب الجلسة لأنها لا تسمح بالوصول إلى ملفات الكوكيز عبر برنامج نصي من جانب العميل مثل JavaScript.
  • Domain: تُستخدم سمة الدومين لمقارنة دومين الكوكيز بكوكيز دومين الخادم الذي يتم تقديم طلب HTTP من أجله. إذا كان الدومين متطابقًا أو إذا كان نطاقًا فرعيًا ، فسيتم التحقق من سمة المسار بعد ذلك.
  • Path: تلعب سمة المسار دورًا رئيسيًا في تحديد نطاق ملفات تعريف الارتباط جنبًا إلى جنب مع الدومين. بالإضافة إلى الدومين، يمكن تحديد مسار URL الذي يكون ملف الكوكيز صالحًا له. إذا تطابق الدومين والمسار ، فسيتم إرسال ملف الكوكيز في الطلب. تمامًا كما هو الحال مع سمة الدومين، إذا تم تعيين سمة المسار بشكل مهمل للغاية ، فقد تترك التطبيق عرضة لهجمات التطبيقات الأخرى على نفس الخادم.
  • Expires: تُستخدم سمة انتهاء الصلاحية لتعيين ملفات الكوكيز الدائمة ، والحد من العمر الافتراضي للجلسة إذا استمرت الجلسة لفترة طويلة جدًا ، وإزالة ملف الكوكيز بالقوة عن طريق تعيينه بتاريخ سابق.
  • SameSite: تُستخدم سمة SameSite للتأكيد على أنه لا يجب إرسال ملف الكوكيز مع طلبات المواقع المشتركة. تتيح هذه الميزة للخادم التخفيف من مخاطر تسرب المعلومات عبر المصدر. في بعض الحالات ، يتم استخدامه أيضًا كإستراتيجية لتقليل المخاطر (أو آلية دفاع في العمق) لمنع هجمات cross-site request forgery.

منهجيات OWASP ASVS لاختبار إدارة الجلسة

1. اختبار لتثبيت الجلسة

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


كيفية الاختبار:

لاختبار تثبيت الجلسة للجلسات المتزامنة:

  • تسجيل الدخول باعتبارك مستخدم userA ولاحظ معرف الجلسة لهذا المستخدم.
  • قم بتسجيل الخروج ثم تسجيل الدخول باسم userB ولاحظ معرف الجلسة لهذا المستخدم.
  • لاحظ أن نفس معرف الجلسة يُستخدم للمستخدم التالي.

لاختبار تثبيت الجلسة لنفس الحساب:

  • تسجيل الدخول كمستخدم userA ولاحظ معرف الجلسة لهذا المستخدم.
  • تسجيل الخروج ثم تسجيل الدخول كمستخدم userA مرة أخرى ولاحظ هل يتغير معرف الجلسة.


نقاط الضعف:

  • تثبيت الجلسة للجلسات المتزامنة.
  • تثبيت الجلسة لنفس الحساب.

العلاج:

قم بتنفيذ تجديد الرمز المميز للجلسة بعد مصادقة المستخدم بنجاح.

يجب أن يقوم التطبيق دائمًا بإبطال معرف الجلسة الحالي أولاً قبل مصادقة المستخدم ، وإذا نجحت المصادقة ، فقم بتوفير معرف جلسة آخر.


2. اختبار وظيفة تسجيل الخروج

يعد إنهاء الجلسة جزءًا مهمًا من دورة حياة الجلسة. يؤدي تقليل عمر الرموز المميزة للجلسة إلى الحد الأدنى إلى تقليل احتمالية نجاح هجوم اختطاف الجلسة. يمكن النظر إلى هذا على أنه عنصر تحكم في منع الهجمات الأخرى مثل ثغرات XSS وCSRF. من المعروف أن مثل هذه الهجمات تعتمد على وجود مستخدم لديه جلسة مصادقة. يؤدي عدم وجود إنهاء جلسة آمن إلى زيادة سطح الهجوم لأي من هذه الهجمات.


كيفية الاختبار:

لاختبار ما إذا كانت الجلسة القديمة لا تُبطل بعد تسجيل الخروج:

  • تسجيل الدخول كمستخدم A
  • اعترض أحد الطلبات المصدق عليها وأرسلها إلى Burp Repeater.
  • تسجيل خروج
  • أرسل الطلب الذي تم اعتراضه في Burp Repeater مرة أخرى ولاحظ أن الجلسة لم يتم التحقق منها.

نقاط الضعف:

  • لا يتم إلغاء صلاحية الجلسة القديمة بعد تسجيل الخروج.

العلاج:

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



3. اختبار متغيرات الجلسة المكشوفة

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


كيفية الاختبار:

لاختبار ما إذا كان الرمز المميز يتم نقله عبر URL عبر طريقة GET:

  • تسجيل الدخول إلى التطبيق.
  • اعترض كل الطلبات باستخدام Burp.
  • لاحظ أن الرمز المميز يتم إرساله عبر URL في طلب GET.
  • قد يساعد هذا المهاجم على اختراق جلسة المستخدم بسهولة.

لاختبار ما إذا كان الرمز المميز قد تم إرساله عبر HTTP

  • اعترض الطلبات.
  • لاحظ أن الرمز المميز يتم إرساله عبر HTTP.

نقاط الضعف:

  • يتم إرسال الرمز المميز عبر URL (طريقة GET).
  • يتم إرسال الرمز المميز عبر HTTP.

العلاج:

  • تأكد من تنفيذ التشفير المناسب.
  • راجع تكوين التخزين المؤقت.
  • تقييم أمان القناة والأساليب.

4. اختبار مهلة انهاء الجلسة

في هذه المرحلة ، يتحقق المختبرين من أن التطبيق يسجل خروج المستخدم تلقائيًا عندما يكون هذا المستخدم خاملاً لفترة معينة من الوقت ، مما يضمن عدم إمكانية "إعادة استخدام" نفس الجلسة وعدم تخزين أي بيانات حساسة في ذاكرة التخزين المؤقت للمتصفح .

كيفية الاختبار:

  • قم بتسجيل الدخول باستخدام اسم المستخدم الخاص بك واترك علامة تبويب المتصفح مفتوحة لفترة طويلة.
  • لاحظ أن الجلسة لم يتم إنهاءها.

نقاط الضعف:

  • مهلة الجلسة طويلة جدًا.

العلاج:

يجب أن يقوم الخادم بإجراء فحوصات مناسبة على حالة الجلسة ، مما يمنع المهاجم من إعادة تشغيل معرفات الجلسة التي تم تدميرها مسبقًا.


5. اختبار مخطط إدارة الجلسة

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


كيفية الاختبار:

  • قم بإجراء طلب عادي على التطبيق.
  • ملاحظة هل يمكن فك تشفير الرمز المميز للجلسة أو تخمينه.

إذا لم يكن كذلك ، فاتبع خطوات الشبكة:

  • اجمع الرموز المميزة للجلسة ، لنفس المستخدم ولمستخدمين مختلفين حيثما أمكن ذلك.
  • قم بالتحليل والتأكد من وجود ما يكفي من العشوائية لإيقاف هجمات تزوير الجلسة.
  • تعديل ملفات الكوكيز غير الموقعة والتي تحتوي على معلومات يمكن التلاعب بها.

نقاط الضعف:

  • يمكن التنبؤ بالرمز المميز للجلسة / عشوائية منخفضة.
  • التلاعب بملف تعريف ارتباط الجلسة.


العلاج:

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


مقاومة العبث: يجب أن يقاوم ملف تعريف الارتباط محاولات التعديل الخبيثة. إذا كانت سمة ملف تعريف الارتباط شيئًا مشابهًا لـ isAdmin=No ، فمن السهل تعديلها للحصول على حقوق إدارية ، ما لم يقم التطبيق بإجراء فحص مزدوج (على سبيل المثال ، إلحاق ملف تعريف الارتباط بتجزئة مشفرة بقيمته).


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


Secure flag: يجب تمكين هذه العلامة في ملف تعريف الارتباط الذي تعتبر قيمته بالغة الأهمية لسلامة الجلسة للسماح بنقله فقط في قناة مشفرة لردع التنصت.


إذا كنت تبحث عن جولة تفصيلية أكثر حول إدارة الجلسة ، فاطلع على مقطع الفيديو الأخير الخاص بي:

reaction:

تعليقات