A01:2021 – تخطي صلاحيات الوصول

العوامل

ربطها مع CWEs	الحد الأقصى للحدوث	متوسط معدل الحدوث	التغطية القصوى	متوسط معدل التغطية	متوسط استغلال الثغرات	متوسط التأثير	إجمالي التكرار	إجمالي نقاط الضعف CVEs
34	55.97%	3.81%	94.55%	47.72%	6.92	5.93	318,487	19,013

نظرة عامة

صعد هذا المعيار من المركز الخامس في الإصدار السابق إلى الأول في هذا الإصدار بعد اختبار ثغرات "تخطي صلاحيات التحكم بالوصول" على 94% من التطبيقات وقد لوحظ أنها تعاني من نقاط الضعف الشائعة "CWEs” تشمل : CWE-200 و CWE-201 و CWE-352

الوصف

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

تجاوز إجراءات التحقق من التحكم في الوصول من خلال تعديل محدد فيURL، او تعديل الكائنات “objects” المرتبطة بالبرنامج داخل الذاكرة أو تعديل صفحة الـ HTML، أو ببساطة استخدام أداة هجوم مخصصة لمهاجمة API
السماح بالتبديل بين مفتاح رئيسي “primary key” وسجلات مستخدم آخر “users record”، مما قد يسمح باستعراض أو التعديل على حسابات أخرى
تصعيد الصلاحيات: التصرف كمستخدم من دون تسجيل الدخول او التصرف كمدير عند تسجيل الدخول بصلاحيات كمستخدم.
التلاعب في البيانات الوصفية "meta data” كإعادة إدخال أو التلاعب برمز التوثيق "JSON Web Token (JWT)،" أو التلاعب في ملفات الارتباط أو الحقول المخفية لغرض تصعيد الصلاحيات أو إساءة استخدام الـ JWT
التهيئة الغير صحيحة لـ CORS تسمح بالدخول الغير مصرح به لواجهة برمجة التطبيقات API.
استعراض صفحات "تستلزم المصادقة" عبر مستخدمين "غير مصادق عليهم" أو الوصول الى صفحات ذات امتيازات عليا باستخدام صلاحيات “حساب مستخدم “، أو الوصول الى واجهة برمجة التطبيقات "API” بوجود قصور في "التحكم في صلاحيات الوصول" مما يؤدي الى تنفيذ طلباتPOST، PUT، DELETE.

كيفية الحماية منها

يكون "التحكم بصلاحيات الوصول" فعالا فقط عندما عند تطبيقه على الشفرة المصدرية من جهة الخوادم الموثوقة- trusted server-side code، أو الخوادم التي لا تملك واجهة برمجة تطبيقات والتي يطلق عليها (server-less API)، حيث لا يستطيع المهاجم تعديل "صلاحيات التحكم بالوصول" أو التلاعب في البيانات الوصفية.

باستثناء طلبات الوصول "للموارد المتاحة للعامة" يتم حظر جميع الطلبات بشكل افتراضي.
وضع الأليات التي تتحكم بالوصول لمرة واحدة في البرنامج/التطبيق مع إعادة استخدامها -هي نفسها- عند الحاجة، وأيضا تقليل استخدام CORS.
نموذج التحكم بالوصول يجب أن يفرض مُلكية السجل " record ownership" بدلًا من الموافقة على أن المستخدم يستطيع إنشاء، قراءة، تحديث، أو حذف أي سجل.
متطلّبات حدود تطبيقات الأعمال الفريدة من نوعها "Unique application business limit" يجب أن يتم فرضها خلال استخدام نماذج المجال (domain models).
تعطيل استعراض مجلدات خادم الويب والتأكد بأن ملف البيانات الوصفية "Meta Data” وملفات النسخ الاحتياطي لا يتم الوصول اليها من خلال مجلد المسار الرئيسي "Root".
توثيق سجلات فشل التحكم في صلاحيات الوصول وتنبيه المسؤولين عند وقوع هذه الأخطاء.
تقييم حد الوصول إلى واجهة برمجة التطبيقات API ووضع حد لمعدّل الطلبات لتقليل الضرر الناجم عن أدوات الهجوم الآلي.
يجب التخلص من رموز JWT على الخادم بعد تسجيل الخروج.

يجب على فرق المطوّرين وموظفين قسم ضمان الجودة "QA" أن تتضمّن وحدة فعالة للتحكم في الوصول وإجراء اختبارات التكامل .

أمثلة على سيناريوهات الهجوم

سيناريو #1: يستخدم التطبيق بيانات لم يتم التحقق منها في استدعاء SQL التي بدورها تصل الى معلومات الحساب:

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

ببساطة يقوم المهاجم بتعديل browser's 'acct' parameter لأرسال أي رقم حساب يريده. وإذا لم يتم التحقق منه بشكل صحيح، يستطيع المهاجم الوصول لأي حساب مستخدم.

https://example.com/app/accountInfo?acct=notmyacct

سيناريو #2: : ببساطة يجبر المهاجم المتصفحات على زيارة العناوين الـ URLsالمستهدفة. والتي لا يستطيع الوصول اليها الا بصلاحيات المسؤول.