A05:2021 – الإعدادات الأمنية الخاطئة

العوامل

ربطها مع CWEs	الحد الأقصى للحدوث	متوسط معدل الحدوث	التغطية القصوى	متوسط معدل التغطية	متوسط استغلال الثغرات	متوسط التأثير	إجمالي التكرار	إجمالي نقاط الضعف CVEs
20	19.84%	4.51%	89.58%	44.84%	8.12	6.56	208,387	789

نظرة عامة

بعد أن كان هذا التهديد في المرتبة السادسة في الإصدار السابق لعام 2017 الآن نجده في المرتبة الخامسة، حيث أنه تم إجراء اختبار على %90 من البرامج والتطبيقات للتأكد إن كانت تحتوي على أيّة أخطاء في طريقة الإعدادات والتكوين الصحيحة، فليس من المُستغرب انتقال هذا التهديد من المرتبة السادسة إلى الخامسة. كذلك تم ضم "XML External Entities XXE" لهذا النوع من الإعدادات والتكوين الخاطئة. تضمن الـ CWEs التالية CWE-16 (Configuration), CWE-611 (Improper Restriction of XML External Entity).

الوصف

من المحتمل ان يكون التطبيق ضعيف امنياً إذا احتوى على النقاط التالية:

عدم مراجعة التكوين والضبط الآمن لإعدادات التطبيق أو في أي جزء من أجزاء التطبيق أو تكوين أذونات خاطئة في الخدمات السحابيّة.
تثبيت وإتاحة خدمات ومِيزات غير ضرورية (منافذ غير ضرورية، الخدمات، الصفحات، الحسابات، والصلاحيات).
تفعيل الحسابات الافتراضية أو عدم تغييرها أو عدم تغيير كلمات المرور الخاصة بها.
كشف رسائل معالجة الأخطاء (Error Handling) عن معلومات قابلة للتتبّع (Stack Traces) أو عرض رسائل الخطأ التي تحتوي على معلومات تفصيلية يمكن أن تُستغل من قِبل المستخدم.
تكون الميزات الأمنية الأحدث مُعطّلة أو لم يتم تكوينها بشكل آمن في الأنظمة التي تمت ترقيتها.
عدم تعيين إعدادات الأمان في خوادم التطبيقات وإطار التطبيقات على سبيل المثال (Struts, Spring, ASP.NET) والمكتبات وقواعد البيانات وما إلى ذلك إلى قيم آمنة.
لا يرسل أو يستخدم الخادم عناوين "Headers" عند نقل البيانات الحساسة للمتصفح أو عند تقديمها من قِبل المتصفح.
لم يعد البرنامج مدعومًا من قبل مزوّدي الخدمات أو ضعيف أمنيًا لاحتوائه على ثغرات أمنية (انظر إلى - A06:2021 الثغرات والأنظمة الغير قابلة للتحديث).

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

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

يجب تطبيق آلية آمنة لتكوين البرامج أو الأجهزة، تشمل على:

تكرار عملية مراجعة التكوين الآمن، والذي سيؤدي إلى تسريع وتسهيل مهمة إنشاء بيئة جديدة مكوّنة بشكل آمن. كما يجب أن يتم تكوين بيئات التطوير وضمان جودة وبيئة الإنتاج بشكل يتطابق مع استخدام كلمات مرور مختلفة في كل بيئة. أيضًا يجب أن تكون هذه العملية آلية للتقليل من الجهد المتطلّب عند إعداد بيئة جديدة وآمنة.
الاكتفاء بالحد الأدنى الأساسي من النظام أو المنصّة بدون تفعيل مِيزات، أو مكونات، أو وثائق، أو عيّنات غير ضرورية، مع حذف وإبطال الميزات وإطار الغير مستخدمة أو عدم تثبيتها.
مراجعة وتحديث الإعدادات بما يتناسب مع كافة ملاحظات الأمان والتحديثات والإصلاحات كجزء من عملية إدارة حِزم الإصلاحات والترقيات. (انظر إلى- A06:2021 الثغرات والأنظمة الغير قابلة للتحديثات). بالإضافة إلى مراجعة أذونات التخزين السحابيّة على سبيل المثال (S3 Bucket Permissions).
تتيح بنية التطبيق المقسّمة فصلًا فعّالًا وآمنًا بين المكونات، مع التجزئة في مجموعات أمان السحابة (ACLs).
إرسال توجيهات الأمان إلى المستخدمين على سبيل المثال Security Headers.
أتمتة عملية التحقق من التحديثات الآمنة للتحقّق من فعاليّة التكوينات والإعدادات في جميع البيئات.
تشغيل أدوات الفحص للتحقّق من فعاليّة التكوينات والإعدادات في جميع البيئات للكشف عن الإعدادات الخاطئة.

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

سيناريو #1: عندما يحتوي احد الخوادم على تطبيق من التطبيقات غير محدث وما يزال يُستخدم في بيئة الإنتاج "Production Server" هذه العيّنات من التطبيقات قد تحتوي على ثغرات أمنية يمكن أن يستخدمها المهاجم في اختراق الخادم ، وبافتراض أن أحد هذه البرامج هي وحدة تحكّم لإدارة الخادم وتحتوي على الاعدادات الافتراضية والرقم السري الافتراضي، في هذه الحالة فإن المهاجم سوف يُسجّل الدخول باستخدام الرقم السري الافتراضي ويتحكّم بالخادم.

سيناريو #2: عندما تكون قائمة الدليل "Directory Listing" غير معطّلة في الخادم الخاص بك، قد يكتشف المهاجم أن بإمكانه سرد قائمة الملفات المخزنة على الخادم وبعد ذلك بإمكانه العثور وتثبيت جميع فئات جافا (Compiled Java Classes) ومن ثم يقوم بفكّها وتطبيق الهندسة العكسية لعرض الشّفرة المصدرية، سوف يحاول المهاجم بعد ذلك إيجاد خطأ أمني للتحكّم في الوصول إلى الخادم.

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

سيناريو #4: أن يكون مقدّم الخدمة السحابيّة لديه أذونات مشاركة افتراضية مفتوحة على الإنترنت من قِبل مستخدمي CSP الآخرين، يسمح هذا بالوصول إلى البيانات الحساسة المخزّنة في سحابة التخزين.