آسیب‌پذیری IDOR چیه؟
آسیب‌پذیری IDOR یا Insecure Direct Object Reference که زیرمجموعه‌ای از آسیب‌پذیری‌های کنترل دسترسیه ، زمانی اتفاق می‌افته که یه API طوری طراحی شده باشه که با استفاده از شناسه‌های قابل حدس، مثل یوزرنیم یا عددهای افزایشی (مثلاً 123)، امکان دسترسی به اطلاعات رو بده.
یعنی اگر من یوزر 123 هستم و به اطلاعات خودم دسترسی دارم، بتونم با تغییر عدد به 124، اطلاعات یوزر بعدی رو هم ببینم.
حالا تصور کنید این مسئله فقط برای خوندن داده‌ها نباشه؛ یه متد update هم وجود داشته باشه که با گرفتن همون ID اطلاعات رو تغییر بده. این‌جوری مهاجم نه‌تنها می‌تونه اطلاعات بقیه رو ببینه، بلکه حتی می‌تونه تغییرشون هم بده.
با وجود این که خیلی‌هامون با این مسئله آشناییم، IDOR هنوز هم جزء آسیب‌پذیری‌های خیلی رایج محسوب میشه و توی پروژه‌های زیادی دیده میشه. (+ )(+ )
راه حل جلوگیری از آسیب‌پذیری IDOR
برای کاهش احتمال رخداد این آسیب‌پذیری چندین راه مختلف وجود داره که اینجا شرح داده میشه.
راه حل ۱: استفاده از شناسه‌های غیرقابل پیش‌بینی
اولین چیزی که به ذهن می‌رسه استفاده از شناسه‌های غیرقابل پیش‌بینیه؛ مثلاً UUID. این‌جوری دیگه مهاجم نمی‌تونه حدس بزنه که یوزر بعدی کیه. اما این راه‌حل کامل نیست.
درسته که دیگه نمی‌شه با یه اسکریپت ساده یا تغییر دستی آیدی‌ها به اطلاعات بقیه رسید، ولی اگه مهاجم به یه لیست از UUIDها دسترسی پیدا کنه (مثلاً از طریق ایندکس‌های دایرکتوری یا ابزارهایی مثل gau)، همچنان می‌تونه از API سوءاستفاده کنه. استفاده‌ی صرف از UUID حتی ممکنه توهم امنیت ایجاد کنه و باعث شه مشکل برای مدت طولانی کشف نشه.
راه حل ۲: تعیین سطوح دسترسی
راه‌حل بهتر، اضافه کردن ولیدیشن و authorization قبل از دسترسی به اطلاعاته. اگه قراره کاربری بتونه به اطلاعاتی دسترسی داشته باشه یا تغییری روش اعمال کنه، باید توی کد بررسی کنیم که آیا کاربر احراز هویت‌شده مجاز به دسترسی به اون داده هست یا نه.
مثلاً اگه یوزری لاگین کرده و تلاش می‌کنه اطلاعاتی شخصی رو تغییر بده، مطمئن بشیم که user_id اون رکورد مربوط به خودشه.
من بیشتر این یادداشت‌ها رو در کانال تلگرام می‌نویسم و اگر این نوشته رو خوندین احتمالاً باقی نوشته‌های کانال هم به کارتون خواهد اومد و پیشنهاد می‌کنم عضو بشید.