مدیریت نشست[۲] برنامههای کاربردی تحت وب و موبایل، برای کاربران پایانی[۳] بسیار مهم است. مدیریت نشست از دو قسمت مهم احراز هویت[۴] و مجوز دسترسی[۵] تشکیل شده است. بخش احراز هویت به سوال «من کیستم؟» و قسمت مجوز دسترسی به سوال «چه کاری می توانم انجام دهم؟» پاسخ میدهد. به طور مثال و به زبان ساده، مجوز دسترسی برای یک فایل در سیستمعامل لینوکس به صورت Read، Write و Execute مشخص میشود و اگر این سطوح دسترسی به درستی استفاده نشوند، امکان نقض حریم خصوصی و آسیبپذیری وجود دارد. یکی از این آسیبپذیریهای مهم، آسیبپذیری IDOR نام دارد. در ادامه به توضیح در خصوص آسیبپذیری IDOR یا Insecure Direct Object Renfrences و روشهای تست این آسیبپذیری خواهیم پرداخت.
آسیبپذیری IDOR چیست
ممکن است متغیرهای زیادی مثل «id»، «pid» و «uid» در برنامه کاربردی وجود داشته باشد. بااینکه معمولاً به این مقادیر بهعنوان پارامترهای HTTP نگاه میشود، میتوان آنها را در Headerها و کوکیها نیز دید. مهاجم میتواند با تغییر مقادیر به هر یک از Objectهای کاربران دسترسی پیدا کرده و آنها را ویرایش یا حذف کند. این آسیبپذیری IDOR نام دارد.
در ابتدا لازم است جریان برنامه کاربردی که توسط توسعهدهندگان نرمافزار ایجاد میشود را درک کنید. وقتی که کاربر وارد برنامه کاربردی وب یا موبایل میشود، باید تمام کاربردهای ماژولها و زیر ماژولهای[۶] آن سنجیده شود. همچنین باید به خاطر داشت که این آسیبپذیری به اندازهی XSS و SCRF در تست امنیتی خطرناک است و نوعی از آسیبپذیری است که به سادگی کشف نمیشود (تست خودکارسازی شده یا دستی).
در این مطلب به موضوعات زیر پرداخته خواهد شد:
- نحوهی پیدا کردن نقطهی نفوذ برای آسیبپذیریهای IDOR.
- برخی از توصیههای مربوط به آسیبپذیری IDOR که بسیار ساده هستند و بیشترین کاربرد را دارند.
- نکاتی که باید در هنگام تست آسیبپذیری IDOR رعایت کرد.
- نحوهی فراهم کردن کنترلهای احراز هویت ابتدایی.
نحوه انجام تست کارآمد و سریع برای آسیبپذیری IDOR
با استفاده از پنجره مخفی[۷] مرورگر، میتوان به سرعت آسیبپذیریهای IDOR را تست کرد. هنگام استفاده از پنجره معمولی به عنوان یک کاربر ساده، میتوان بهعنوان یک مهاجم از پنجره مخفی استفاده کرد. این کار، تضمینی برای حضور مستمر و عدم خروج[۸] از سیستم است.
میتوان برای چک کردن تمام درخواستها از پنجره HTTP History در نرمافزار Burp Suite استفاده کرد. ویژگی HTTP History تمام ترافیک بین دستگاه (مرورگر، گوشی، تبلت) و سرور برنامه کاربردی را نشان میدهد. همچنین میتوان از ویژگی Scope در Burp Suite برای تست سریع استفاده کرد، زیرا ویژگی Scope برای ایجاد لیست هدف مفید بوده و تنها اجازهی نمایش دادههای مرتبط برای محدوده تست کاربر را میدهد.
مثلاً شرکت امنپردازان کویر تست شد و محدوده آن فقط تحت عنوان apk-Group.net روی صفحهی Scope نمایش داده میشود. در این صورت میتوان با راستکلیک روی یک درخواست، Scope مرتبط را اضافه نمود. میتوان مقدار محدوده اضافی را با توجه به محدوده دادهشده، ویرایش نمود. نهایتاً باید با انتخاب گزینهی «Show only in-scope items» در پنجره HTTP History فیلترینگ لازم را انجام داد.
این کار کمک میکند که بتوان نقشها را در برنامه کاربردی بهتر درک کرد؛ نقشهایی مثل Read-Only، Normal، Super و غیره.
بازسازی تمام درخواستها
در هنگام تست آسیبپذیری IDOR، باید تمام درخواستهایی که برنامه کاربردی وب یا موبایل ایجاد میکند را بازسازی کنید. زیرا اگر چیزی را در برنامه کاربردی تغییر داده باشید، امکان ایجاد درخواستهای دیگر با استفاده از آن بهوجود میآید. اگر تمام درخواستهای API برنامه کاربردی مثل فایل WSDL، صفحهی Swagger و غیره را داشته باشید و همهچیز به خوبی کار کند، خوش شانس هستید. میتوان از این امکان استفاده کرد و به راحتی تست آسیبپذیری IDOR را انجام داد.
بهعنوانمثال میتوان به یک برنامهی خصوصی اشاره کرد. اطلاعات کارتهای اعتباری پس از انجام خرید در برنامه کاربردی موبایل اضافه میشود. پس از اینکه درخواستها تست شدند، ممکن است فکر کنید که هیچ آسیبپذیری وجود ندارد. اما وقتی خرید دوم انجام شد، صفحهی انتخاب کارت اعتباری دیده میشود و آسیبپذیری IDOR در این نقطه قرار دارد. وقتی در اینجا یک کارت اعتباری را انتخاب میکنید، برنامه کاربردی ID آن کارت را در درخواستی به سرور میفرستد و این درخواست با تغییر ID کارت اعتباری، دسترسی را به دادههای کارتهای اعتباری کاربران دیگر فراهم میکند.
در یک برنامهی خصوصی دیگر، برنامه کاربردی وب در سیستم پیامرسانی داخل برنامه وجود دارد. کاربر میتواند پیامهایی را به کاربران دیگر ارسال کرده و آنها را به پیامهای خود اضافه نماید. وقتی کاربر تلاش میکند به یکی از پیامهای خود دسترسی پیدا کند، یک درخواست به «/messages/5955» ارسال میشود و به نظر میرسد ID پیام ۵۹۵۵ است. همچنین وقتی سعی کنید با ارسال درخواست به «/messages/5955» به پیام کاربر دیگری دسترسی پیدا کنید، دسترسی به پیام حاصل نمیگردد. وقتی یک کاربر بخواهد کاربر دیگری را به پیام خود اضافه کند، درخواستی مثل درخواست زیر دیده میشود:
POST /messages/5955/invite HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0Accept: */*X-Requested-With: XMLHttpRequestCookie: my_cookiesConnection: closeuser=testaccount2
و وقتی این درخواست بررسی شود، کاربر میتواند خود را به پیامهای کاربران دیگر اضافه کرده و به تمام پیامها دسترسی داشته باشد.
بهعلاوه نقشها در برنامه کاربردی باید به خوبی درک شوند تا آسیبپذیری IDOR شناسایی گردد. دانستن اینکه یک نقش باید چه کار کند و چه کار نکند، در مرحلهی شناسایی ضعف بسیار مفید خواهد بود. پس در ابتدا باید برنامه کاربردی را عمیقاً درک کنید.
نحوهی پیدا کردن نقاط نفوذ
همانطور که قبلاً گفته شد، میتوان با استفاده از تمام ویژگیهای برنامه کاربردی، درخواستهای بسیاری را برای تست آسیبپذیری IDOR پیدا کرد. وقتی Endpointهای API در تستهای آسیبپذیری IDOR فراهم نشده باشند، کد منبع html. یا فایلهای js. مفید هستند. این فایلها معمولاً شامل موارد جالب و درخواستهای Ajax هستند. تست آسیبپذیری IDOR را میتوان با استفاده از درخواستهای ارائه شده در این فایلها انجام داد. این درخواستها میتوانند قبلاً توسط برنامه کاربردی انجام شده و یا درخواستهای احتمالی آینده باشند.
اگر خوششانس باشید فقط میتوانید درخواستهایی را ببینید که یک کاربر ادمین احراز هویت شده باید در فایلهای Javascript مشاهده کند. به همین دلیل، کد منبع و مخصوصاً فایلهای Javascript باید به خوبی تجزیهوتحلیل شوند. همچنین میتوانید نسخهی قدیمی برنامه کاربردی وب را روی سایت Archive.org جستجو کنید و ممکن است بتوانید درخواستهای مفیدی را در فایلهای Javascript قدیمی پیدا کنید یا اینکه با استفاده از Dorks در موتورهای جستجو، درخواستها را جستجو نمایید.
در برخی از موارد، مقادیر ID منحصربهفرد نیستند، مثل ۱، ۲، ۳، ۱۰۰، ۱۰۰۰ و غیره، این مقادیر ID میتوانند یک مقدار کدگذاری شده یا Hashشده باشند. اگر با یک مقدار کدگذاریشده مواجه شدید، میتوانید با رمزگشایی آن آسیبپذیری IDOR را تست کنید. اگر با یک مقدار Hashشده مواجه شدید، باید تست کنید که آیا آن مقدار قابلدسترسی یا قابلپیشبینی هست یا خیر. در موردی دیگر، میتوانید در Referrer” header” به مقدار Hashشده دسترسی پیدا کنید، تا این سناریوها بازسازی شوند.
به طور مثال، نمیتوانید به Objectهای یک کاربر دیگر دسترسی پیدا کنید، اما میتوانید مقدار ID متعلق به Object که Hashشده است را در کد منبع صفحهی Object و ID متعلق به Object که Hashشده است را در یک پیام درون برنامهی کاربردی (In-App) از کاربر قربانی پیدا کنید (این کار تأثیر Bug را کاهش میدهد). پس میتوانید دو حساب تست، مثلاً X و Y را ایجاد کرده، سپس مقدار ID متعلق به X که Hash شده است را در درخواستهای Y در Burp History امتحان کنید.
بخی از درخواستهای برنامه کاربردی مانند درخواست SmartSheet که حاوی بیش از یک پارامتر است، به نظر بیش از حد پیچیده میرسندبرای پیدا کردن نقطه نفوذ در این درخواست، میتوانید از ابزار مقایسه Burp Suite استفاده کنید. باید روی درخواست راست کلیک کرده و گزینهی «Send to Comparer» را انتخاب کنید. سپس میتوانید درخواست یکسانی را برای استفاده از یک Object دیگر و ارسال به مقایسهکننده بسازید.
هنگام استفاده از ابزار مقایسه با کلیک روی گزینهی Words، یک پنجره برای تغییر نقاط را مشاهده خواهید کرد. میتوانید از روش یکسانی برای پاسخهای HTTP استفاده کنید و تفاوتهای آنها را بررسی نمایید.
در بخش دوم این مطلب، به معرفی نمونههایی از باگهای آسیبپذیری IDOR میپردازیم و نرمافزارهای مفید برای تست این آسیبپذیری را معرفی خواهیم کرد.
[۲] Session
[۳] End Users
[۴] authentication
[۵] authorization
[۶] Sub-Modules
[۷] Secret Tab
[۸] Logout