اختبار المصادقة والجلسات والصلاحيات: ثلاث طبقات لا تخلط بينها

سجلت الدخول بنجاح، ومع ذلك قدرت تشوف ملفًا ما يخصك. هل المشكلة في كلمة المرور؟ غالبًا السؤال في المكان الخطأ. المصادقة تثبت الهوية، والجلسة تربط الطلبات بتلك الهوية، والتحكم في الوصول يقرر ما الذي يسمح لها بفعله. فصل هذه الطبقات يساعدك تختار اختبارًا صحيحًا وتكتب إصلاحًا يعالج السبب.

المصادقة: هل الهوية تثبت بالطريقة المتوقعة؟

Authentication

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

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

الجلسة: كيف تستمر الهوية ومتى تنتهي؟

Session Management

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

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

خصائص الكعكات: افهم الحماية التي تقدمها كل واحدة

Secure
تقيد إرسال الكعكة إلى الاتصال الآمن في الاستخدام المعتاد.

HttpOnly
تمنع الوصول إلى الكعكة عبر واجهات برمجية مثل قراءة كعكات الصفحة من جافاسكربت؛ لكنها لا تعالج كل أثر محتمل لحقن الشفرة في الصفحة.

SameSite
تقيد إرفاق الكعكة في سياقات الطلبات بين المواقع وفق القيمة والسياق. تساعد في تقليل بعض مخاطر تزوير الطلبات، لكنها ليست بديلًا عامًا عن تصميم الحماية المناسبة.

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

الصلاحيات: من يستطيع فعل ماذا على أي مورد؟

Access Control

اختبر ثلاثة أبعاد على الأقل: الفصل بين أدوار مختلفة، والفصل بين مستخدمين في الدور نفسه، والفصل بين عملاء أو مؤسسات مستقلة. أضف حالة المورد عندما تؤثر في السياسة: مسودة، منشور، ملغى، أو مؤرشف. لا يكفي حساب مدير وحساب موظف لتمثيل كل هذه العلاقات.

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

المعرف غير القابل للتخمين لا يعوض التحقق من الصلاحية. وإخفاء الزر لا يمنع بالضرورة إرسال الطلب. الإصلاح يجب أن يربط هوية الطالب بالفعل والمورد والسياق داخل جهة موثوقة.

سيناريو يربط الطبقات الثلاث

موظف تجريبي سجل دخوله، ثم أُزيل من فريق يملك مساحة ملفات. هنا عندك عدة أسئلة مستقلة: هل تغيّر الدور في المصدر الصحيح؟ هل الجلسة القديمة تحتفظ بصلاحية لا ينبغي بقاؤها؟ هل خدمة الملفات تعيد التحقق من العضوية أم تعتمد على قرار سابق؟

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

مراجع للتوسع في الجلسات واختبار الصلاحيات:
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/02-Testing_for_Bypassing_Authorization_Schema/

ولربط هذه الحالات بخطة التطبيق كاملة، اقرأ:
https://courses.cyberpts.com/community/14/mnhjyh-akhtbar-ttbyq-wyb-khth-amlyh-tghty-alwzayf-whdwd-althqh