«ارجاع مستقیم ناامن به اشیاء داخلی برنامه» یا آسیب‌پذیری Insecure Direct Object Reference که به عنوان آسیب‌پذیری IDOR شناخته می‌شود، یک آسیب‌پذیری کنترل دسترسی است که در آن می‌توان از ورودی کاربر نامعتبر، برای دسترسی غیرمجاز به منابع یا عملیات‌ها استفاده کرد. علی‌رغم دشواری‌های موجود در یافتن آسیب‌پذیری‌های IDOR، این آسیب‌پذیری‌ها می‌توانند عواقبی جدی برای امنیت سایبری داشته باشند و به راحتی نیز قابل استفاده هستند. با توجه به این موضوع، در ادامه این مطلب جزئیات آسیب‌پذیری Insecure Direct Object Reference  را موردبررسی قرار می‌دهیم.

آسیب‌پذیری‌ IDOR در بین ۱۰ آسیب‌پذیری برتر OWASP

در لیست ۱۰ آسیب‌پذیری برتر برنامه‌های تحت وب که توسط OWSAP (پروژه امنیت برنامه‌های تحت وب[۱]) تهیه شده، آسیب‌پذیری Insecure Direct Object Reference به عنوان یک نام کلی به آسیب‌پذیری‌هایی اطلاق شده که به مهاجمان اجازه ارجاع مستقیم به اشیاء داخلی برنامه و دسترسی غیرمجاز به منابع برنامه را می‌دهد. برنامه‌های تحت وب آسیب‌پذیر، ارجاع مستقیم به یکی از اشیاء در پیاده‌سازی داخلی، مانند شناسه کاربر را قابل دسترس قرار داده و سپس قادر به بررسی مجاز بودن کاربر فعلی برای دسترسی به یک منبع یا عملیات نیستند.

آسیب‌پذیری IDOR جهت رسمی‌سازی ایده ساده فوق که طی آن می‌توان با خرابکاری کردن در یک URL یا از طریق یک پارامتر به منابع و عملیات‌ها دست یافت، در سال ۲۰۰۷، توسط OWASP و در لیست ۱۰ آسیب‌پذیری رایج، در دسته جداگانه A4 معرفی شد. این دسته از آسیب‌پذیری‌ها، در سال ۲۰۱۷،  با دسته A5 یعنی کنترل دسترسی ناقص[۲] ادغام گردید.

یک ارجاع مستقیم ناامن به یک شیء داخلی برنامه به خودی خود خطرناک نیست و تنها برخی جزئیات پیاده‌سازی داخلی برنامه را در معرض دید قرار می‌دهد. برای اینکه یک ارجاع مستقیم ناامن به یک شیء داخلی برنامه به عنوان یک IDOR در نظر گرفته شود باید با کنترل دسترسی ناکافی ترکیب شود که به پیروی از OWASP، این تعریف موردنظر از IDOR در این مطلب است.

نحوه کار آسیب‌پذیری‌ IDOR

یک آسیب‌پذیری Insecure Direct Object Reference زمانی روی می‌دهد که شروط زیر محقق گردد:

• برنامه ارجاعی مستقیم به یک شی داخلی را در معرض دید قرار دهد
• کاربر بتواند با دستکاری یک URL یا یک پارامتر از یک فرم، ارجاع مستقیم را تغییر دهد
• برنامه اجازه دسترسی به شیء داخلی را بدون بررسی مجاز بودن کاربر بدهد

علی‌رغم بسیار رسمی به نظر رسیدن شروط فوق، درک آسیب‌پذیری‌های IDOR در عمل بسیار ساده است. به عنوان مثال، فرض کنیم که یک فروشگاه آنلاین ایمیلی حاوی یک کد تبلیغاتی یک بار مصرف برای مقدار مشخص تخفیف در خرید از آن فروشگاه را به شما ارسال کرده و در زمان استفاده از کد موردنظر، URL www.example.com/applydiscount?promocode=123 را، بدون بررسی اینکه واقعا کاربر فعلی واجد شرایط استفاده از کد تخفیف تبلیغاتی موردنظر باشد، پردازش کند. در صورت توجه به این نکته در طول بررسی، ممکن است وسوسه شده تا کدهای تبلیغاتی دیگر را نیز تایپ کرده و آن‌چه اتفاق می‌افتد را ببینید. در این صورت، اگر مقدار پارامتر کد تبلیغاتی را به مقداری دیگر، برای مثال ۱۲۰ یا ۱۲۵ تغییر داده و تخفیف متفاوتی به دست آورید، موفق به بهره‌برداری از یک آسیب‌پذیری IDOR شده‌اید.

استفاده از شناسه در URL، به عنوان مثال به صورت www.example.com/userinfo/73627، می‌تواند یک مثال پیش پاافتاده دیگر از IDOR باشد. بدون مدیریت جلسه و کنترل دسترسی مناسب، سایت ذکر شده ممکن است اجازه شمارش شناسه‌های کاربران را داده و در نتیجه آن، به طور بالقوه، اطلاعاتی محرمانه را در اختیار افراد غیرمجاز قرار دهد.

انواع آسیب‌پذیری Insecure Direct Object Referenec

چه از طریق URLها و چه از طریق پارامترهای فرم‌ها، برنامه‌ها می‌توانند بسیاری از جزئیات پیاده‌سازی داخلی خود را آشکار کنند. برخی پارامترها مانند کدهای تبلیغاتی ذکر شده در پاراگراف فوق می‌توانند به طور مستقیم برای کسب منفعت مالی مورد استفاده قرار گیرند. برخی دیگر ممکن است برای استخراج اطلاعات حساس یا ارتقای سطح دسترسی، مورد استفاده قرار گیرند. با توجه به نوع حمله، آسیب‌پذیری‌های IDOR را می‌توان در عمل (علی‌رغم هم‌پوشانی) به ۴ دسته زیر تقسیم نمود.

• کسب دسترسی غیرمجاز به داده‌ها: در معرض دید قرار گرفتن ارجاعات به اشیاء ممکن است به طور مستقیم شناسه‌های پایگاه داده را آشکار کرده و امکان بازیابی رکوردهای پایگاه داده، که شامل داده‌های حساس هستند، را در اختیار مهاجمین قرار دهد. مقادیر و نام‌های کلیدی پایگاه داده همچنین می‌توانند برای تهیه Payloadهای حملات SQL injection مورد استفاده قرار گیرند.
• انجام عملیات‌ غیرمجاز: از طریق دستکاری مقادیر شناسه کاربر نامعتبر، نام‌های دستورات یا کلیدهای API، مهاجمین می‌توانند دستورات غیرمجاز را در برنامه اجرا کنند. به عنوان مثال‌هایی از این دست می‌توان به اجبار به تغییر گذرواژه جهت تحت کنترل در آوردن حساب یک کاربر، اجرای دستورات مدیریتی برای افزودن کاربر یا افزایش سطح دسترسی و دستیابی به ویژگی‌ها یا APIهای برنامه نیازمند پرداخت یا دارای نرخ محدود، اشاره کرد.
• دستکاری اشیاء برنامه: دسترسی به ارجاع به اشیاء داخلی می‌تواند به کاربران نامجاز اجازه تغییر وضعیت داخلی یا داده‌های یک برنامه را بدهد. در نتیجه این نوع آسیب‌پذیری، مهاجمان ممکن است متغیرهای جلسات را با اهدافی مانند تغییر داده‌ها، افزایش سطح دسترسی، یا دسترسی به قابلیت‌های محدود شده، دستکاری کنند.
• دسترسی مستقیم به فایل‌ها: این نوع از IDOR که به طور معمول با آسیب‌پذیری Path Traversal ترکیب می‌شود، به مهاجمان امکان دستکاری منابع فایل سیستم[۳] را می‌دهد. در نتیجه این امکان، ممکن است مهاجمین اجازه بارگذاری فایل و یا دانلود رایگان محتوای پولی را به دست آورند.

علی‌رغم اینکه بسیاری از آسیب‌پذیری‌های Insecure Direct Object Access در نوع خود آسیب‌پذیری‌هایی قابل توجهی هستند، اما به طور معمول در ترکیب با سایر بردارهای حمله مورد استفاده قرار می‌گیرند.

شناسایی آسیب‌پذیری‌های IDOR

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

جلوگیری از آسیب‌پذیری‌های Insecure Direct Object Reference

در این قسمت به معرفی چندین رویکرد برای جلوگیری از آسیب‌پذیری‌های IDOR پرداخته می‌شود. این رویکردها، علی‌رغم اینکه دلیل اصلی آسیب‌پذیری‌های IDOR را برطرف نمی‌کنند، اما خطرات ناشی از ارجاع مستقیم را کاهش می‌دهند. اولین رویکرد این است که ارجاعات موردنظر با ارجاعات غیرمستقیم به اشیا، که در ادامه به صورت داخلی به اشیاء واقعی Map می‌شوند، جایگزین شوند. این رویکرد می‌تواند به معنای استفاده از یکMap  ارجاع موقت به ازای هر Session باشد که فقط شامل مقادیری معتبر برای یک کاربر مشخص و همراه با کلیدهایی تصادفی و فاقد ترتیب باشد.

استفاده از Hashهای امن به جای ارجاع به اشیای واقعی یک راه دیگر برای دشوار کردن دستکاری مقادیر قابل کنترل توسط کاربر است. برای مشاهده توصیه‌هایی دقیق در مورد جایگزینی شناسه‌های مستقیم با Hashهای امن، علاقمندان می‌توانند به OWASP IDOR Prevention Cheat Sheet مراجعه کنند.

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

سخن پایانی

شرکت امن‌پردازان کویر (APK) از شرکت‌های پیشگام کشور در حوزه‌ی ارائه خدمات امنیت سایبری به سازمان‌ها و شرکت‌ها، با در اختیار داشتن مجموعه‌ای از حرفه‌ای‌ترین مهندسان امنیت سایبری، آماده ارائه خدمات در زمینه شناسایی و مقابله با رایج‌ترین آسیب‌پذیری‌های امنیت سایبری از جمله آسیب‌پذیری Insecure Direct Object Reference یا IDOR به شرکت‌ها و سازمان‌ها است. جهت کسب اطلاعات بیشتر در این زمینه می‌توانید با شماره ۰۲۱۴۲۲۳۸ تماس حاصل نمایید.

منبع:

https://www.netsparker.com/blog/web-security/insecure-direct-object-reference-vulnerabilities-idor

[۱] Open Web Application Security Project

[۲] Broken access control

[۳] File system