شرح Broken Access Control وتغيير الصلاحيات

هل ممكن وظيفة بسيطة لتغيير البريد الإلكتروني تسمح للمستخدم بتغيير صلاحيات حسابه
والوصول إلى لوحة تحكم المدير (Admin Panel) ؟
الإجابة: أيوه، لو التطبيق مش بيتحقق بشكل صحيح من الحقول اللي المستخدم مسموح له يعدّلها، ممكن المهاجم يستغل وظيفة عادية زي تغيير الإيميل علشان يغيّر صلاحيات حسابه. وده أحد السيناريوهات المهمة في ثغرات Broken Access Control.

في الفيديو ده، هنحل اللاب الرابع من PortSwigger Web Security Academy، وهنشوف عمليًا إزاي نستخدم Burp Suite لتحليل الطلبات، واكتشاف الحقول غير المتوقعة، واختبار إمكانية تنفيذ هجوم Privilege Escalation.

---

🎥 شرح عملي: Broken Access Control - Lab 4​

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

🔍 هنتعلم إيه في الفيديو؟​

الشرح بيركز على فهم طريقة اكتشاف الثغرة، مش مجرد تغيير قيمة معينة علشان نحل اللاب.
هنغطي النقاط التالية:

• فهم مفهوم Roles وPermissions والفرق بينهم.
• تحديد الـ Endpoints المسؤولة عن تعديل بيانات الحساب.
• تحليل HTTP Requests وResponses باستخدام Burp Suite.
• اختبار وظيفة تغيير البريد الإلكتروني ومعرفة إذا كانت بتقبل حقول إضافية غير متوقعة.
• فهم دور الباراميتر roleid وتأثيره المحتمل على صلاحيات الحساب.
• اختبار إمكانية الوصول إلى Admin Panel بعد تعديل صلاحيات المستخدم.
• بناء منهجية واضحة لاختبار Broken Access Control أثناء اختبار اختراق تطبيقات الويب.

---

إزاي تغيير الإيميل ممكن يؤدي إلى Privilege Escalation؟​

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

مثال توضيحي:
لو التطبيق بيستقبل بيانات الحساب بصيغة JSON، ممكن الطلب الطبيعي يكون بالشكل التالي:

{
  "email": "user@example.com"
}

أثناء الاختبار، بنحاول نعرف إذا كان السيرفر بيقبل حقلًا إضافيًا متعلقًا بصلاحيات المستخدم:

{
  "email": "user@example.com",
  "roleid": 2
}

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

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

---

🛠️ استخدام Burp Suite لاكتشاف الثغرة​

خلال الفيديو، هنستخدم Burp Suite علشان نفهم التطبيق بيتعامل إزاي مع طلبات تعديل بيانات الحساب.
منهجية الاختبار بتعتمد على الخطوات التالية:

1. تسجيل الدخول بحساب مستخدم عادي داخل بيئة اللاب.
2. اعتراض طلب تغيير البريد الإلكتروني باستخدام Burp Proxy.
3. إرسال الطلب إلى Burp Repeater لتحليله.
4. مراجعة الباراميترات اللي بيستقبلها السيرفر.
5. اختبار إضافة أو تعديل الحقول المرتبطة بصلاحيات الحساب.
6. مقارنة استجابة السيرفر قبل التعديل وبعده.
7. التحقق من تأثير التغيير على صلاحيات المستخدم وإمكانية الوصول إلى Admin Panel.

الهدف من الخطوات دي إننا نفهم هل التطبيق بيفرض قواعد الصلاحيات على السيرفر فعلًا، ولا بيسمح للمستخدم بتعديل بيانات المفروض تكون محمية.

---

💡 إيه الدرس الأمني من اللاب؟​

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

علشان كده، من المهم اختبار:

• وظائف تعديل الملف الشخصي (Profile).
• طلبات تغيير البريد الإلكتروني.
• الحقول المرتبطة بالأدوار والصلاحيات.
• التحقق من صلاحية تعديل كل حقل على مستوى السيرفر.

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

---

🎯 مين يستفيد من الفيديو؟​

الفيديو مناسب لأي شخص بيتعلم Web Penetration Testing أو مهتم بمجال Bug Bounty، خصوصًا لو عنده معرفة أساسية بطلبات HTTP وعايز يتدرب على اكتشاف ثغرات التحكم في الوصول بشكل عملي.

الأدوات المستخدمة:

• Burp Suite.
• PortSwigger Web Security Academy.

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

💬 سؤال للنقاش:
وأنت بتختبر Broken Access Control، هل بتراجع وظائف تعديل بيانات الحساب وبتختبر إمكانية إضافة Parameters غير متوقعة، ولا بتركز بشكل أساسي على صفحات الإدارة والـ Endpoints المحمية؟
شاركنا تجربتك في التعليقات.