التخويل

حالة استخدام

في أي موقع ويب يحتوي على مستخدمين بمستويات مختلفة من القدرات (مثل المشاهدين مقابل المحررين) أو يحتوي على معلومات سرية للمستخدمين ومن المهم أن يحمي الموقع هذه الميزات و/أو هذه البيانات من الأشخاص الذين ليس لديهم إذن لاستخدام هذه الميزات و/أو التفاعل مع هذه البيانات.

الأهداف

بعد استكمال هذا الموضوع الفرعي، يجب أن يكون الممارسون قادرين على القيام بما يلي:

• فهم الأنواع الشائعة من ثغرات التخويل
• فهم الآثار المحتملة لهذه الأنواع من الثغرات
• فهم آليات عمل هذه الثغرات
• فهم كيفية منع ثغرات هذه بشكل عام

العرض

المعرفة الأساسية

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

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

لتسهيل التواصل حول الثغرات تُقسم ثغرات التخويل بشكل عام ضمن ثلاث فئات.

فقدان المصادقة

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

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

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

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

تصعيد الصلاحيات الرأسي

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

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

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

جرب بنفسك!

سجّل الدخول إلى دي في دبليو إيه الخاص بك وتأكد من تعيين مستوى الأمان بالمستوى المنخفض وأنك قمت بتسجيل الدخول كمسؤول (من الأفضل تسجيل الخروج وتسجيل الدخول مرة أخرى باستخدام بيانات الاعتماد “admin:password”. انتقل إلى صفحة “تجاوز التفويض (Authorisation Bypass)"، وإذا لم تتمكن من رؤية هذه الصفحة في الشريط الأيسر ولديك أحدث إصدار من دي في دبليو إيه فهذا يعني أنك لم تقم بتسجيل الدخول بصفة مسؤول.

بعد ذلك افتح نافذة تصفح خاصة أو متصفحًا آخر وسجل الدخول إلى دي في دبليو إيه الخاص بك بصفة مستخدم “gordonb” ولاحظ أن تجاوز التفويض لا يظهر في شريط التنقل في gordonb. هل يمكنك معرفة كيفية الوصول إلى تجاوز التفويض باسم gordonb؟ (إذا كنت تواجه مشكلة فتذكر أن ثغرات في التخويل واضحة للغاية بشكل عام ولا تفرط بالتفكير فيها.)

تصعيد الصلاحيات الأفقي

يحدث تصعيد الصلاحيات الأفقي عندما يتمكن المستخدمون من عرض أو تنفيذ إجراءات على بيانات المستخدمين الآخرين عندما يكون لدى هؤلاء المستخدمين الآخرين نفس مستوى الوصول.

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

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

الوقاية من ثغرات التخويل

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

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

لمزيد من المصادقة راجعورقة معلومات تخويل مشروع أمان تطبيق الويب المفتوح. ولأجل نظرة متعمّقة راجع مسار تعلّم تقييم أمان تطبيقات الويب..

الممارسة

اقرأ تقرير الثغرات هذا وتأكد من فهمك لثغرات المصادقة أو التخويل التي يتم استغلالها هنا.

اختبار مهارة

التمرين 1: ملخص

أكمل تمرين تجاوز تصريح دي في دبليو إيه كما هو موضح أعلاه.

التمرين 2: اختبار خيارات متعددة

السؤال 1. ما هو الغرض الأساسي من التخويل في النظام؟. أ) مصادقة المستخدمين ب) ضمان سلامة البيانات ج) التحقق من أذونات المستخدم د) تشفير المعلومات الحساسة

السؤال 2. ما هو الغرض الأساسي من التخويل في النظام؟.

أ) تصعيد الصلاحيات الرأسي ب) تصعيد الصلاحيات الأفقي ج) المصادقة المفقودة د) التصفح القسري

السؤال 3. ما هو النمط الشائع لثغرة المصادقة المفقودة المذكورة في نص الموضوع الفرعي؟

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

السؤال 4. ما هي نتيجة ثغرة تصعيد الصلاحيات الرأسي؟

أ) يمكن للمستخدمين الوصول إلى البيانات غير المصرح بها ب) يمكن للمستخدمين الأقل قوة تنفيذ إجراءات قوية لم يكونوا مخولين بالقيام بها ج) يمكن للمستخدمين تعديل بيانات المستخدمين الآخرين دون إذن د) يصبح الموقع بأكمله عرضة للهجمات

السؤال 5. في سياق تصعيد الصلاحيات الأفقي، ما هو السبب الشائع للثغرات وفقًا لنص الموضوع الفرعي؟

أ) نقص وعي المطور ب) التنفيذ غير المتسق للضوابط ج) تمرير معرّفات المستخدم في معلمات عنوان موقع الويب د) بروتوكولات التشفير غير كافية

السؤال 6. كيف يمكن للمطورين الوقاية من ثغرات التخويل وفقًا لنص الموضوع الفرعي؟

أ) استخدام منطق معقّد للتحقق من التخويل ب) الاعتماد فقط على دعم الإطار ج) تنفيذ الضوابط الخاصة بهم باستمرار د) تجاهل عمليات التحقق من الأذونات على مستوى البيانات

السؤال 7. أي مما يلي ليس نصيحة مذكورة في النص لمنع ثغرات التخويل؟

أ) تحديد طبقات وتبسيط عملية التحقق من أذونات المستخدم ب) استخدام مواقع منفصلة للمستخدمين العاديين والمسؤولين ج) الاعتماد فقط على وظائف الإطار للتخويل د) وضع مبادئ توجيهية متسقة للمطورين للوصول إلى البيانات

السؤال 8. ما هي أهمية الاتساق في تنفيذ ضوابط التخويل؟

أ) يزيد من تعقيد النظام ب) يقلل من احتمالية الأخطاء ج) يحد من الوصول إلى بعض المستخدمين د) يجعل عمليات التحقق من التخويل أكثر صعوبة

السؤال 9. ما هو أحد الأمثلة الواردة في نص الموضوع الفرعي لثغرة تصعيد الصلاحيات الرأسي؟

أ) تعديل معلمات عنوان موقع الويب لتصعيد الصلاحيات ب) السماح للمستخدمين بعرض بيانات المستخدمين الآخرين ج) تمرير معرّفات المستخدم في حقول النموذج المخفية د) وصول المستخدمين المنتظمين إلى الميزات الإدارية

السؤال 10. ما فئة الثغرات التي تتضمن قيام مستخدمين باتخاذ إجراءات تؤثر على بيانات مستخدمين آخرين بنفس مستوى الوصول؟

أ) المصادقة المفقودة ب) تصعيد الصلاحيات الرأسي ج) تصعيد الصلاحيات الأفقي د) التصفح القسري

التمرين 3 (اختياري، فقط لأولئك الذين يتعاملون بشكل مرن مع لغة بايثون الأساسية): تحدي العثور على الأخطاء في التعليمات البرمجية

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

# Import statement for print function (Python 3.x)
from __future__ import print_function

# User data (replace with your own test data)
users = {
    "admin": {"id": 1, "username": "admin", "permissions": ["read", "write", "delete"]},
    "user1": {"id": 2, "username": "user1", "permissions": ["read", "write"]},
    "user2": {"id": 3, "username": "user2", "permissions": ["read", "write"]},
}

# Function to simulate fetching a user's profile
def get_profile(username):
    if username not in users:
        return None
    return users[username]

# Function to simulate deleting a user's profile (vulnerable)
def delete_profile(username, current_user):
    if "write" in current_user["permissions"]:
        if username in users:
            del users[username]
            return f"User '{username}' deleted successfully."
        else:
            return f"User '{username}' not found."
    else:
        return "Permission denied: You do not have permission to delete users."

# Test cases (modify as needed)
current_user = users["user1"]  # Simulate a user with write permission
target_username = "user2"  # Simulate the target user

# Try to delete the victim's profile
result = delete_profile(target_username, current_user)

# Print the result (expected output: "Permission denied: You do not have permission to delete users.")
print(result)

ابحث عن الثغرة الأمنية في وظيفة “delete_profile” وأصلحها.

موارد التعلّم