This is beta version of Ravro English website. Some dynamic texts are in Persian. If you need support, contact with support@ravro.ir.
آسیب‌پذیری iframe Injection؛ پیدای پنهان

آسیب‌پذیری iframe Injection؛ پیدای پنهان

5305

در این مطلب به آسیب‌پذیری‌ای می‌پردازیم که می‌تواند باعث انتشار بدافزارهای مختلف، سبب حمله‌ی فیشینگ یا Phishing و فریب کاربران برای ورود اطلاعات خود شود. آسیب‌پذیری iframe injection، با سوءاستفاده از تگ iframe فضایی را در یک صفحه‌ی html ایجاد می‌کند تا صفحه‌ی دیگری را بارگذاری کند. اگر بخواهیم مثالی در دنیای واقعی بزنیم، این آسیب‌پذیری این امکان را برای مهاجم فراهم می‌کند که مسیر قطار کاربران یک سامانه را به سوی مقصد جعلی موردنظر خود عوض کند. صفحه‌ی بارگذاری‌شده می‌تواند منبعی از انتشار یک بدافزار باشد، اسکریپت مخربی را اجرا کند و یا حتی برای حمله‌ی فیشینگ استفاده شود. شکارچی می‌تواند با تزریق این تگ و این صفحات به صفحه‌ای از یک سامانه‌ی تحت وب، آسیب‌پذیربودن سامانه را نسبت به آسیب‌پذیری iframe injection بررسی کند.

این آسیب‌پذیری این امکان را برای مهاجم فراهم می‌کند که مسیر قطار کاربران یک سامانه را به سوی مقصد جعلی موردنظر خود عوض کند.

در ادامه باهم آماری از حملات فیشینگ در سال ۲۰۲۰ را بررسی می‌کنیم. به معرفی اجمالی تگ iframe در html و روش‌های مختلف بهره‌جویی از آسیب‌پذیری iframe injection. می‌پردازیم و در پایان به روش‌های کشف آسیب‌پذیری iframe injection و نحوه‌ی اکسپلویت آسیب‌پذیری iframe injection می‌رسیم.

آسیب‌پذیری Iframe Injection که بود و چه کرد؟

همان‌طور که گفتیم، یکی از مواردی که هکرها در آن از آسیب‌پذیری iframe injection استفاده می‌کنند، در حمله‌های فیشینگ و برای فریب کاربران است. به گزارش استارتاپ ایرانی فعال در حوزه‌ی تحلیل و کشف بدافزار، بیت‌بان دانشگاه شریف:

تعداد حملات فیشینگ در جهان در سال ۲۰۲۰ نسبت به سال ۲۰۱۹، بیش از ۳۴٪ افزایش یافته‌اند؛

٪۲۲ از تمامی حملات سایبری، حملات فیشینگ بوده‌اند.

٪۹۷ کاربران قادر به شناسایی ایمیل‌های فیشینگ نبوده‌اند.

٪۹۵ از حملات صورت‌گرفته بر شبکه‌های شرکت‌ها، اسپییر (spear) فیشینگ بوده‌اند.

هر حمله‌ی اسپیر فیشینگ، بطور متوسط ۱.۶ میلیون دلار به قربانیان خسارت وارد کرده‌ است.

٪۵۴ سایت‌های فیشینگ از https استفاده کرده‌اند.

٪۸۵ از سازمان‌ها، حداقل یک بار مورد حمله‌ی فیشینگ قرار گرفته‌اند.

هر ماه نزدیک به ۱.۵ میلیون سایت فیشینگ ساخته شده است.

تعداد حملات فیشینگ در جهان در سال ۲۰۲۰ نسبت به سال ۲۰۱۹ بیش از ۳۴٪ افزایش یافته‌اند.

تگ iframe چیست و چگونه کار می‌کند؟

تگ iframe به برنامه‌نویسان سامانه‌های تحت وب امکان می‌دهد که اسناد، ویدیو یا رسانه‌های تعاملی را در یک صفحه نمایش بدهند. در اغلب موارد نیز کاربرد تگ iframe، نمایش محتوا یا فایل html دیگری در لابه‌لای یک صفحه‌ی html است.

ساختار یک تگ iframe به صورت زیر است:

<iframe src=”ravro.html” title=”iframe example”></iframe>

لازم به ذکر است که همیشه آدرس یک فایل html در src قرار نمی‌گیرد و امکان دارد اسکریپتی مخرب به آن تزریق شود. هم‌چنین تگ‌هایی مانند img نیز به دلیل نمایش تصویر از جایی دیگر مشابه تگ iframe هستند و می‌توان در این تگ‌ها نیز آسیب‌پذیری را بررسی کرد.

آسیب‌پذیری iframe injection‌ نیز یکی از آسیب‌پذیری‌هایی است که بر پایه‌ی نقص در اعتبارسنجی یا Validation صورت می‌گیرد. در مطلب «اعتبارسنجی ورودی کاربر، چرا و چگونه؟» درباره‌ی اهمیت و چگونگی اعتبارسنجی ورودی کاربر بیش‌تر گفته‌ایم.

آسیب‌پذیری iframe injection را چگونه می‌توان کشف کرد؟ و چگونه می‌توان اکسپلویت کرد؟

آسیب‌پذیری iframe injection از این جهت که با دست‌کاری در تگ‌های html بروز پیدا می‌کند، شبیه آسیب‌پذیری XSS به نظر می‌رسد، اما تفاوتش با آسیب‌پذیری XSS آن‌جاست که تغییراتی در پیلود یا payload نیاز دارد. آسیب‌پذیری iframe injection بر پایه‌ی تگ iframe در html برای نمایش یک صفحه html ثانویه کاربرد دارد و شکارچی از همین طریق می‌تواند کاربر را از آدرس فعلی iframe به یک آدرس دیگر هدایت کند. شکارچی این آدرس را به تگ iframe تزریق می‌کند ( این کار معمولا به وسیله‌ی ایجاد تغییراتی در پیلود دریافتی و ارسال آن انجام می‌شود ) و به دلیل عدم اعتبارسنجی صحیح در سمت سرور، بدین ترتیب آدرس فعلی به آدرسی که مدنظر شکارچی است، تغییر می‌یابد.

یکی از سناریوهایی که آسیب‌پذیری iframe injection به وسیله‌ی آن بروز پیدا می‌کند و کشف می‌شود، بررسی ورودی‌های صفحه است.

به عنوان مثال:

یکی از سناریوهایی که آسیب‌پذیری iframe injection به وسیله‌ی آن بروز پیدا می‌کند و کشف می‌شود، بررسی ورودی‌های صفحه است.

به عنوان نمونه، در یک آدرس URL مانند زیر:

http://originalSite.com/page?iframesrc=http://originalSite.com/anotherPage

همان‌طور که می‌بینید در این صفحه یک تگ iframe وجود دارد که خصیصه‌ی src در آن مقدار iframesrc قرار می‌گیرد و آدرس دیگر در همان دامنه را نمایش می‌دهد.

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

فرض کنید یک تگ iframe به صورت زیر در صفحه موجود است:

<iframe src=”http://originalSite.com/”></iframe>

و ورودی‌های صفحه در آدرس URL صفحه مانند نمونه‌ی قبل به صورت زیر مشخص هستند:

http://originalSite.com/page?iframesrc=http://originalSite.com/anotherPage

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

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

http://originalSite.com/page?iframesrc=http://originalSite.com/anotherPage"></iframe><h1>I’m Hunter!</h1>

چگونه می‌توان از بروز آسیب‌پذیری iframe injection جلوگیری کرد؟

تا جایی که امکان دارد نباید ورودی کاربران در آدرس URL به کار برده شود یا به عبارت دیگر، بهتر است در ارسال ورودی‌ها از متد POST به جای متد GET استفاده شود و یا ورودی کاربر چه در مبدا یعنی سمت کاربر و چه در سمت سرور کنترل شود.

اگر از آدرس‌های URL‌ای استفاده می‌شود که پویا هستند و تغییر می‌کنند، از Whitelist برای تمایز آدرس‌های معتبر و نامعتبر استفاده شود تا از دخالت آدرس‌های نامعتبر جلوگیری شود.

باید اطمینان حاصل کرد که تنها آدرس‌های URL‌ای پذیرفته هستند که به دامنه‌های مورد اعتماد اشاره می‌کنند.

سخن آخر

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

منابع:

https://secnhack.in/iframe-injection-attacks-and-mitigation/

https://infosecwriteups.com/when-i-found-iframe-injection-and-illegal-redirect-dom-based-cfbbcec21a7