- بواسطة x32x01 ||
ثغرة IDOR (Insecure Direct Object Reference) من ثغرات التحكم في الوصول (Broken Access Control)، وبتسمح للمهاجم بالوصول إلى بيانات أو موارد خاصة بمستخدم تاني بسبب ضعف التحقق من صلاحيات الوصول.
في البوست ده هنتعرف على طريقة اكتشاف واختبار ثغرة IDOR عمليًا باستخدام Burp Suite، من خلال حل مجموعة من اللابات على منصة PortSwigger Web Security Academy، وتحليل طلبات HTTP واكتشاف الأخطاء اللي ممكن تكشف بيانات المستخدمين أو تسمح بالتحكم في حساباتهم.
مثلاً، لو المستخدم بيفتح بيانات حسابه من خلال الرابط:
وقدر يغير الرقم من
المشكلة هنا مش في تغيير الرقم نفسه، لكن في إن السيرفر سمح بالوصول للبيانات من غير التحقق من صلاحيات المستخدم.
بعد كده هنستخدم Burp Suite لمراقبة الطلبات المرسلة إلى السيرفر، ونختبر بعض القيم زي Username وUser ID لمعرفة هل التطبيق بيتحقق من صلاحيات الوصول بشكل صحيح ولا لأ.
كمان هنحلل استجابات السيرفر، لأن بعض التطبيقات ممكن تكشف بيانات حساسة داخل الـ Response حتى لو المستخدم اتعمله Redirect لصفحة تانية.
وده بيوضح ليه لازم نفحص الطلب والاستجابة بالكامل، مش نعتمد على اللي بيظهر في المتصفح بس.
🎬 شاهد الشرح العملي
شرح عملي لاكتشاف IDOR وحل اللابات باستخدام Burp Suite.
وإيه أكتر طريقة بتستخدمها لاكتشاف مشاكل Broken Access Control؟
شاركنا تجربتك في التعليقات، ولو بتتعلم Bug Bounty اكتب لنا أكتر حاجة بتواجهك أثناء اختبار تطبيقات الويب. 🚀
في البوست ده هنتعرف على طريقة اكتشاف واختبار ثغرة IDOR عمليًا باستخدام Burp Suite، من خلال حل مجموعة من اللابات على منصة PortSwigger Web Security Academy، وتحليل طلبات HTTP واكتشاف الأخطاء اللي ممكن تكشف بيانات المستخدمين أو تسمح بالتحكم في حساباتهم.
🔍 إيه هي ثغرة IDOR؟
ببساطة، بتحصل ثغرة IDOR لما التطبيق يعتمد على قيمة زي User ID أو Username لتحديد البيانات المطلوبة، من غير ما يتأكد إن المستخدم الحالي عنده صلاحية الوصول للبيانات دي.مثلاً، لو المستخدم بيفتح بيانات حسابه من خلال الرابط:
https://example.com/profile?id=100وقدر يغير الرقم من
100 إلى 101 ويشوف بيانات مستخدم تاني، فده ممكن يكون مؤشر على وجود ثغرة IDOR.المشكلة هنا مش في تغيير الرقم نفسه، لكن في إن السيرفر سمح بالوصول للبيانات من غير التحقق من صلاحيات المستخدم.
🎯 إيه اللي هتتعلمه في الفيديو؟
خلال التطبيق العملي هتتعلم:- فهم ثغرة IDOR وعلاقتها بـ Broken Access Control.
- الفرق بين Authentication وAuthorization.
- اختبار تغيير Username داخل HTTP Requests.
- تحليل User IDs واكتشاف المعرفات المكشوفة.
- استخدام Burp Suite لاختبار صلاحيات الوصول.
- تحليل HTTP Requests وResponses باستخدام Repeater.
- اكتشاف تسريب البيانات من خلال HTTP 302 Redirect.
- اختبار الوصول إلى بيانات مستخدمين آخرين باستخدام Session IDs.
- فهم تأثير ضعف الصلاحيات على حسابات المستخدمين.
- اختبار سيناريوهات الوصول إلى وظائف Admin داخل اللابات.
🛠️ الأدوات والمنصات المستخدمة
الأدوات اللي هنستخدمها في الشرح:- Burp Suite: لاعتراض وتحليل طلبات HTTP.
- Burp Repeater: لإعادة إرسال الطلبات وتعديلها واختبار استجابات السيرفر.
- Web Browser: للتفاعل مع تطبيق الويب.
- PortSwigger Web Security Academy: لتطبيق الاختبارات من خلال لابات تعليمية.
🧪 التطبيق العملي: اكتشاف ثغرة IDOR
هنبدأ بتحليل طريقة عمل صفحات المستخدمين، ونشوف إزاي التطبيق بيتعامل مع بيانات الحسابات المختلفة.بعد كده هنستخدم Burp Suite لمراقبة الطلبات المرسلة إلى السيرفر، ونختبر بعض القيم زي Username وUser ID لمعرفة هل التطبيق بيتحقق من صلاحيات الوصول بشكل صحيح ولا لأ.
كمان هنحلل استجابات السيرفر، لأن بعض التطبيقات ممكن تكشف بيانات حساسة داخل الـ Response حتى لو المستخدم اتعمله Redirect لصفحة تانية.
وده بيوضح ليه لازم نفحص الطلب والاستجابة بالكامل، مش نعتمد على اللي بيظهر في المتصفح بس.
🎬 شاهد الشرح العملي
💬 شاركنا تجربتك
هل سبق واكتشفت ثغرة IDOR أثناء اختبار تطبيق ويب؟وإيه أكتر طريقة بتستخدمها لاكتشاف مشاكل Broken Access Control؟
شاركنا تجربتك في التعليقات، ولو بتتعلم Bug Bounty اكتب لنا أكتر حاجة بتواجهك أثناء اختبار تطبيقات الويب. 🚀