آسیبپذیری Insecure Direct Object References یا به اختصار IDOR یک آسیبپذیری کنترل دسترسی است که در آن میتوان از ورودی کاربر نامعتبر، برای دسترسی غیرمجاز به منابع یا عملیاتها استفاده کرد. در بخش اول این مقاله، روشهایی کارآمد را برای یافتن این آسیبپذیری معرفی کردیم. در این بخش نمونهای از باگهایی که به آسیبپذیری IDOR منجر میشوند را بررسی کرده و ابزارهایی مفید برای تست این آسیبپذیری را معرفی خواهیم کرد. همچنین به بررسی تاثیرات این آسیبپذیری خواهیم پرداخت.
معرفی نمونههایی از باگهای IDOR
دستکاری درخواستهای ایجاد[۱]
برخی از برنامههای کاربردی یک ID را در سمت کلاینت ایجاد کرده و سپس درخواست ایجاد را به سرور میفرستند. این مقدار ID میتواند یک عدد باشد، مثل -۱ یا ۰ یا هر عددی. مقادیر ID موجود همراه با IDهای Objectهایی که قبلاً ایجاد شدهاند، تغییر میکنند. درنتیجه میتوان Objectهای کاربران دیگر را با استفاده از آسیبپذیری IDOR حذف یا ویرایش کرد.
اگر در هنگام ایجاد یک Object پارامترهایی مثل «id»، «user_id»، «pid» و«post_id» را ندیدید باید آن را اضافه کرده و خودتان آن را تست کنید. میتوانید با اضافه کردن یا ویرایش هر Objectی در برنامهی کاربردی، نام کلید پارامتر را پیدا کنید.
BLIND IDOR
در مورد دیگری، امکان پیدا کردن آسیبپذیری IDOR وجود دارد اما ممکن است به راحتی متوجه آن نشوید. مثلاً اگر اطلاعات Object را در برنامهی کاربردی تغییر دهید، ایمیلی را دریافت میکنید که حاوی اطلاعات Object است. درنتیجه اگر تلاش کنید اطلاعات Object کاربر دیگری را تغییر دهید، امکان دسترسی به هیچچیزی در پاسخ HTTP وجود ندارد، اما میتوانید با یک ایمیل به اطلاعات Object دسترسی پیدا کنید. میتوان نام این مورد را Blind IDOR گذاشت.
ترکیب آسیبپذیریهای مختلف
تأثیرات باگهای IDOR قابلتغییر هستند. در برخی از موارد، آسیبپذیریهای IDOR میتوانند با فعال کردن آسیبپذیریهای دیگری که قابلیت Exploit شدن ندارند، به شما کمک کنند. اگر یک آسیبپذیری بیاهمیت IDOR مثل ویرایش نامهای فایل غیرعمومی و بیاهمیت را پیدا کنید و بخواهید تأثیر باگ موجود را افزایش دهید، میتوانید از Self-XSS Bug استفاده کنید. آسیبپذیری Self-XSS که در حین تست برنامه کاربردی وب پیدا میشود معمولاً خارج از محدوده است، اما اگر آسیبپذیری Self-XSS را با یک آسیبپذیری IDOR دیگر ترکیب کنید، میتوانید گزارشی را تحت عنوان «IDOR + Stored XSS» ارائه داده و به یک آسیبپذیری در سطح P2 دست پیدا کنید.
آسیبپذیریهای حیاتی IDOR
آسیبپذیری IDOR توانایی دسترسی به یک حساب کاربری دسترسی را ایجاد میکند، اما امکان حذف یا ویرایش را نمیدهد. این باگهای حیاتی در زمینههایی مثل ریست کردن رمز عبور، تغییر رمز عبور و بازیابی حساب کاربری پدیدار میشوند. پس در ابتدا باید لینک داخل ایمیل و پارامترهای درون آن را چک کنید. سپس میتوانید درخواست ریست کردن رمز عبور را دریافت کرده و پارامترها را با هر ابزار پروکسی که میتوانید بررسی نمایید. ما بارها در این درخواستها مقدار «user id» را دیدهایم و میتوانیم به سادگی وارد حساب کاربری یک کاربر دیگر شویم.
در همین حال، مهم است که بهدست آوردن حساب از طریق مقادیر Header در درخواست ارسال شوند. دیده شده است که برخی از مقادیر Header مثل «X-User-ID» یا «X-UID» از محیطهای تست و Debug تغییر کردهاند. درنتیجه کاربر میتواند مثل هرکاربر دیگری رفتار کند و با موفقیت کنترل حساب کاربری را بهدست آورد.
HPP Bug
در مواردی نادر، میتوان با اضافه کردن پارامتر یکسانی در درخواست خود، آسیبپذیری HPP یا همان HTTP Parameter Pollution را برای IDOR تست کرد.
ایجاد درخواست معتبر
باید اطمینان حاصل کنید که درخواست ارسال شده به سرور صحیح است. اگر سعی کنید درخواست یک کاربر را با یک کاربر دیگر ارسال کنید، باید مطمئن شوید که مقدار CSRF-Token متعلق به این درخواست معتبر است. پس باید CSRF-Token متعلق به کاربر دیگر را درون درخواست قرار دهید. در غیر این صورت، خطای عدم تطابق مقادیر Token دریافت خواهید کرد. اگر درخواست تستشدهی شما XHR باشد (درخواست XML HTTP)، باید اعتبار پارامتر Content-Type Header را در درخواست خود چک کنید. همچنین ممکن است درخواستهای برنامهی کاربردی دارای Headerهای سفارشی مثل «W-User-Id»، «X-User-Id»، «User-Token» و غیره باشند. اگر بخواهید تست درست و کاملی داشته باشید، باید تمام Headerهای مورداستفادهی برنامهی کاربردی را بهصورت درست ارسال کنید.
ابزارهای مفید برای تست آسیبپذیری IDOR
همانطور که قبلاً اشاره کردیم، میتوانید از ویژگیهای Burp Suite استفاده کنید. همچنین میتوانید از افزونههای Burp Suite برای تست آسیبپذیری IDOR استفاده کنید، مثلاً «Authz»، «AuthMatrix» و «Authorize».
افزونهی Authz امکان مشاهدهی درخواستهای کاربران دیگر را فراهم میکند. پس میتوانید درخواست کاربر X را به Authz بفرستید و سعی کنید بهعنوان کاربر Y به پاسخ آن دسترسی پیدا کنید. همچنین میتوانید Header سفارشی مثل «X-CSRF-Token» را برای تست آسیبپذیری IDOR اضافه کنید.
افزونهی AuthMatrix به شما این توانایی را میدهد که با ثبت مقادیر کوکی یا مقادیر Header برای نقشهایی در برنامه کاربردی، چکِ احراز هویت انجام دهید.
برای درخواستهای API میتوان از افزونهی Wsdler برای Burp Suite، SoapUI، Postman و… استفاده کرد. میتوانید با استفاده از این ابزارها تمام درخواستهای GET، POST، PUT، DELETE، PATCH را امتحان کنید و تست API را بهسرعت و با موفقیت انجام دهید.
تأثیر آسیبپذیریهای IDOR
آسیبپذیریهای IDOR از نظر تأثیرگذاری متنوع هستند، زیرا کلیت تأثیر آنها وابسته به باگ ارائه شده است. اما براساس تجربه، فهرستی درمورد تأثیر آسیبپذیریهای IDOR ایجاد شده است که در ادامه ارائه میگردد.
P1 – به دست گرفتن حساب کاربری، دسترسی به اطلاعات بسیار مهم (مثلاً کارت اعتباری)
P2 – تغییر یا حذف دادههای عمومی کاربر دیگر، دسترسی خصوصی یا عمومی به دادههای مهم (مثلاً صورتحسابها یا اطلاعات پرداخت)
P3 – دسترسی، حذف و تغییر دادههای خصوصی (اطلاعات شخصی محدود: نام، آدرس، غیره)
P4 – دسترسی به هر دادهی بیاهمیت
نحوهی پیشگیری از آسیبپذیریهای IDOR
اول از همه باید در هنگام ایجاد یک برنامهی کاربردی تمام درخواستهای عادی، Ajax و API کنترل شود. مثلاً آیا کاربر Read-Only میتواند چیزی را در برنامهی کاربردی بنویسد؟ یا اینکه آیا یک کاربر غیرادمین میتواند به API Token که تنها باید توسط کاربر ادمین ساخته شود دسترسی داشته باشد یا آن را ایجاد کند؟ پس برای تست کردن تمام آسیبپذیریهای IDOR باید مثل یک هکر فکر کنید.
میتوانید روی برنامه کاربردی خود اجازه دسترسی را برای تمام Endpointها فراهم کنید. اگر Endpoint مربوط به «privatesection» شما شامل درخواستهای API مثل /api/privatesection/admins، /api/privatesection/console، /api/privatesection/tokens باشد، میتوانید Endpoint را برای کاربران غیرادمین بلاک کنید. همچنین برای اینکه کار مهاجم را سختتر کنید و گاهی اوقات جلوی کار او را بگیرید، میتوانید از قابلیت Hash بهره ببرید و به جای اعداد یا رشتههای عادی از مقادیر Hashشده استفاده کنید.
[۱] Create Requests