باگ IDOR چیست؟ هک سایت با تغییر ID و راه جلوگیری

ببین، فرض کن وارد حساب کاربری خودت توی یه سایت شدی و روی «جزئیات پروژه» زدی. توی آدرس، یه شماره مثل 4102 می‌بینی. تا اینجا همه‌چیز عادیه؛ سایت باید بفهمه کدوم پروژه رو می‌خوای. اما یه سؤال مهم: اگه شماره پروژه یه نفر دیگه رو وارد کنی، سرور از کجا می‌فهمه اون پروژه مال تو نیست؟ اگه جواب این سؤال توی کد مشخص نباشه، ممکنه با یکی از مهم‌ترین ضعف‌های امنیت وب روبه‌رو باشیم.

اسم این مشکل باگ IDOR هست. برای اتفاق افتادنش لازم نیست کسی رمز عبور رو بشکنه یا کد عجیب‌وغریب اجرا کنه. گاهی کاربر با حساب خودش وارد می‌شه، یه شناسه رو می‌فرسته و سیستم، اطلاعاتی رو تحویلش می‌ده که نباید ببینه. اینجا با یه کارگاه ماکت‌سازی خیالی و دو حساب آزمایشی جلو می‌ریم تا ببینی اشکال دقیقاً کجاست و چطور باید برطرفش کرد؛ بدون دست‌زدن به اطلاعات واقعی دیگران.

توی این آموزش IDOR می‌خوام یه عادت مهم بهت یاد بدم: وقتی شناسه‌ای توی لینک یا درخواست دیدی، فقط به خود عدد خیره نشو؛ ببین تصمیمِ مجوز دسترسی کجا گرفته می‌شه. این طرز فکر هم به درد کسی می‌خوره که امنیت وب یاد می‌گیره، هم برنامه‌نویسی که قراره پنل کاربری، فروشگاه یا API امن بسازه.

باگ IDOR چیست؟ جواب کوتاه و روشن

به زبان خودمونی، باگ IDOR چیست؟ یعنی برنامه با شناسه‌ای که از درخواست کاربر می‌گیره، یه فایل یا رکورد رو پیدا می‌کنه، ولی یادش می‌ره بررسی کنه درخواست‌کننده واقعاً حق دسترسی به اون مورد رو داره یا نه. اسم کاملش Insecure Direct Object Reference یا «ارجاع مستقیم ناامن به شیء» هست. اون شیء می‌تونه سفارش، فاکتور، تیکت پشتیبانی، تصویر خصوصی، فایل دانلودی یا هر رکورد دیگه‌ای باشه.

مثلاً مسیر فرضی /projects/4102 فقط می‌گه «پروژه شماره ۴۱۰۲ رو می‌خوام». این شماره به‌خودی‌خود نمی‌گه چه کسی مالکشه. سرور باید هویت واقعیِ نشست فعلی رو بشناسه، پروژه موردنظر رو پیدا کنه و بعد طبق قانون دسترسی تصمیم بگیره اطلاعات رو برگردونه یا درخواست رو رد کنه. پیدا کردن رکورد با مجاز بودن دیدنش فرق داره.

یه سوءتفاهم رو همین اول جمع کنیم: دیدن یا حتی حدس‌زدن شناسه، دلیل وجود باگ IDOR نیست. اگه با حساب آزمایشیِ نیما شماره پروژه مینا رو درخواست کنی و سرور بدون افشای اطلاعات، دسترسی رو رد کنه، اتفاقاً کنترل امنیتی درست کار کرده. وقتی می‌گیم آسیب‌پذیری وجود داره که خلافِ سیاست دسترسی، اطلاعات یا عملیاتی واقعاً در اختیار آدم اشتباه قرار بگیره.

چرا این باگ توی بحث هک سایت تا این حد مهمه؟

خیلی وقت‌ها وقتی می‌شنویم «هک سایت»، ذهنمون می‌ره سمت ابزار و ترمینال. ولی بعضی ضعف‌ها خیلی ساده‌ترن: کاربر به‌درستی وارد حسابش می‌شه، درخواستش هم از نظر فنی معمولیه، اما سرور جواب مربوط به یه کاربر دیگه رو می‌ده. اینجا مشکل از شکستن رمزنگاری نیست؛ برنامه موقع تصمیم‌گیری درباره مالکیت و مجوز اشتباه کرده.

این خطا زیر چتر بزرگ‌تر Broken Access Control قرار می‌گیره. توی فهرست OWASP Top 10:2025، ضعف کنترل دسترسی همچنان در دسته A01 قرار داره. برای همین شناخت باگ IDOR فقط یادگرفتن یه ترفند نیست؛ داری یکی از اصول پایه امنیت نرم‌افزار رو یاد می‌گیری. راهنمای رسمی OWASP برای جلوگیری از IDOR هم دقیقاً روی بررسی مجوزِ هر شیء تأکید می‌کنه.

البته هر مورد IDOR هم قرار نیست به «هک کامل سرور» ختم بشه. شاید فقط عنوان یه سند خصوصی لو بره، شاید فایل قرارداد یه مشتری دیده بشه یا شاید کاربر بتونه وضعیت سفارش شخص دیگه‌ای رو عوض کنه. شدت خطر به حساسیت اطلاعات، کاری که می‌شه انجام داد و تعداد افراد در معرض آسیب بستگی داره. توی گزارش فنی باید همین اثر واقعی رو بنویسیم، نه ترسناک‌ترین احتمالی رو که به ذهنمون می‌رسه.

سناریوی اختصاصی : کارگاه ماکت‌سازی «خانه کاغذی»

بیا یه مثال ثابت داشته باشیم که تا آخر درس باهاش جلو بریم. کارگاه خیالی «خانه کاغذی» برای مشتری‌ها ماکت معماری می‌سازه. هر مشتری توی پنلش می‌تونه تصویر ماکت، قیمت، وضعیت ساخت و فایل‌های پروژه خودش رو ببینه. طبیعیه که مشتری‌ها نباید فایل و سفارش همدیگه رو ببینن؛ فقط مسئول‌هایی که طبق وظیفه‌شون مجوز دارن می‌تونن سراغ پروژه‌های مربوط برن.

حالا دو مشتری داریم: «مینا» با پروژه 4102 و «نیما» با پروژه 4103. هر دو با حساب مستقل خودشون وارد سایت شدن. نیما قرار نیست رمز مینا رو بدونه؛ سؤال اینه که اگر مرورگر نیما شناسه ۴۱۰۲ رو به سرور بفرسته، برنامه چه پاسخی می‌ده؟ همین سؤال پایه آزمایش کنترل‌شده ماست. این افراد و شناسه‌ها همگی ساختگی‌ان.

صحنه اول : یک لینک کاملاً معمولی

توی پنل نیما، دکمه مشاهده پروژه به مسیر /projects/4103 می‌ره. وجود چنین مسیری کاملاً طبیعیه، چون سرور برای پیدا کردن اطلاعات به یه مرجع نیاز داره. اما این لینک فقط مشخص می‌کنه دنبال کدوم پروژه بگردیم؛ نه اینکه هر کسی لینک رو داشت، مالک پروژه هم باشه. تصمیم دوم باید جداگانه سمت سرور گرفته بشه.

صحنه دوم : دو حساب آزمایشی و یک سؤال

تیم توسعه برای تست، دو حساب و دو پروژه آزمایشی ساخته. با نشست نیما، نمایش پروژه ۴۱۰۳ باید موفق بشه و نمایش پروژه ۴۱۰۲ باید رد بشه. اگه کد فقط بگه «هر پروژه‌ای با این شناسه هست برگردون»، باگ IDOR به وجود میاد. کد درست قبل از فرستادن پاسخ می‌پرسه: «آیا همین کاربر، با همین نقش و شرایط، اجازه دیدن این پروژه رو داره؟»

صحنه سوم : مسئله فقط دیدن اطلاعات نیست

حالا داستان رو یه مقدار واقعی‌تر کنیم. فرض کن کنار جزئیات پروژه، دکمه دانلود فایل سه‌بعدی، تأیید برآورد هزینه و درخواست تغییر ابعاد هم وجود داره. ممکنه صفحه جزئیات مجوز رو درست بررسی کنه، ولی مسیر دانلود فایل یادش بره. این یعنی امن بودن یک صفحه، دلیل امن بودن همه عملیات روی همون پروژه نیست. هر عمل باید جدا سنجیده بشه.

صحنه چهارم : یک خروجی اشتباه، یک ادعای اشتباه‌تر

یه نکته مهم هم درباره گزارش نتیجه تست باگ IDOR: اگه سرور برای یه آدرس پاسخ 200 فرستاد، هنوز نمی‌تونیم بگیم نفوذ انجام شده. شاید صفحه خطای سفارشی رو با همین وضعیت برگردونده یا اطلاعات، عمومی بوده. باید متن پاسخ، مالکیت رکورد و قانون مجوز رو با دو حساب آزمایشی مقایسه کنیم. توی امنیت حرفه‌ای، «درخواست جواب داد» با «دسترسی غیرمجاز ثابت شد» یکی نیست.

چهار سؤال طلایی برای تحلیل کنترل دسترسی

برای اینکه موقع بررسی باگ IDOR گیج نشی، یه روش ساده داریم: هر بار که قراره اطلاعاتی خونده یا تغییر داده بشه، چهار سؤال رو کنار هم بذار. چه کسی درخواست می‌ده؟ روی چه چیزی؟ چه عملیاتی؟ در چه شرایطی؟ این چهار سؤال کمک می‌کنن به‌جای حدس‌زدن، قانون دسترسی مشخصی بنویسی. جدول پایین همون تصمیم رو برای کارگاه ماکت‌سازی باز می‌کنه.

مثلاً نیما می‌خواد فایل خصوصی پروژه مینا رو دانلود کنه. کاربر مشخصه، شیء مشخصه، عملیات هم مشخصه؛ اما رابطه مجازی بین نیما و اون پروژه وجود نداره، پس سرور باید درخواست رو رد کنه. در مقابل، مسئول تولید شاید در مرحله ساخت اجازه دریافت فایل فنی رو داشته باشه. همین مجوز ممکنه بعد از پایان پروژه برداشته بشه. می‌بینی؟ تصمیم فقط به شماره رکورد وابسته نیست.

اینجا فرق یه نقش کلی با مجوزِ یک رکورد معلوم می‌شه. هر دو نفر ممکنه نقش «مشتری» داشته باشن و هر دو اجازه باز کردن صفحه پروژه رو داشته باشن، ولی هرکدوم فقط باید اطلاعات پروژه‌های مجاز خودشون رو ببینن. خیلی از موارد آسیب‌پذیری IDOR از همین اشتباه میاد: برنامه اجازه ورود به بخش رو بررسی می‌کنه، اما مجوز خودِ داده رو نه.

شناسه‌ها فقط آخر آدرس نیستن؛ باگ کجا پنهان می‌شه؟

حواست باشه شناسه همیشه آخر آدرس نیست. ممکنه داخل پارامتر URL، بدنه JSON، فرم، درخواست GraphQL یا آدرس دانلود فایل باشه. پس وقتی دنبال ریشه باگ IDOR می‌گردیم، باید ببینیم کدوم داده از درخواست به انتخاب یک شیء می‌رسه و بعد چه بررسی مجوزی انجام می‌شه. وجود شناسه، فقط نقطه شروع تحلیل رو نشون می‌ده؛ هنوز چیزی درباره آسیب‌پذیر بودن ثابت نکرده.

ردیف عملیات گروهی جدول رو جدی بگیر. تصور کن مشتری اجازه ویرایش یک پروژه رو داره و API فهرستی از ده شناسه می‌گیره. اگه برنامه فقط شناسه اول رو بررسی کنه و بقیه رو بدون مجوز پردازش کنه، خطای دسترسی رخ می‌ده. مجوز یک شیء به بقیه اشیاء سرایت نمی‌کنه. همین موضوع درباره خروجی اکسل، چاپ فاکتور و دانلود چند فایل هم صدق می‌کنه.

IDOR افقی و عمودی چه فرقی دارن؟

دسترسی افقی : کاربر هم‌سطح به داده کاربر دیگه می‌رسه

توی دسترسی افقی، دو کاربر تقریباً هم‌سطح داریم. مثلاً نیما و مینا هر دو «مشتری» هستن، اما قرار نیست نیما سفارش مینا رو ببینه. اگه بتونه با شناسه اون پروژه اطلاعاتش رو دریافت کنه، یک نمونه روشن از ضعف دسترسی افقی داریم. این از رایج‌ترین سناریوهای باگ IDOR به حساب میاد.

دسترسی عمودی : نقش عادی وارد محدوده اختیارات بالاتر می‌شه

توی دسترسی عمودی، مسئله فرق نقش‌هاست. مشتری عادی نباید فقط با تغییر یه پارامتر بتونه عملیات مخصوص مدیر رو انجام بده. این هم زیرمجموعه Broken Access Control هست، ولی دقت کن: هر ضعف عمودی الزاماً باگ IDOR نیست. گاهی یک قابلیت مدیریتی بدون کنترل نقش باز مونده و اصلاً شناسه شیء خاصی در کار نیست. اسم دقیق باگ رو باید از علتش انتخاب کنیم.

دسترسی وابسته به وضعیت : مرحله پروژه هم مهمه

بعضی مجوزها به وضعیت کار هم بستگی دارن. مثلاً مشتری قبل از شروع برش ماکت می‌تونه تغییر ابعاد بده، ولی بعد از اون باید درخواستش تأیید بشه. ممکنه کاربر همون آدم باشه و پروژه هم مال خودش، اما انجام عملیات در این مرحله مجاز نباشه. این نوع خطا لزوماً باگ IDOR کلاسیک نیست؛ نمونه‌ای از اهمیت «شرایط اجرای عملیات» توی کنترل دسترسیه.

تفاوت Authentication و Authorization؛ دو کلمه شبیه، دو کار متفاوت

این دو اصطلاح رو خوب از هم جدا کن. Authentication می‌پرسه «تو کی هستی؟» و Authorization می‌پرسه «اجازه چه کاری رو داری؟». رمز عبور، کد پیامکی و ورود دومرحله‌ای برای احراز هویت کمک می‌کنن؛ اما به‌تنهایی ثابت نمی‌کنن که این فاکتور، سفارش یا پروژه مخصوص همون کاربره. اتفاقاً خیلی از خطاهای IDOR بعد از ورود موفق کاربر رخ می‌دن.

نیما ممکنه کاملاً قانونی وارد حساب خودش شده باشه، ولی این دلیل نمی‌شه بتونه فایل قرارداد مینا رو بگیره. پس جمله‌ای که می‌خوام یادت بمونه اینه: لاگین بودن یعنی سیستم هویتت رو می‌شناسه؛ نه اینکه به همه اطلاعات دسترسی داری. سرور باید برای هر درخواست حساس، مجوز مرتبط با اون کار رو هم حساب کنه.

باگ IDOR با BOLA چه ارتباطی داره؟

وقتی همین مسئله توی API رخ بده، اسم BOLA رو زیاد می‌بینی؛ مخفف Broken Object Level Authorization. توی OWASP API Security Top 10:2023 این موضوع با شناسه API1:2023 معرفی شده. BOLA روی مجوز دسترسی به خودِ شیء در API تمرکز می‌کنه و با خیلی از سناریوهای باگ IDOR هم‌پوشانی داره. بهتره به‌جای درگیر شدن با اسم‌ها، اول بفهمی درخواست به کدوم شیء رسیده و چرا مجاز یا غیرمجاز بوده.

مثلاً فرانت‌اند ممکنه دکمه «ویرایش پروژه» رو برای نیما مخفی کنه، ولی اگه API پشتش مجوز بررسی نکنه، مخفی کردن دکمه هیچ حفاظتی ایجاد نمی‌کنه. خود Endpoint باید برای همون پروژه و همون عملیات تصمیم بگیره. این قاعده برای خواندن، تغییر، حذف، دانلود و عملیات گروهی صدق می‌کنه و فقط مخصوص درخواست‌های GET نیست.

همین حرف درباره اپ موبایل هم درسته. اینکه درخواست از اپ رسمی میاد، به شناسه ارسالی اعتبار ویژه‌ای نمی‌ده؛ چون داده‌ای که از دستگاه کاربر میاد قابل کنترل هم هست. نقطه‌ای که باید قانون دسترسی رو اجرا کنه، سمت سرور و سرویس قابل اعتماد برنامه‌ست. این دقیقاً همون مرزیه که توی آموزش IDOR دنبالش می‌گردیم.

آموزش IDOR با Python؛ یک آزمایش آفلاین و قابل اجرا

حالا بریم سراغ یه آزمایش کاملاً آفلاین با Python. دو مشتری و دو پروژه ساختگی داریم. یه تابع عمداً ناامن می‌نویسیم که فقط شناسه پروژه رو می‌بینه؛ بعد تابع دوم رو می‌سازیم که علاوه بر شناسه، هویت کاربر و مالکیت پروژه رو بررسی می‌کنه. این کد قرار نیست سیستم احراز هویت واقعی باشه؛ هدفش اینه که تفاوت «پیدا کردن داده» و «حق دیدن داده» رو با خروجی قابل بررسی نشون بده.

projects = {
    4102: {"owner": 18, "name": "ماکت مرکز فرهنگی"},
    4103: {"owner": 27, "name": "ماکت کتابخانه"},
}


def unsafe_read(project_id):
    # عمداً ناامن: هویت درخواست‌کننده اصلاً بررسی نمی‌شود.
    return projects.get(project_id)


def safe_read(authenticated_user_id, project_id):
    # در سرویس واقعی authenticated_user_id باید از نشست معتبر بیاید.
    if type(authenticated_user_id) is not int or authenticated_user_id <= 0:
        return "UNAUTHENTICATED"
    if type(project_id) is not int or project_id <= 0:
        return "BAD_REQUEST"

    project = projects.get(project_id)
    if project is None:
        return "NOT_FOUND"
    if project["owner"] != authenticated_user_id:
        return "FORBIDDEN"
    return project["name"]


print(unsafe_read(4102)["name"])
print(safe_read(27, 4102))
print(safe_read(18, 4102))
print(safe_read(18, 9999))
print(safe_read(18, [4102]))

وقتی کد رو با پایتون ۳ اجرا کنی، این خروجی رو می‌بینی. قبل از نگاه کردن به جواب، یه بار حدس بزن هر درخواست باید چه رفتاری داشته باشه:

ماکت مرکز فرهنگی
FORBIDDEN
ماکت مرکز فرهنگی
NOT_FOUND
BAD_REQUEST

خط اول از تابع ناامن اومده: فقط شناسه 4102 رو گرفت و اسم پروژه مینا رو لو داد. خط دوم درخواست نیما برای پروژه میناست و باید FORBIDDEN برگردونه. خط سوم درخواست خودِ میناست و مجازه. دو خط آخر هم نشون می‌دن شناسه اشتباه یا ورودی با نوع نامعتبر، نباید برنامه رو از کار بندازه یا به‌اشتباه دسترسی بده. همه داده‌ها همین‌جا داخل حافظه ساخته شدن.

یه هشدار خیلی مهم درباره همین آزمایش باگ IDOR: توی سرویس واقعی، کاربر نباید بتونه authenticated_user_id رو هر عددی که دلش خواست بفرسته و از سرور انتظار داشته باشه حرفش رو باور کنه. این مقدار توی مثال فقط برای فهم آزمایش وارد تابع شده. توی برنامه واقعی باید از نشست معتبر سمت سرور یا توکنِ درست اعتبارسنجی‌شده به دست بیاد. از طرف دیگه، بررسی مالکیت ساده فقط یکی از مدل‌های مجوزدهیه و برای پروژه‌های تیمی یا چندسازمانی کافی نیست.

چرا تغییر ID به‌تنهایی باگ IDOR رو ثابت نمی‌کنه؟

این جمله رو توی خیلی از آموزش‌ها می‌بینی: «شماره آخر لینک رو عوض کن، اگه صفحه باز شد یعنی باگ پیدا کردی». نه؛ این روش نتیجه‌گیری ناقصیه. ممکنه رکورد عمومی باشه، ممکنه حساب آزمایشی تو هم مجوز داشته باشه یا اصلاً پاسخ، محتوای همون رکورد نباشه. برای تشخیص باگ IDOR باید قانون دسترسی و نتیجه واقعی رو کنار هم بذاری، نه اینکه فقط تغییر آدرس رو ببینی.

از اون طرف، گرفتن 403 یا 404 هم اثبات نمی‌کنه کل سامانه امنه. شاید صفحه جزئیات محافظت شده باشه ولی فایل پیوست از مسیر دیگه‌ای برگرده؛ شاید هم پاسخ خطا، اطلاعات خصوصی داخل خودش داشته باشه. برای همین آزمایشگر حرفه‌ای چند مسیر مربوط به یک شیء رو، فقط در محدوده مجاز، جداگانه بررسی می‌کنه.

روش بررسی قانونی باگ IDOR با دو حساب آزمایشی

قبل از هر تست امنیتی، تکلیف مجوز و محدوده رو روشن کن. برای یادگیری، یه پروژه محلی یا آزمایشگاه آموزشی بهترین انتخابه. توی پروژه مشتری هم باید از حساب و داده‌ای استفاده کنی که صاحب سامانه برای تست در اختیارت گذاشته. رفتن سراغ فایل یا سفارش کاربران واقعی، حتی با نیت کنجکاوی، روش قابل قبولی برای تمرین نیست.

برای بررسی باگ IDOR به‌صورت کنترل‌شده، دو حساب آزمایشی با نقش مشابه بساز و برای هرکدوم یه پروژه و فایل خصوصی قرار بده. اول مطمئن شو هر حساب به اطلاعات خودش دسترسی داره؛ بعد بررسی کن آیا درخواستش برای پروژه حساب دیگه رد می‌شه یا نه. این آزمایش ساده معمولاً از حدس‌زدن صدها شماره بهتره، چون هم قانون دسترسی روشنه، هم نتیجه رو می‌شه درست تفسیر کرد.

بررسی رو فقط به مشاهده صفحه محدود نکن. اگه توی محدوده تست اجازه داری، دانلود فایل، ویرایش، حذف، تأیید، خروجی PDF و عملیات گروهی رو هم با داده‌های ساختگی آزمایش کن. ممکنه توسعه‌دهنده مجوز رو توی یک مسیر نوشته باشه و مسیر دیگه رو فراموش کرده باشه. راهنمای تست IDOR در OWASP WSTG هم همین نگاه مبتنی بر شیء و مجوز رو توضیح می‌ده.

۷ جای حساس برای بررسی باگ IDOR و ضعف‌های دسترسی

یک : لینک فایل و پیش‌نمایش خصوصی

اولین نقطه حساس برای باگ IDOR، فایل‌ها هستن. ممکنه صفحه پروژه فقط به صاحبش نمایش داده بشه، ولی عکس یا فایل طراحی از یه آدرس عمومی و بدون بررسی مجوز دانلود بشه. برای فایل خصوصی، خودِ مسیر تحویل فایل هم باید از سیاست دسترسی تبعیت کنه. اسم پیچیده فایل جای مجوز رو نمی‌گیره و لینک موقت هم باید محدوده و زمان اعتبار مشخص داشته باشه.

دو : خروجی Excel، PDF و نسخه چاپی

دومین جای مهم، خروجی‌ها هستن. بعضی وقت‌ها صفحه فاکتور امنه، ولی دکمه «دانلود PDF» به یه مسیر جدا وصل شده که فقط شماره فاکتور رو می‌گیره. نتیجه این می‌شه که ظاهر صفحه درست محافظت شده، اما نسخه چاپی یا خروجی اکسل همون اطلاعات رو بدون بررسی لازم می‌ده. خروجی گرفتن هم یه عملیات مستقل روی داده خصوصی محسوب می‌شه.

سه : تیکت پشتیبانی و پیوست پاسخ‌ها

سومین نقطه حساس برای باگ IDOR، سیستم پشتیبانیه. یه تیکت فقط یک شماره نیست؛ پیام‌ها، فایل‌ها و یادداشت‌های داخلی خودش رو داره. ممکنه دیدن متن تیکت مجاز باشه، اما دانلود پیوست اون به کنترل جداگانه نیاز داشته باشه. توی این جور سیستم‌ها باید رابطه هر فایل و پیام با تیکت و مالک مجازش بررسی بشه، نه فقط شناسه تیکت اصلی.

چهار : تغییر وضعیت و عملیات POST

چهارمین مورد، درخواست‌های تغییردهنده هستن. بعضی‌ها فکر می‌کنن چون دکمه تأیید از طریق POST کار می‌کنه، دیگه خطری نداره. ولی نوع درخواست HTTP خودش مجوز ایجاد نمی‌کنه. سرور باید قبل از هر تغییر وضعیت بررسی کنه آیا همین کاربر روی همین پروژه و در این مرحله اجازه اون کار رو داره یا نه.

پنج : عملیات گروهی و صف پردازش

پنجمین جای بررسی باگ IDOR، عملیات گروهیه. فرض کن API یه لیست از شناسه‌های پروژه می‌گیره تا وضعیتشون رو عوض کنه. مجاز بودن مورد اول، بقیه موارد رو مجاز نمی‌کنه. باید برای تک‌تک شناسه‌ها مجوز بررسی بشه و تکلیف شکستِ یکی از درخواست‌ها هم از قبل روشن باشه؛ مثلاً کل عملیات رد بشه یا فقط موارد مجاز پردازش بشن.

شش : حافظه کش و لایه CDN

ششمین نقطه حساس، کش و CDN هستن. گاهی اصلِ کد دسترسی درست نوشته شده، اما پاسخ خصوصی یه کاربر برای کاربر دیگه از کش تحویل داده می‌شه. ریشه این اتفاق لزوماً باگ IDOR کلاسیک نیست، ولی نتیجه می‌تونه افشای اطلاعات باشه. پس برای داده‌های خصوصی، سیاست کش و جداسازی پاسخ‌ها بر اساس هویت یا نشست رو هم باید بررسی کنیم.

هفت : پنل ادمین و نقش‌های سفارشی

هفتمین بخش، پنل‌های مدیریتی و نقش‌های سفارشی‌ان. ممکنه اپراتور اجازه دیدن سفارش‌ها رو داشته باشه، ولی حق تغییر مبلغ، حذف سفارش یا دانلود بعضی فایل‌ها رو نداشته باشه. «اجازه دیدن» رو نباید با «اجازه هر کاری کردن» اشتباه بگیریم. این موضوع توی سیستم‌های وردپرسی با نقش‌های متعدد هم حسابی مهمه.

چرا UUID، رمزنگاری شناسه و لینک تصادفی مشکل رو ریشه‌ای حل نمی‌کنن؟

یه راه‌حل ظاهراً جذاب برای باگ IDOR اینه که شناسه‌های ساده رو با UUIDهای طولانی عوض کنیم. این کار حدس‌زدن شناسه رو سخت‌تر می‌کنه، اما سؤال اصلی هنوز سر جاشه: اگر یک نفر شناسه خصوصی رو به هر دلیلی به دست آورد، سرور بدون مجوز فایل رو بهش می‌ده یا نه؟ اگه می‌ده، مشکل حل نشده.

شناسه تصادفی می‌تونه یه لایه کمکی خوب باشه، ولی جای بررسی مالکیت و دسترسی رو نمی‌گیره. همین‌طور مخفی کردن شماره توی JavaScript، تبدیلش به Base64 یا برداشتن دکمه از صفحه، مجوز سمت سرور درست نمی‌کنه. توی جلوگیری از IDOR باید اصلِ تصمیم دسترسی رو اصلاح کنیم، نه فقط ظاهر لینک رو.

یه استثنای مهم هم داریم: بعضی سرویس‌ها عمداً لینک اشتراک‌گذاری می‌سازن که خودِ داشتن لینک، بخشی از مدل مجوزدهیه. این مدل می‌تونه درست باشه، به شرطی که آگاهانه طراحی شده باشه؛ مثلاً زمان انقضا، محدوده دسترسی و امکان باطل‌کردن لینک مشخص باشه. چنین لینکی با فایل خصوصی‌ای که تصادفاً بدون کنترل در دسترس قرار گرفته فرق داره.

چطور از باگ IDOR جلوگیری کنیم؟ روش درست توی بک‌اند

برای جلوگیری از IDOR، قانون اصلی خیلی روشنه: سرور باید روی هر درخواست، مجوز همان عملیات روی همان شیء رو بررسی کنه. ممکنه این مجوز از مالکیت، عضویت توی تیم، نقش کاربر، وضعیت قرارداد یا محدودیت سازمانی بیاد. ورود موفق به حساب یا دیدن یک دکمه توی صفحه، جای این بررسی رو نمی‌گیره.

اگه داده‌ها متعلق به یک کاربر خاصن، حتی بهتره جست‌وجوی دیتابیس از اول به محدوده مجاز همون کاربر محدود بشه. مثلاً برنامه به‌جای «پروژه شماره ۴۱۰۲ رو بیار»، دنبال «پروژه شماره ۴۱۰۲ در بین پروژه‌های مجاز این کاربر» بگرده. البته برای پروژه‌های مشترک یا چندسازمانی، بررسی صرفِ owner_id کافی نیست و باید قوانین واقعی تیم و Tenant هم لحاظ بشن.

توی پروژه جدی، بهتره قانون‌های دسترسی توی یک لایه مشخص نگه‌داری بشن، نه اینکه توی ده‌ها فایل و کنترلر هرکدوم یه نسخه جدا داشته باشن. کنار اون هم تست رگرسیون بنویس تا بعد از تغییرات برنامه، دسترسی غیرمجاز دوباره برنگرده. ثبت رویدادهای ردشده هم کمک می‌کنه رفتار مشکوک رو ببینی، البته بدون اینکه اطلاعات خصوصی رو بی‌دلیل توی لاگ ذخیره کنی.

باگ IDOR در وردپرس؛ آیا permission_callback کافیه؟

اگه با REST API وردپرس کار می‌کنی، احتمالاً permission_callback رو دیدی. این بخش قبل از اجرای callback اصلی، مجوز درخواست رو بررسی می‌کنه. ولی وجود این گزینه به‌تنهایی به معنی امن بودن API نیست. اگه فقط is_user_logged_in() رو صدا بزنی، معلوم می‌شه کاربر وارد شده؛ هنوز ثابت نشده که حق دیدن همین پروژه رو داره. مستندات رسمی ساخت Endpoint در وردپرس این بخش رو توضیح می‌ده.

برای اینکه موضوع ملموس بشه، یک API کاملاً آموزشی برای نوع نوشته فرضی nb_private_project در نظر می‌گیریم. قانون نمونه ما اینه: فقط نویسنده همون پروژه حق دیدن عنوانش رو داره. این محدودیت رو عمداً ساده انتخاب کردیم تا تستش روشن باشه؛ قرار نیست مدیر، همکار یا اپراتور به‌صورت ضمنی مجوز بگیره. نوع نوشته باید قبلاً در محیط آزمایشگاهی ثبت شده باشه و هیچ‌کدوم از این کدها رو نباید بدون تطبیق با مدل دسترسی، روی سایت تجاری نصب کنی.

add_action('rest_api_init', static function () {
    // صرفاً برای نوع نوشته فرضی nb_private_project در محیط آزمایشگاهی.
    $authorize = static function (WP_REST_Request $request) {
        if (!is_user_logged_in()) {
            return new WP_Error('login_required', 'Login required', ['status' => 401]);
        }

        $url_params = $request->get_url_params();
        $raw_id = $url_params['id'] ?? null;
        if (!is_string($raw_id) || !preg_match('/^[1-9][0-9]*$/D', $raw_id)) {
            return new WP_Error('bad_id', 'Invalid project ID', ['status' => 400]);
        }

        $project_id = (int) $raw_id;
        if ($project_id < 1) {
            return new WP_Error('bad_id', 'Invalid project ID', ['status' => 400]);
        }

        $post = get_post($project_id);
        if (!$post || $post->post_type !== 'nb_private_project') {
            return new WP_Error('not_found', 'Not found', ['status' => 404]);
        }
        if ((int) $post->post_author !== get_current_user_id()) {
            return new WP_Error('forbidden', 'Access denied', ['status' => 403]);
        }
        return $post;
    };

    register_rest_route('nb-demo/v1', '/projects/(?P<id>[1-9][0-9]*)', [
        'methods' => 'GET',
        'permission_callback' => static function (WP_REST_Request $request) use ($authorize) {
            $result = $authorize($request);
            return is_wp_error($result) ? $result : true;
        },
        'callback' => static function (WP_REST_Request $request) use ($authorize) {
            $post = $authorize($request); // بررسی مجدد قبل از ساخت پاسخ
            if (is_wp_error($post)) {
                return $post;
            }
            return rest_ensure_response([
                'id'    => (int) $post->ID,
                'title' => $post->post_title,
            ]);
        },
    ]);
});

توی این مثال، سرور اول کاربر جاری رو از نشست معتبر وردپرس می‌گیره، بعد شناسه رو از پارامتر مسیر API می‌خونه، وجود و نوع پروژه رو بررسی می‌کنه و سرانجام صاحب پروژه رو با کاربر واردشده مقایسه می‌کنه. همین بررسی موقع ساخت پاسخ هم دوباره انجام می‌شه. پس حتی اگه درخواست‌کننده پارامتری به اسم user_id بفرسته، برنامه اون رو به‌جای هویت معتبر قبول نمی‌کنه. این روش برای سیاست «فقط مالک» طراحی شده، نه همه مدل‌های مجوزدهی.

توی این نمونه جلوگیری از باگ IDOR، خروجی API فقط عنوان پروژه آزمایشی رو برمی‌گردونه تا رفتار قابل بررسی بمونه. اگر بعداً مدیر یا همکار هم باید دسترسی داشته باشه، باید اون قانون جداگانه و با آزمون‌های مشخص اضافه بشه. تابع current_user_can('edit_post', $project_id) توی وردپرس برای بررسی قابلیت ویرایش یک نوشته کاربرد داره، اما نباید بدون فکر فرض کنیم مجوز ویرایش دقیقاً همون سیاست خواندن پروژه خصوصی ماست. برای این تفاوت، مستندات current_user_can رو هم ببین.

Nonce در وردپرس چرا جای Permission رو نمی‌گیره؟

یه اشتباه رایج دیگه توی توسعه وردپرس اینه که کسی یه Nonce معتبر می‌بینه و خیال می‌کنه درخواست حتماً مجازه. Nonce در وردپرس برای کمک به محافظت از بعضی درخواست‌ها در برابر سوءاستفاده‌هایی مثل CSRF استفاده می‌شه؛ اما سند مالکیت سفارش یا پروژه نیست. Nonce معتبر، جای Authorization رو نمی‌گیره.

فرض کن نیما برای عملیات پنل خودش Nonce معتبر گرفته؛ با این حال نباید بتونه همون درخواست رو روی پروژه مینا اجرا کنه. پس ورود و Nonce هرکدوم نقش خودشون رو دارن، و بررسی دسترسی به شیء هم وظیفه جداگانه‌ایه. اگه این‌ها رو یکی فرض کنیم، حتی با وجود چند لایه امنیت ظاهری، ممکنه باگ IDOR باقی بمونه.

فرق IDOR با XSS و SQL Injection چیه؟

تا اینجای مسیر، SQL Injection و XSS رو هم بررسی کردیم. فرقشون با باگ IDOR خیلی مهمه. توی تزریق SQL، داده ممکنه وارد ساخت دستور دیتابیس بشه؛ توی XSS، ورودی نامطمئن می‌تونه در مرورگر به محتوای اجرایی تبدیل بشه. ولی توی IDOR ممکنه کوئری کاملاً پارامتری باشه و خروجی هم درست Escape شده باشه؛ با این حال سرور اطلاعات پروژه اشتباهی رو بده، چون مجوز رکورد رو بررسی نکرده.

برای اینکه این سه ضعف رو قاطی نکنی، یه بار آموزش SQL Injection و درس حمله XSS رو کنار همین مقاله مرور کن. شباهت ظاهریِ نتیجه حمله‌ها مهم نیست؛ چیزی که برای اصلاح کد اهمیت داره، ریشه فنی مشکله.

چرا ابزار هک به‌تنهایی IDOR رو پیدا نمی‌کنه؟

ابزارهایی مثل Burp Suite می‌تونن بهت کمک کنن درخواست و پاسخ دو حساب آزمایشی رو کنار هم ببینی. اما ابزار از قوانین داخلی کسب‌وکار خبر نداره؛ مثلاً نمی‌دونه نیما اجازه مشاهده پروژه مشترک با مینا رو داشته یا نه. برای همین تشخیص باگ IDOR به شناخت سیاست دسترسی و تحلیل نتیجه نیاز داره، نه فقط زدن دکمه اسکن. آموزش IDOR در Web Security Academy هم مثال‌های خوبی برای فهم این تفاوت داره.

ممکنه ابزار یه درخواست رو مشکوک نشون بده ولی بعد معلوم بشه دسترسی مجاز بوده. برعکس، شاید اسکن خودکار هیچ هشداری نده، اما آزمایش دو حساب مجاز با داده‌های ساختگی ضعف رو روشن کنه. ارزش ابزار توی مشاهده و ثبت شواهده؛ اینکه پاسخ خلافِ قانون دسترسی بوده یا نه، باید با تحلیل دقیق مشخص بشه.

چطور از یک کشف مشکوک، گزارش امنیتی درست بسازیم؟

وقتی می‌خوای برای باگ IDOR گزارش بنویسی، صرفِ «این سایت ناامنه» هیچ کمکی به برنامه‌نویس نمی‌کنه. باید بگی چه حساب آزمایشی‌ای استفاده شد، کدوم شیء درخواست شد، انتظار چی بود، واقعاً چه پاسخی برگشت و چرا اون پاسخ خلافِ سیاست بود. بهتره شواهد رو با داده ساختگی ثبت کنی و اطلاعات خصوصی اضافی وارد گزارش نکنی.

شدت خطر هم از روی اسم باگ مشخص نمی‌شه. افشای عنوان یک پروژه عمومی با دانلود قرارداد مالی محرمانه فرق داره؛ همین‌طور دیدن اطلاعات با تغییر یا حذفش یکی نیست. توی گزارش، چیزی رو که واقعاً تأیید کردی جدا از پیامدهایی بنویس که فقط احتمال می‌دی. این دقیقاً همون صداقتیه که باعث می‌شه تیم فنی روی گزارش حساب کنه.

چک‌لیست اصلاح برای برنامه‌نویس و صاحب سایت

اگه توسعه‌دهنده یا مسئول یک سایتی، لازم نیست صبر کنی تا کسی ضعف رو گزارش کنه. از مسیرهایی شروع کن که داده خصوصی دارن: سفارش‌ها، فاکتورها، تیکت‌ها، فایل‌های پیوست، پنل مالی و API اپ موبایل. برای هر کدوم مشخص کن چه کسی می‌تونه چه کاری روی کدوم رکورد انجام بده و بعد هم برای دسترسی مجاز و غیرمجاز تست بنویس.

پیشنهاد عملی من اینه که کنار تست «مینا پروژه خودش رو می‌بینه»، حتماً تست «نیما پروژه مینا رو نمی‌بینه» هم داشته باشی. تست منفی معمولاً اون چیزی رو پیدا می‌کنه که تست‌های معمولی جا می‌ندازن. وقتی این بررسی‌ها توی CI اجرا بشن، احتمال برگشت ضعف بعد از تغییرات کمتر می‌شه. راهنمای OWASP برای تست رگرسیون مجوزدهی هم روش ساخت این ماتریس‌ها رو توضیح می‌ده.

سه تمرین کوتاه برای اینکه موضوع واقعاً جا بیفته

تمرین اول : لینک قابل حدس

حالا خودت قضاوت کن: توی یه پنل آزمایشی، شماره پروژه‌ها پشت سر هم زیاد می‌شن. حساب A پروژه خودش رو می‌بینه، اما موقع درخواست پروژه B پاسخ 403 می‌گیره و هیچ اطلاعات خصوصی‌ای هم برنمی‌گرده. آیا صرف قابل حدس بودن شناسه‌ها یعنی باگ IDOR داریم؟ نه؛ چون سرور برای شیء غیرمجاز تصمیم درستی گرفته. سختی حدس شناسه یه موضوعه، کنترل مجوز یه موضوع دیگه.

تمرین دوم : کاربر ادمین و فایل پروژه

مثال دوم: یک مدیر شعبه می‌گه چون نقش «مدیر» داره باید همه پروژه‌ها رو ببینه. اما طبق سیاست شرکت، هر مدیر فقط اجازه دیدن پروژه‌های شعبه خودش رو داره. اگه مدیر شعبه اول بتونه فایل‌های شعبه دوم رو بگیره، کنترل دسترسی درست اجرا نشده. پس نقش کلی بدون بررسی محدوده سازمان یا Tenant کافی نیست.

تمرین سوم : دکمه مخفی شده

مثال سوم: سایت دکمه «تأیید پرداخت» رو برای مشتری مخفی کرده، ولی API مربوط به اون درخواست هنوز برای نقش مشتری قابل اجراست. آیا مخفی کردن دکمه مشکل رو حل می‌کنه؟ قطعاً نه. سرور باید مجوز انجام عملیات رو بررسی کنه؛ اگه شناسه سفارش هم در درخواست هست، باید مجوز همین سفارش هم جدا ارزیابی بشه.

از این درس به مسیر واقعی یادگیری هک و امنیت وب

اگه تازه آموزش هک سایت رو شروع کردی، طبیعیه اول ابزارها برات جذاب‌تر باشن. اما توی باگ IDOR و بقیه موضوعات امنیتی، مهارت واقعی از جایی شکل می‌گیره که بتونی رفتار برنامه رو به یک قانون امنیتی وصل کنی، با داده آزمایشی نتیجه بگیری و بعد دلیل و راه اصلاح رو توضیح بدی. همین نگاه برای برنامه‌نویسی بک‌اند، ساخت API و توسعه افزونه وردپرس هم ارزش داره.

برای اینکه تصویر کلی‌تری داشته باشی، اول درس هک سایت چگونه انجام می‌شود رو بخون و بعد سراغ مسیر آموزش تست نفوذ برو. هرکدوم جای خودشون رو دارن: یکی انواع ضعف‌های وب رو معرفی می‌کنه و اون یکی مسیر بررسی مجاز و گزارش حرفه‌ای رو نشون می‌ده.

اگه دوست داری این مباحث رو منظم‌تر و با آزمایشگاه‌های بیشتری ادامه بدی، می‌تونی سرفصل‌های پکیج متخصص تست نفوذ نابغه‌ها رو ببینی. البته همین مقاله هم باید مستقل به دردت بخوره؛ هدفمون این نیست با ترسوندن از هک، فقط تو رو سمت یه دوره بفرستیم. می‌خوام دلیل فنی باگ رو بفهمی و بتونی درباره اصلاحش حرف بزنی.

جمع‌بندی : مشکل عدد نیست، تصمیم دسترسیه

اگه قرار باشه کل درس رو توی یک جمله بگم، اینه: باگ IDOR وقتی اتفاق می‌افته که سرور شیء درخواست‌شده رو پیدا کنه، اما حقِ دسترسی همون درخواست‌کننده به همون شیء و عملیات رو درست بررسی نکنه. شناسه عددی، URL قابل حدس یا نبودن رمز روی خود فایل، به‌تنهایی تعریف این باگ نیستن. اصل ماجرا تصمیم مجوزدهیه.

از این به بعد هر وقت شناسه سفارش، فایل یا تیکت رو دیدی، به‌جای اینکه فقط بپرسی «اگه عددش رو عوض کنم چی می‌شه؟»، سؤال دقیق‌تری بپرس: «سرور کجا مشخص می‌کنه این کاربر حق دیدن یا تغییر این مورد رو داره؟» همین تغییر زاویه نگاه، تفاوت حفظ کردن چند ترفند با فهمیدن واقعی امنیت و تست نفوذه.

سؤالات متداول درباره باگ IDOR و هک سایت

منابع معتبر برای مطالعه بیشتر

برای مطالعه دقیق‌تر، راهنمای رسمی جلوگیری از IDOR در OWASP، روش تست در OWASP WSTG، آموزش PortSwigger، راهنمای BOLA و مستندات REST API وردپرس رو ببین. داستان کارگاه ماکت‌سازی و همه مثال‌ها برای همین درس طراحی شدن و به یک سامانه واقعی اشاره ندارن.