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

آشنایی با حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

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

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

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

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

[caption id="attachment_711" align="aligncenter" width="300"] حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه[/caption]

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

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

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

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

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

برای درک بهتر موضوع حملات ارجاع مستقیم ناامن به اشیا داخلی برنامه، دو مثال زیر را بیان می‌نماییم.

مثال اول از حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

برای مثال فرض کنید کاربر به یک صفحه وب که نیاز به احراز هویت یا Authentication دارد، وارد می‌شود و سپس احراز هویت شده و وارد صفحه کاربری خود می‌گردد. پس‌ازآن فهرستی از اسناد و نمونه کارهای خود را که می‌تواند آن‌ها را ویرایش و بررسی نماید خواهد دید. زمانی که کاربر با استفاده از مرورگر خود تصمیم به مشاهده نمونه کارها می‌نماید، یک درخواست یا Request با شناسه‌ی نمونه کار، به‌عنوان یک مقدار پارامتر URL برای سرور ارسال می‌گردد. در سمت سرور احراز هویت قبلی را در نظر داشته و صحت درخواست را تائید می‌نماید و از شناسه نمونه کار، برای بازیابی اطلاعات استفاده می‌کند و سپس آن را در یک پاسخ برای نمایش در مرورگر کاربر ارسال می‌نماید.

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

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

[caption id="attachment_712" align="aligncenter" width="256"] مثال حملات IDOR[/caption]

مثال دوم از حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

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

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

تست نفوذ در حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

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

الف) شناسایی ورودی‌های درخواست (پارامترها، Header ها و غیره) که شامل ارجاع‌های مستقیم از قبیل شناسه‌ها، کلیدها، فایل‌ها، منابع و غیره هستند.

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

[caption id="attachment_713" align="aligncenter" width="256"] تست نفوذ در حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه[/caption]

شناسایی حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

به‌عنوان‌مثال فرض کنید، متوجه شده‌اید که آدرس URL زیر، زمانی که ما برای مشاهده جزئیات یک مشتری یا کاربر استفاده می‌کنیم، در نظر گرفته‌شده است.

Https:\\shekaf.org\\myapplication\\getCustomer?id=678

با وارد شدن به آدرس بالا، یک پاسخ از سرور به سمت مرورگر ارسال می‌شود که اطلاعات مشتری موردنظر را نشان می‌دهد.

در اینجا غیرمنطقی نخواهد بود که فرض کنیم، جزئیات مشتری مورد درخواست توسط شناسه پرس‌وجو "id" و مقدار 678 به‌عنوان یک ارجاع منحصربه‌فرد و یکتا، برای مشتری موردنظر اعمال‌شده است.

برای تشخیص اینکه آیا پارامتر "id" یک ارجاع مستقیم شیء هست یا خیر، باید با استفاده از ابزارهای پروکسی وب، همچون Burp Suite مقدار پارامتر id را تغییر دهیم و سپس آن را به سمت سرور ارسال نماییم و یکی از سه حالت زیر در پاسخ برای ما ارسال خواهد شد.

الف) برنامه کاربردی وب با توجه به ورودی بدون نقص عمل کرده و پاسخی را نشان می‌دهد که اطلاعات درخواست شده در دسترس نیست.

ب) برنامه کاربردی وب با توجه به ورودی با نقص عمل کرده و یک استثنا غیرمجاز را راه‌اندازی می‌کند و یک کد پاسخ HTTP 5XX که نشان‌دهنده خطا است را نشان می‌دهد.

ج) برنامه کاربردی وب، اطلاعات مشتری مربوط به مقدار ارائه‌شده، در پارامتر id را، نشان می‌دهد.

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

در تست و ارزیابی و تشخیص حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR می‌توان به ابزارهای قدرتمندی همچون Burp Suite و OWASP ZAP اشاره نموده که در بحث امنیت سایت از این دو ابزار به فراوانی استفاده می‌شود.

جلوگیری از حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

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

• 
  

  اعتبار سنجی منطقی ارجاع‌ها یا Logically Validate References

  
  

در این رویکرد هر برنامه کاربردی وب، باید تمام ورودی‌های غیرقابل‌اعتماد یا Untrusted را با هر درخواست HTTP دریافت کرده و سپس آن‌ها را تائید یا Validate نماید. برنامه کاربردی وب باید حداقل یک لیست سفید تائید شده از هر ورودی داشته باشد. این بدین معنی است که مقدار ورودی، مطابق با انتظارات برنامه‌ها برای آن ورودی باشد. مثلاً:

حداقل و حداکثر طول ورودی مشخص شود.

حداقل و حداکثر امتیاز ورودی برای مقادیر عددی مشخص گردد.

کاراکترهای قابل‌قبول برای ورودی مشخص گردند.

نوع داده، مانند String،Data،Integer مشخص گردد.

الگوها، مانند شماره تلفن‌ها مشخص گردند.

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

• 
  

  استفاده از ارجاع‌های غیرمستقیم یا Use Indirect References

  
  

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

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

[caption id="attachment_714" align="aligncenter" width="256"] انواع حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه[/caption]

انواع حملات ارجاع مستقیم ناامن به اشیاء داخلی برنامه یا حملات IDOR

 

1- حملات Change Secret

هکر با استفاده از برنامه‌هایی همچون Tamper Date و Burp Suite بسته‌های ارسالی از مرورگر به وب‌سایت را کنترل کرده و تغییراتی را در آن‌ها ایجاد می‌نماید. در این نوع از حملات IDOR، هکر به دلیل ضعف در ارجاع مستقیم به اشیا داخلی برنامه، سعی بر تغییر رمز عبور دیگر کاربران وب‌سایت را خواهد داشت.

2- حملات Reset Secret

این نوع حملات نیز با سناریویی کاملاً مشابه با حملات Change Secret صورت می‌پذیرد و در آن هکر با استفاده از Object های مربوط به عملکرد Reset Secret، سعی می‌کنند تا پسورد کاربران وب‌سایت را Reset نمایند.

3- حملات Order Tickets

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