Skip to content

API1_BOLA.md

Latest commit

 

History

History
204 lines (104 loc) · 12.2 KB

API1_BOLA.md

File metadata and controls

204 lines (104 loc) · 12.2 KB
Raw

🌐 API1:2023 - Broken Object Level Authorization (BOLA)

📌 1. Definition (تعريف الثغرة)

تحدث هذه الثغرة عندما لا يتحقق الـ API من أن المستخدم الذي يطلب "كائن" معين (Object) لديه الصلاحية للوصول إليه. يعتمد الـ API غالباً على معرف الكائن (ID) الذي يرسله المستخدم في الرابط (URL)، وإذا لم يكن هناك فحص دقيق، يمكن للمستخدم الوصول لبيانات غيره بمجرد تغيير الـ ID.

🧠 Real-World Analogy (مثل واقعي لفهم الثغرة)

تخيل أنك ذهبت إلى المطعم 🍔:

  1. طلبت وجبتك، وأعطاك الموظف رقم طلب (7) وقال لك: "انتظر حتى يجهز طلبك".

  2. أنت جلست على الطاولة، وشفت ورقة صغيرة مكتوب عليها رقم طلبك (7).

  3. فجأة، خطرت لك فكرة! مسحت الرقم (7) وكتبت بدلاً منه (8).

  4. ذهبت للموظف وقلت له: "أعطني هذا الطلب".

  5. الموظف نظر للورقة، ورأى رقم (8)، فذهب وأحضر لك وجبة الشخص الآخر (الذي طلب رقم 8) وأعطاك إياها بدون ما يتأكد من هويتك أو يطلب منك الفاتورة الأصلية!

👉 هذه هي ثغرة BOLA:

  • 👨‍💻 أنت: المخترق (تلاعبت بالـ ID).

  • 🌐 المطعم (الموظف): هو الـ API (نفذ الطلب بناءً على الرقم فقط).

  • ⚠️ المشكلة: الموظف وثق في "الرقم" الذي أعطيته إياه ولم يتأكد هل أنت فعلاً صاحب الطلب رقم 8 أم لا.

🧩 2. Types (أنواع الثغرة)

🔢 1. التلاعب بالمعرفات الرقمية (Simple Numeric IDs)

هذا هو النوع الأسهل والأكثر شيوعاً. المعرفات تكون عبارة عن أرقام متسلسلة.

  • المثال: GET /api/orders/1001 ← يغيرها الهكر إلى 1002.

  • 🎯 الهدف: سحب بيانات الطلبات لجميع العملاء عبر سكربت بسيط.

🧬 2. التلاعب بالـ UUIDs/GUIDs (The "Hidden" ID)

يعتقد المبرمج أن استخدام UUID (مثل 550e8400-e29b-41d4-a716-446655440000) يحمي من BOLA لأن تخمينه مستحيل.

  • ⚠️ الثغرة: الهكر لا يخمن الـ UUID، بل يبحث عنه في أماكن أخرى (مثل رابط بروفايل المستخدم العام، أو في سجلات الـ API المسربة). بمجرد حصوله على الـ UUID، يجربه في Endpoints حساسة.

🔗 3. التلاعب بمصادر البيانات المتعددة (Multi-Object BOLA)

أحياناً الـ API يتأكد من صاحب الحساب، لكنه ينسى التأكد من "الأشياء" التابعة للحساب.

  • المثال: حسابك (User 5) يطلب عرض فاتورة (Invoice 99). الـ API يتأكد أنك (User 5)، لكنه لا يتأكد أن (Invoice 99) تتبع لك فعلاً!

🎭 4. التلاعب بالـ Methods (The Action Swap)

أخطر أنواع BOLA هو الذي يسمح بتغيير الحالة وليس فقط القراءة.

  • المثال:

    • GET /api/posts/50 ← مسموح للجميع (رؤية المنشور).

    • DELETE /api/posts/50 ← يجب أن يكون لصاحب المنشور فقط.

  • ⚠️ الثغرة: إذا لم يفحص الـ API الصلاحية عند استخدام DELETE أو PUT (تعديل)، يمكن لأي شخص حذف منشورات الآخرين.

🔥 3. Impact (خطورة الثغرة)

تكمن خطورة BOLA في أنها تضرب "قلب" المنطق البرمجي، وتفتح أبواباً كان من المفترض أن تظل مغلقة للأبد. إليك الأسباب:

  • 🔓 تسريب بيانات ضخم (Massive Data Breach): بما أن الـ APIs مصممة للتعامل مع البيانات الخام (JSON/XML)، فإن ثغرة BOLA واحدة قد تسمح للمخترق بسحب بيانات آلاف أو ملايين المستخدمين (مثل الإيميلات، العناوين، الأرقام السرية، والبيانات البنكية) عبر "سكربت" بسيط يغير الـ IDs بشكل آلي.

  • 🕵️ التجسس والخصوصية (Privacy Invasion): تخيل تطبيق محادثات أو تطبيقاً طبياً؛ ثغرة BOLA قد تسمح لشخص ما بقراءة رسائل خاصة أو سجلات طبية لا تخصه بمجرد معرفة "رقم الطلب"، مما يؤدي لكوارث قانونية وفقدان ثقة المستخدمين.

  • 🔨 التلاعب بالبيانات (Data Manipulation): الخطر لا يقتصر على "القراءة" فقط؛ فإذا كان الـ API يسمح بطلبات PUT أو DELETE دون فحص الصلاحية، يمكن للمخترق "تعديل" بيانات مستخدمين آخرين أو حتى "حذف" حساباتهم بالكامل!

  • 🛡️ تجاوز الحمايات التقليدية: كثير من الأنظمة الأمنية (مثل WAF) لا تكتشف BOLA بسهولة، لأن الطلب يبدو "شرعياً" تماماً؛ المستخدم مسجل دخول، والرابط صحيح، والصيغة سليمة. المشكلة "منطقية" في الكود وليست في شكل الطلب.

🛠️ 4. Discovery (كيف تكتشفها؟)

👥 1. استراتيجية الحسابين (The Two-Account Method)

هذه هي الطريقة الأكثر ضماناً ودقة:

  • 🌐 افتح متصفحين: سجل دخول بالحساب (A) في متصفح، وبالحساب (B) في متصفح آخر.

  • 🆔 استخرج المعرف (ID): من الحساب (A)، ابحث عن طلب API يجلب بيانات خاصة، مثل /api/v1/my-orders/777.

  • 💥 الهجوم: انسخ رابط الـ API الخاص بالحساب (A)، وحاول تشغيله باستخدام Token أو Cookie الحساب (B).

  • 🚨 النتيجة: إذا استجاب السيرفر وأعطاك بيانات الطلب 777 للحساب (B)، فأنت أمام ثغرة BOLA صريحة.

💎 2. التنقيب عن المعرفات المخفية (ID Mining)

أحياناً تكون الـ IDs صعبة التخمين (مثل UUIDs)، لذا ابحث عنها في:

  • 📜 ملفات JavaScript: ابحث عن روابط API قديمة أو مخفية في الكود الأمامي (Front-end).

  • 🌍 الاستجابات العامة: هل يعرض الموقع الـ ID الخاص بالمستخدمين في التعليقات أو في صفحة "من نحن"؟

  • 📱 Mobile Apps: إذا كان للتطبيق نسخة موبايل، افحص طلبات الـ API هناك، غالباً ما تكون الحماية فيها أضعف من نسخة الويب.

🔄 3. فحص كل الـ HTTP Methods

لا تكتفِ بطلب الـ GET (القراءة). جرب تغيير الـ Method على نفس الـ ID:

  • ✏️ جرب PUT /api/user/88 لتعديل بيانات غيرك.

  • 🗑️ جرب DELETE /api/user/88 لحذف حساب غيرك.

  • 🧠 المبدأ: "قد يحمي المبرمج القراءة، لكنه ينسى حماية الحذف والتعديل."

🤖 4. استخدام أدوات الأتمتة (Automated Fuzzing)

إذا كانت الـ IDs أرقاماً متسلسلة، استخدم أداة Intruder في Burp Suite:

  • 🎯 حدد مكان الـ ID في الرابط.

  • 🔢 اجعل الـ Payload أرقاماً متسلسلة (مثلاً من 100 إلى 200).

  • 📊 راقب الـ HTTP Status Code والـ Length. إذا كانت الأطوال متشابهة، فالسيرفر يسرب البيانات للكل.

🛡️ 5. Remediation (كيف تُصلح؟)

✅ 1. التحقق من الصلاحية على مستوى الكائن (Object-Level Authorization)

هذه هي القاعدة الذهبية. يجب أن يتحقق الكود برمجياً من أن المستخدم الحالي هو صاحب الحق في هذا الـ ID.

  • ❌ بدلاً من: SELECT * FROM orders WHERE id = $id

  • ✅ الصحيح: SELECT * FROM orders WHERE id = $id AND user_id = $current_user_id

  • 🛡️ هنا حتى لو غير الهكر الـ id لطلب فاتورة شخص آخر، السيرفر سيفشل في إيجاد النتيجة لأنها لا تتبع الـ user_id الخاص به.

🎲 2. استخدام المعرفات غير المتوقعة (Random UUIDs)

توقف عن استخدام الأرقام المتسلسلة (1, 2, 3) التي يسهل تخمينها وعمل "Fuzzing" لها.

  • 🧬 استخدم UUID v4 أو GUID. هذا يجعل من الصعب جداً على المخترق تخمين الـ ID الخاص بمستخدم آخر حتى لو كانت الثغرة موجودة منطقياً.

🔐 3. سياسة "أقل الصلاحيات" (Least Privilege)

  • 🚫 لا تمنح المستخدم صلاحية الوصول لأي Endpoint إلا إذا كان يحتاجه فعلياً.

  • 🔑 تأكد من أن الـ Token (مثل JWT) يحتوي على معلومات المستخدم بشكل مشفر ويتم التحقق منه في كل طلب قبل لمس قاعدة البيانات.

🏛️ 4. استخدام وظيفة فحص مركزية (Centralized Auth Logic)

بدلاً من كتابة كود التحقق في كل صفحة (مما يسهل نسيان بعض الصفحات)، استخدم "Middleware" أو وظيفة مركزية تقوم بفلترة الطلبات والتأكد من الصلاحيات قبل تمريرها للـ Controller.

🧪 5. اختبار الأمان المستمر (Continuous Testing)

  • 🧩 قم بإضافة "Integration Tests" في كود الـ Backend تحاكي محاولة وصول مستخدم لمورد لا يملكه.

  • 🔍 استخدم أدوات الـ DAST لفحص الـ APIs بشكل دوري لاكتشاف أي ثغرات منطقية تظهر بعد التحديثات.

🧠 6. Attacker Mindset (اسأل نفسك كمخترق)

المخترق المحترف في الـ API يعامل كل "ID" يراه كأنه مفتاح محتمل لغرفة شخص آخر. اسأل نفسك هذه الأسئلة:

  • 🔍 أين أجد الـ IDs الأخرى؟
    "إذا كان الموقع يستخدم UUID ولا يمكنني تخمينه، من أين يمكنني سرقته؟ هل يظهر في رابط البروفايل العام؟ هل يظهر في الـ Source Code الخاص بالصفحة؟ هل يظهر في تعليقات المستخدمين؟"

  • 🔄 ماذا لو استبدلت 'معرّفي' بـ 'معرّف الضحية'؟
    "أنا الآن أعدل بياناتي الشخصية والطلب يذهب إلى /api/v1/profile/update/105. ماذا يحدث لو أرسلت نفس الطلب لكن غيرت الرقم إلى 106؟ هل السيرفر سيسأل: 'هل 105 هو نفسه صاحب الجلسة (Session) الحالية؟' أم سينفذ الأمر فوراً؟"

  • 🎭 هل هناك 'تبادل أدوار'؟
    "أنا مستخدم عادي، والمدير (Admin) له ID. هل يمكنني استخدام الـ Endpoint الخاص بي للوصول لبيانات المدير؟ أو العكس: هل يمكنني استخدام Endpoint مخصص للمديرين وتمرير الـ ID الخاص بي فيه للحصول على صلاحيات أعلى؟"

  • 🧪 هل الفحص يتم في 'البداية' فقط؟
    "الموقع منعني من رؤية صفحة الطلبات الخاصة بغيري عبر المتصفح (Front-end). لكن، ماذا لو أخذت رابط الـ API المباشر واستدعيته عبر Burp Suite أو Postman؟ هل الحماية موجودة في 'الشكل الخارجي' فقط أم في 'قلب السيرفر'؟"