تحلیل آسیبپذیری IDOR و روشهای شناسایی و سوءاستفاده از آن
. هدف این مقاله
هدف این مقاله، ارائه یک بررسی جامع، رسمی و فنی از آسیبپذیری Insecure Direct Object Reference (IDOR) و مجموعه تهدیدات مرتبط با آن است.
1. آسیب پذیریIDOR یک زیرمجموعهی مهم از Broken Access Control است . چون با دستکاری شناسههای مستقیم، مهاجم میتواند محدودیتهای دسترسی را دور بزند و به همین خاطر، Broken Access Control در رتبهی اول لیست ریسکهای امنیت اپلیکیشن در OWASP 2025 قرار گرفته است.
این مقاله تلاش دارد نشان دهد که IDOR چگونه شکل میگیرد، چگونه قابل بهرهبرداری است، و چه رابطهای با دیگر ضعفهای مهم امنیتی مانندMass Assignment دارد.
همچنین هدف این است که خواننده پس از مطالعه این مقاله، بتواند بهصورت عملی IDOR را شناسایی کند، آن را تست کند، انواع مختلف آن را تشخیص دهد، و درک کند که یک ساختار ناامن چگونه میتواند به افشای اطلاعات حساس، دسترسی غیرمجاز، یا حتی تصاحب کامل حساب کاربری (Account Takeover) منجر شود.
۲. تعاریف
برای فهم بهتر مطالب، ابتدا لازم است چند اصطلاح کلیدی معرفی شود:
۲.۱: IDOR(Insecure Direct Object Reference)
نوعی آسیبپذیری که در آن وباپلیکیشن بدون کنترل سطح دسترسی، بهصورت مستقیم و بر اساس ورودی کاربرمانند ID به دادهها یا اشیاء داخلی سیستم ارجاع میدهد.
۲.۲: Broken Access Control
مجموعهای از ضعفهایی که منجر میشوند کاربران به منابع یا عملیاتهایی دسترسی پیدا کنند که برای آنها مجاز نشدهاند.
۲.۳: PII(Personal Identifiable Information)
اطلاعات شناساییکننده افراد مانند ایمیل، شماره ملی، شماره تماس، نام و سایر دادههای حساس.
۲.۴: Insecure Direct Function Reference
نوعی ضعف مشابه IDOR، با این تفاوت که مهاجم بهجای داده، عملکردهای حساس مثل تغییر رمز، حذف حساب یا ویرایش اطلاعات را هدف قرار میدهد.
۲.۵: Mass Assignment
وقتی بکاند پارامترهای JSON را بدون فیلتر و کنترل، مستقیماً به مدل داده نگاشت یا map میکند و مهاجم میتواند با افزودن پارامترهای غیرمجازمثل isAdminرفتارهای حساسی ایجاد کند.
۲.۶: Path Traversal
یعنی مهاجم با دستکاری مسیر فایلها (../) به فایلها و فولدرهایی خارج از محدودهی مجاز در سرور دسترسی پیدا کند.
۳. مقدمه: ماهیت آسیبپذیری IDOR
IDOR یکی از پرمخاطرهترین ضعفهای امنیتی در دنیای وب است و از دسته Broken Access Control محسوب میشود. این آسیبپذیری زمانی رخ میدهد که اعتبارسنجی دسترسی کاربر، به جای چک شدن در سمت سرور، تنها بر اساس ورودی کاربر انجام شود.
اگر یک وباپلیکیشن از شناسهها، نامها، ایمیلها یا هر نوع مرجع مستقیم دیگر برای بازیابی داده استفاده کند، اما بررسی نکند که آیا کاربر فعلی واقعاً مجاز به دسترسی به آن داده هست یا خیر، شرایط برای وقوع IDOR مهیا میشود.
به بیان ساده:
وقتی سیستم به کاربر «زیادی اعتماد» میکند، IDOR به وجود میآید.
۴. تحلیل فنی آسیبپذیری IDOR
۴.۱. مثال ۱ – دسترسی غیرمجاز به دادهها
فرض کنید یک کاربر به صفحه زیر هدایت میشود:
https://target.com/profile/user/14
در این صفحه اطلاعات حساس (PII) مربوط به حساب کاربر ۱۴ نمایش داده میشود.
اگر مهاجم مقدار ۱۴ را به ۱۶ تغییر دهد:
https://target.com/profile/user/16
و اطلاعات کاربر دیگری نمایش داده شود، این نشان میدهد که هیچ بررسی دسترسی سمت سرور انجام نشده است.
این سادهترین و رایجترین شکل IDOR است.
۴.۲. مثال ۲ – IDOR در عملکردها (Function IDOR)
ضعف دیگری که با IDOR مرتبط است، زمانی رخ میدهد که عملکردهای حساس مانند change_password یا change_email بدون بررسی سطح دسترسی اجرا میشوند.
درخواست عادی:
سوءاستفاده مهاجم:
اگر رمز کاربر ۱۶ تغییر کند، یعنی سیستم بدون بررسی هویت، عملیات حساس را اجرا کرده است.
این نوع آسیبپذیری از نظر امنیتی بسیار خطرناکتر از IDOR معمولی است زیرا مستقیماً میتواند منجر به Account Takeover شود.
۵. چرایی رخ دادن IDOR
ایجاد IDOR معمولاً ناشی از اشتباهات زیر است:
۵.۱. عدم پیادهسازی Access Control صحیح
توسعهدهنده صرفاً به ID ارسالی کاربر اعتماد میکند و بررسی نمیکند که این ID متعلق به چه کسی است.
۵.۲. فرض اشتباه امن بودن Front-end
گاهی توسعهدهنده فکر میکند کاربر به پارامترها دست نمیزند، در حالی که مهاجم همیشه توانایی تغییر درخواست را دارد.
۵.۳. وابستگی بیش از حد به Client-side Validation
برخی سیستمها چک سطح دسترسی را فقط در سمت کاربر انجام میدهند، که کاملاً اشتباه است.
۵.۴. عدم وجود سیاست یکپارچه کنترل دسترسی
فقدان یک معماری مشخص و یکپارچه برای سهمیهبندی سطوح دسترسی، رایجترین دلیل ایجاد IDOR است.
۶. روش شناسایی (IDOR Discovery)
۶.۱. بررسی نقاط حاوی دادههای حساس
هر Endpoint که دادههای شخصی بازمیگرداند، احتمال IDOR دارد:
https://target.com/api/v1/account_details
این نقاط معمولاً شامل موارد زیر هستند:
- پروفایل کاربران
- لاگها
- اطلاعات سفارش
- فایلها
- تنظیمات حساب
۶.۲. عملکردهای حساس
Endpointهای تغییر وضعیت معمولاً هدف اصلی مهاجم هستند:
- تغییر رمز
- تغییر ایمیل
- ارسال یا حذف نظر
- لایک
- افزودن یا حذف دوست
هر عملیاتی که مربوط به مدیریت حساب باشد، بالقوه خطرناک است.
۷.آسیب پذیری Mass Assignment و ارتباط آن با IDOR
Mass Assignment زمانی رخ میدهد که API پارامترهای JSON را بدون کنترل بپذیرد.
درخواست عادی تغییر ایمیل:
سوءاستفاده مهاجم:
اگر سیستم این درخواست را بپذیرد، یعنی پارامتر user_id بدون اعتبارسنجی مورد قبول واقع شده است.
سوءاستفاده شدیدتر Privilege Escalation
قبول این درخواست یعنی مهاجم میتواند سطح دسترسی خود را تغییر دهد یعنی از کاربر عادی به ادمین تبدیل شود و این به این معنی است که مهاجم می تواند به پنل ادمین دسترسی داشته باشد؛ این یکی از بدترین سناریوهای امنیتی است.
۸. نتیجهگیری
آسیبپذیری IDOR یکی از پایهایترین و در عین حال خطرناکترین ضعفهای امنیتی است. دلیل آن این است که در صورت وجود این ضعف، مهاجم میتواند:
- اطلاعات کاربران دیگر را مشاهده کند
- دادههای حساس را تغییر دهد
- عملکردهای حساس را بهجای دیگران اجرا کند
- حساب کاربری را تصاحب کند
- حتی سطح دسترسی خود را افزایش دهد
پیادهسازی کنترل دسترسی دقیق، اعتبارسنجی دائمی، و فیلتر کردن پارامترهای دریافتی سمت سرور، اصلیترین دفاع در برابر این آسیبپذیری است.
برای درک بهتر و عمیق تر می توانید رایتاپ های زیر را بخوانید:
