خنقتونا خنقتونا
random

آخر الأخبار

random
random
جاري التحميل ...

شرح ثغرة IDOR: كيف تصل لبيانات المستخدمين الآخرين؟ | الدليل الشامل 2025

 

شرح ثغرة IDOR: دليلك الشامل للوصول إلى ما لا يجب عليك رؤيته

مقدمة:

تخيل أنك سجلت الدخول إلى حسابك في أحد مواقع التجارة الإلكترونية لتتصفح طلباتك السابقة. لاحظت أن رابط الصفحة ينتهي بـ order_id=105. بدافع الفضول، قمت بتغيير الرقم إلى 106 وضغطت Enter. فجأة، ظهرت أمامك تفاصيل طلب شخص آخر بالكامل: اسمه، عنوانه، وماذا اشترى.

ما حدث للتو ليس سحرًا، بل هو استغلال ناجح لواحدة من أكثر ثغرات الويب شيوعًا وخطورة: IDOR أو Insecure Direct Object References.

في دليلنا السابق، غصنا في أعماق [ثغرة XSS](رابط مقال XSS). اليوم، سنستكمل سلسلتنا ونتناول ثغرة مختلفة تمامًا، ثغرة لا تتطلب أكوادًا معقدة، بل تتطلب فقط قوة الملاحظة والفضول.


الجزء الأول: مشكلة "المفتاح الرئيسي" - ما هي ثغرة IDOR ببساطة؟ (H2)

ثغرة IDOR هي ثغرة في آلية التحكم في الوصول (Access Control). تحدث عندما يثق تطبيق الويب بشكل أعمى في المُدخلات التي يقدمها المستخدم للوصول إلى بيانات أو "كائنات" (Objects) في قاعدة البيانات، دون التحقق مما إذا كان هذا المستخدم مصرّح له بالوصول إلى هذا الكائن تحديدًا.

تشبيه فندق المفتاح الواحد 

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

في عالم الويب، المفتاح هو المعرّف (ID) الذي ترسله (مثل user_id=123)، والأقفال هي برمجة الموقع التي تفشل في التحقق من هويتك قبل فتح الباب.


الجزء الثاني: الوجوه المتعددة لـ IDOR: الكشف مقابل التنفيذ

لا تقتصر ثغرات IDOR على كشف البيانات فقط، بل لها أشكال أكثر خطورة.

1. IDOR لكشف البيانات (Data Exposure) 

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

  • مثال: تغيير invoice_id=99 إلى invoice_id=100 في الرابط لعرض فاتورة عميل آخر.

2. IDOR لتنفيذ إجراءات (Performing Actions) 

هذا النوع يحولك من مجرد "متلصص" إلى "متحكم". يحدث عندما تستغل الثغرة لتنفيذ إجراءات نيابة عن مستخدمين آخرين.

  • مثال: في طلب POST لحذف تعليق، تجد پارامترًا مخفيًا comment_id=550. إذا قمت بتغييره إلى comment_id=551، فقد تتمكن من حذف تعليق شخص آخر.


الجزء الثالث: مسرح الجريمة - أين تبحث عن ثغرات IDOR؟ 

ثغرات IDOR يمكن أن تختبئ في أي مكان يتم فيه استخدام معرّف مباشر. إليك قائمة بأشهر أماكن الصيد:

  • پارامترات الـ URL: المكان الأكثر وضوحًا. example.com/users?id=123

  • نقاط نهاية الـ API (API Endpoints): شائعة جدًا في تطبيقات الهاتف والمواقع الحديثة. api.example.com/v1/messages/451

  • حقول النماذج المخفية (Hidden Form Fields): افتح دائمًا كود المصدر للصفحة (Ctrl+U) وابحث عن حقول مثل: <input type="hidden" name="account_id" value="123">.

  • أسماء الملفات: عند طلب ملفات، قد يكون اسمها معرّفًا مباشرًا. example.com/download?file=receipt-123.pdf


الجزء الرابع: حقيبة المحقق - تجهيز معملك لاكتشاف IDOR 

على عكس XSS، لا تحتاج إلى Payloads معقدة، لكنك تحتاج إلى إعداد منهجي.

القاعدة الذهبية: حسابان دائمًا 

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

استخدام البروكسي (Proxy) 

أداة مثل Burp Suite ضرورية. حتى لو كنت تختبر ID في الرابط فقط، فإن Burp Suite يسمح لك برؤية جميع الطلبات التي يرسلها متصفحك في الخلفية، بما في ذلك طلبات API التي قد تحتوي على ثغرات IDOR غير مرئية لك.


الجزء الخامس: التحقيق - منهجية منظمة لاختبار IDOR 

لا تختبر بشكل عشوائي. اتبع هذه الخطوات المنظمة:

  1. ارسم خريطة للتطبيق: سجل الدخول بالحساب A. تصفح كل جزء من الموقع: عدّل ملفك الشخصي، أرسل رسالة، أضف صديقًا، قم بطلب شراء.

  2. حدد كل المعرّفات: أثناء تصفحك، قم بتدوين كل مكان ترى فيه ID مباشرًا. سواء في الرابط، أو في طلب API، أو في حقل مخفي.

  3. ابدأ بتبديل المعرّفات: سجل الخروج من الحساب A وسجل الدخول بالحساب B.

  4. أعد إرسال الطلبات: ارجع إلى قائمة الطلبات التي جمعتها. ابدأ بإعادة إرسالها واحدًا تلو الآخر، ولكن في كل مرة، استبدل الـ ID الخاص بالحساب A بالـ ID الخاص بالحساب B.

  5. حلل النتائج: هل نجحت؟ هل تمكنت من رؤية بيانات الحساب B؟ هل تمكنت من تعديلها؟ قم بتوثيق كل خطوة ناجحة بالصور أو الفيديو.


الجزء السادس: أدلة متقدمة - التعامل مع المعرّفات المعقدة 

ماذا لو لم يكن الـ ID مجرد رقم بسيط 123؟

المعرّفات المجزأة (Hashed IDs) 

قد ترى أحيانًا معرّفًا يبدو عشوائيًا، مثل c4ca4238a0b923820dcc509a6f75849b. في كثير من الحالات، لا يكون هذا عشوائيًا، بل هو مجرد رقم بسيط تم تشفيره باستخدام MD5. الرقم في المثال السابق هو 1!

  • نصيحة احترافية: عندما تواجه Hashed ID، خذ أرقامًا بسيطة (1, 2, 3, 4, 5...) وقم بتشفيرها بنفس الخوارزمية (مثل MD5) وقارن النتائج. قد تتمكن من تخمين الـ ID الخاص بالأدمن.

المعرّفات الفريدة عالميًا (UUIDs) 

كإجراء دفاعي، تستخدم بعض المواقع UUIDs (مثل 123e4567-e89b-12d3-a456-426614174000). هذه المعرّفات طويلة جدًا وعشوائية ومن المستحيل تخمينها، مما يجعل هجمات IDOR التقليدية صعبة للغاية.


الجزء السابع: العواقب - التأثير الحقيقي لثغرة IDOR 

تتراوح خطورة IDOR من "عالية" إلى "حرجة"، ويمكن أن تؤدي إلى:

  • تسريب بيانات جماعي (Mass Data Leakage): عرض المعلومات الشخصية لآلاف أو ملايين المستخدمين.

  • السيطرة الكاملة على الحساب (Account Takeover): إذا كانت الثغرة موجودة في وظيفة تغيير البريد الإلكتروني أو كلمة المرور.

  • تصعيد الصلاحيات (Privilege Escalation): إذا تمكنت من الوصول إلى حساب له صلاحيات أعلى (مثل الأدمن) عن طريق تخمين الـ ID الخاص به (id=1 أو id=admin).

  • إجراءات غير مصرح بها: حذف بيانات، إرسال رسائل، أو إجراء عمليات شراء نيابة عن مستخدمين آخرين.


الجزء الثامن: بناء الخزنة - كيف يمنع المطورون ثغرات IDOR؟ 

الحل لمشكلة IDOR بسيط من الناحية النظرية ولكنه يتطلب تطبيقًا دقيقًا.

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

  • البرمجة الخاطئة (Vulnerable): "المستخدم يطلب الطلب رقم 551. هل قام المستخدم بتسجيل الدخول؟ نعم. إذًا، اعرض له الطلب رقم 551."

  • البرمجة الصحيحة (Secure): "المستخدم Ahmed يطلب الطلب رقم 551. هل قام Ahmed بتسجيل الدخول؟ نعم. والآن، تحقق في قاعدة البيانات: هل الطلب رقم 551 ينتمي بالفعل إلى المستخدم Ahmed؟ نعم. إذًا، اعرض له الطلب."

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


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


في دليلنا القادم، سنتعمق في وحش آخر من وحوش الويب، ثغرة SQL Injection التي يمكن أن تسمح للمهاجم بالسيطرة على قاعدة البيانات بأكملها. كن مستعدًا

والآن، شاركنا في التعليقات: ما هو السيناريو الأكثر إثارة للقلق الذي يمكن أن تتخيل حدوثه بسبب ثغرة IDOR؟

عن الكاتب

Mahmoud Salman

التعليقات


اتصل بنا

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

تابع المدونة من هنا

مواقيت الصلاة من هنا

مشاركة مميزة

شرح ثغرة SQL Injection: دليلك الكامل للسيطرة على قواعد البيانات | 2025

شرح ثغرة SQL Injection   شرح ثغرة SQL Injection: دليلك الكامل للسيطرة على قواعد البيانات مقدمة: تخيل أنك تستطيع خداع أمين الأرشيف في مكتبة ض...

جميع الحقوق محفوظة

خنقتونا