كيف تحدّدون أدوار الوصول لتطبيق أعمال صغير

ابدأوا بالإجراءات لا بالمسمّيات الوظيفية

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

ثم دوّنوا السجلات التي يمسّها كل إجراء. رؤية اسم العميل ليست كرؤية سجل مدفوعاته، وينبغي أن يُظهر الجدول هذا الفرق.

قائمة تحقق لتخطيط الأدوار

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

• الإجراء بعبارة فعلية بسيطة
• السجلات التي يمسّها
• الأدوار التي يحق لها تنفيذه
• هل هو مقتصر على سجلات الشخص نفسه
• هل يحتاج إلى موافقة شخص ثانٍ
• من يملك قرار تغيير هذه القاعدة

اجعلوا النسخة الأولى صغيرة

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

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

ارفضوا افتراضياً وامنحوا أقل ما يلزم

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

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

تعاملوا مع الإجراءات الحسّاسة على حدة

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

• تصدير كل السجلات أو قائمة العملاء كاملة
• حذف السجلات أو دمجها
• تغيير دور شخص أو دعوة مستخدم جديد
• الاطلاع على البيانات الشخصية لأشخاص خارج نطاق عمل المستخدم
• تغيير الأسعار أو المعدلات أو حدود الاعتماد

مثال توضيحي

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

سجلات الشخص نفسه فقط: فحص بمستخدمين اثنين

عندما تقول خلية في جدولكم «مسموح لسجلات الشخص نفسه فقط»، يجب أن يتأكد التطبيق عند كل طلب لسجل محدد من أن السجل يخص الشخص الطالب. تصف OWASP الإشارة المباشرة غير الآمنة إلى الكائن (Insecure Direct Object Reference) بأنها ذات ثلاثة مكونات: كائن مثل حساب أو مستند، ومرجع إليه مثل معرّف ID أو slug، وغياب فحص التفويض على مستوى الكائن. إن استبعاد سجلات الآخرين من قائمة ليس مثل رفض الطلب حين يقدّم أحدهم معرّف سجل آخر. وتنصح OWASP بالتحقق من صلاحية المستخدم في كل مرة تُجرى فيها محاولة وصول.

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

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

تحقّقوا من القواعد قبل الإطلاق

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

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