خانه / بلاگ / امنیت
Clickjacking چیست و چگونه می‌تواند کاربران یک سایت را فریب دهد؟
امنیت ۱۳ دقیقه مطالعه

Clickjacking چیست و چگونه می‌تواند کاربران یک سایت را فریب دهد؟

📅 سه‌شنبه ۱۴۰۵/۰۷/۰۷ • 👁 ۴ بازدید • zqz.ir

امنیت یک وب‌سایت فقط به رمز عبور، HTTPS یا جلوگیری از حملات سروری محدود نمی‌شود. گاهی مهاجم بدون اینکه مستقیماً سایت را هک کند، از نحوه نمایش صفحات در مرورگر سوءاستفاده می‌کند تا کاربر را به انجام کاری وادار کند که خودش از آن خبر ندارد. یکی از حملاتی که دقیقاً از این روش استفاده می‌کند Clickjacking یا «کلیک‌ربایی» است. در این حمله، ظاهر صفحه چیزی را به کاربر نشان می‌دهد، اما کلیکی که کاربر انجام می‌دهد ممکن است در واقع روی یک عنصر مخفی یا پوشانده‌شده از سایت دیگری ثبت شود.

Clickjacking چیست؟

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

برای مثال، تصور کنید یک مهاجم صفحه‌ای با عنوان «دریافت جایزه» ایجاد کرده است. کاربر یک دکمه بزرگ با عنوان «دریافت جایزه» می‌بیند، اما در لایه دیگری، صفحه‌ای از یک سرویس دیگر قرار گرفته است و کلیک کاربر در واقع روی دکمه‌ای مانند «تغییر تنظیمات»، «تأیید» یا یک عملیات حساس ثبت می‌شود.

Clickjacking چگونه انجام می‌شود؟

یک سناریوی ساده می‌تواند به این شکل باشد:

  1. مهاجم یک صفحه فریبنده ایجاد می‌کند.
  2. صفحه هدف را داخل یک iframe قرار می‌دهد.
  3. ظاهر فریم را با لایه‌ها یا عناصر دیگر صفحه هماهنگ می‌کند.
  4. کاربر تصور می‌کند روی دکمه‌ای مشخص کلیک می‌کند.
  5. کلیک در واقع روی عنصر دیگری در صفحه هدف انجام می‌شود.

نمونه بسیار ساده‌ای از یک iframe به شکل زیر است:

<iframe src="https://example.com/account"></iframe>

البته یک حمله واقعی معمولاً فقط به قرار دادن iframe محدود نمی‌شود و مهاجم تلاش می‌کند ظاهر آن را با رابط کاربری صفحه خود ترکیب کند تا کاربر متوجه عملیات واقعی نشود.

چرا Clickjacking خطرناک است؟

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

برای مثال، یک صفحه حساب کاربری ممکن است عملیات زیر را ارائه دهد:

  • تغییر تنظیمات حساب
  • تأیید یک عملیات
  • فعال یا غیرفعال کردن یک قابلیت
  • حذف یک مورد
  • ارسال یک درخواست
  • تغییر برخی تنظیمات امنیتی

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

Clickjacking چه تفاوتی با Phishing دارد؟

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

نقش iframe در Clickjacking

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

جلوگیری از Clickjacking با X-Frame-Options

یکی از روش‌های قدیمی و همچنان کاربردی برای محدود کردن نمایش صفحات در فریم، هدر HTTP با نام X-Frame-Options است.

برای جلوگیری کامل از قرار گرفتن صفحه داخل frame می‌توان از مقدار DENY استفاده کرد:

X-Frame-Options: DENY

در این حالت مرورگر اجازه نمی‌دهد صفحه در یک frame از هر مبدأیی نمایش داده شود.

اگر سایت باید در صفحات همان Origin خودش داخل فریم نمایش داده شود، مقدار SAMEORIGIN نیز وجود دارد:

X-Frame-Options: SAMEORIGIN

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

روش مدرن‌تر: Content-Security-Policy و frame-ancestors

برای کنترل دقیق‌تر اینکه چه سایت‌هایی می‌توانند صفحه شما را در iframe قرار دهند، می‌توان از دستور frame-ancestors در هدر Content-Security-Policy استفاده کرد.

برای مسدود کردن Embed شدن صفحه توسط هر سایت:

Content-Security-Policy: frame-ancestors 'none'

برای اجازه دادن به صفحات همان Origin:

Content-Security-Policy: frame-ancestors 'self'

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

X-Frame-Options یا frame-ancestors؟

این دو هدر نقش مشابهی در کنترل Frame شدن صفحه دارند، اما frame-ancestors در CSP کنترل دقیق‌تری فراهم می‌کند. در بسیاری از پیاده‌سازی‌ها، استفاده هم‌زمان از سیاست CSP و X-Frame-Options به‌عنوان یک لایه دفاعی اضافی مورد استفاده قرار می‌گیرد؛ مخصوصاً زمانی که سازگاری با مرورگرهای قدیمی‌تر نیز اهمیت دارد. نکته مهم این است که قبل از اضافه کردن این هدرها باید بررسی کنید آیا سایت شما واقعاً به iframe شدن توسط سایت‌های دیگر نیاز دارد یا خیر.

SameSite چه کمکی می‌کند؟

تنظیم ویژگی SameSite برای کوکی‌های نشست می‌تواند به‌عنوان یک لایه دفاعی دیگر در برابر برخی سناریوهای Clickjacking مورد استفاده قرار گیرد. برای مثال، کوکی‌های حساس می‌توانند با سیاستی مانند Lax یا Strict تنظیم شوند. این تنظیم می‌تواند باعث شود در برخی درخواست‌های Cross-Site، کوکی نشست کاربر ارسال نشود. با این حال، SameSite جایگزین کنترل Frame شدن صفحه نیست و بهتر است به‌عنوان بخشی از یک راهکار دفاعی چندلایه در نظر گرفته شود.

یک اشتباه رایج: استفاده از Meta Tag

گاهی برای جلوگیری از Clickjacking پیشنهاد می‌شود تنظیمات مربوط به X-Frame-Options داخل یک Meta Tag در HTML قرار گیرد. این روش برای اعمال هدر X-Frame-Options قابل اتکا نیست. چنین سیاستی باید در سطح Response HTTP توسط سرور ارسال شود.

به عبارت ساده، این کار درست نیست:

<meta http-equiv="X-Frame-Options" content="DENY">

بهتر است هدر امنیتی توسط وب‌سرور، تنظیمات PHP یا سایر لایه‌های زیرساخت ارسال شود.

نمونه پیاده‌سازی در PHP

در یک پروژه PHP می‌توان هدر را قبل از ارسال خروجی HTML تنظیم کرد:

<?php

header('X-Frame-Options: DENY');
header("Content-Security-Policy: frame-ancestors 'none'");

?>

در یک پروژه واقعی باید توجه داشت که این تنظیم ممکن است قابلیت‌هایی را که عمداً از iframe استفاده می‌کنند از کار بیندازد. بنابراین باید قبل از اعمال سراسری، معماری سایت بررسی شود.

چگونه وجود Clickjacking را بررسی کنیم؟

برای بررسی وضعیت امنیتی صفحات سایت، یکی از اولین مواردی که می‌توان بررسی کرد Response Headerهای HTTP است. برای مثال، می‌توان با ابزارهایی مانند curl هدرهای پاسخ یک صفحه را مشاهده کرد:

curl -I https://example.com

سپس بررسی کنید آیا هدرهایی مانند موارد زیر وجود دارند یا خیر:

X-Frame-Options: DENY

Content-Security-Policy: frame-ancestors 'none'

البته صرف وجود یک هدر به‌تنهایی به معنی امن بودن کامل سایت نیست. امنیت باید متناسب با عملکرد صفحه و سایر تهدیدهای موجود بررسی شود.

آیا همه صفحات سایت باید iframe را مسدود کنند؟

خیر. این موضوع کاملاً به کاربرد صفحه بستگی دارد.

برای مثال، یک صفحه مدیریتی یا صفحه‌ای که شامل عملیات حساس حساب کاربر است ممکن است اصلاً نیازی به Embed شدن نداشته باشد و بتوان آن را از Frame شدن منع کرد. در مقابل، برخی سرویس‌ها عمداً Widget یا محتوای قابل Embed ارائه می‌کنند. در این شرایط باید به جای مسدود کردن کامل Frame، فقط Originهای مورد اعتماد را مشخص کرد. هدف این نیست که iframe را در تمام سایت‌ها بدون استثنا غیرفعال کنیم؛ هدف این است که دسترسی به Frame شدن، آگاهانه و کنترل‌شده باشد.

Clickjacking و لینک‌های کوتاه

یک نکته مهم برای سرویس‌های کوتاه‌کننده لینک این است که خود لینک کوتاه به‌تنهایی باعث Clickjacking نمی‌شود. مهاجم ممکن است از یک لینک کوتاه برای هدایت کاربر به یک صفحه فریبنده استفاده کند، اما Clickjacking معمولاً در مرحله‌ای اتفاق می‌افتد که صفحه هدف در یک Frame یا ساختار مشابه نمایش داده می‌شود. بنابراین در یک پلتفرم مدیریت لینک مانند zqz.ir بهتر است تمرکز امنیتی فقط روی URL کوتاه نباشد و مقصد لینک، رفتار Redirect، اعتبارسنجی URL و امنیت صفحات مقصد نیز در نظر گرفته شود.

آیا Redirect باعث Clickjacking می‌شود؟

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

چک‌لیست جلوگیری از Clickjacking

  • صفحات حساس را تا حد امکان در iframe قابل نمایش نکنید.
  • برای صفحات مناسب از Content-Security-Policy و frame-ancestors استفاده کنید.
  • در صورت نیاز برای سازگاری بیشتر از X-Frame-Options نیز استفاده کنید.
  • کوکی‌های نشست را با سیاست مناسب SameSite تنظیم کنید.
  • قبل از اعمال DENY یا frame-ancestors 'none' بررسی کنید که Embed شدن صفحه موردنیاز نباشد.
  • عملیات حساس را در سمت سرور نیز به‌درستی احراز هویت و مجوزدهی کنید.
  • امنیت را فقط به یک هدر یا یک روش دفاعی وابسته نکنید.

جمع‌بندی

Clickjacking یکی از حملاتی است که بدون نیاز به هک مستقیم سرور می‌تواند از نحوه تعامل کاربر با یک صفحه وب سوءاستفاده کند. مهاجم با ترکیب یک صفحه فریبنده و محتوای Embed شده تلاش می‌کند کاری را از طرف کاربر انجام دهد که او تصور دیگری درباره آن دارد.

یکی از مهم‌ترین راهکارهای مقابله با این تهدید، کنترل دقیق امکان Frame شدن صفحات است. استفاده از Content-Security-Policy با دستور frame-ancestors و در صورت نیاز X-Frame-Options می‌تواند بخش مهمی از این ریسک را کاهش دهد.

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

امتیاز این مطلب

—
هنوز رأی‌ای ثبت نشده
امتیاز شما به این مطلب

برای امتیاز دادن وارد حساب شوید

لینک کوتاه این مطلب

https://zqz.ir/RFhACU

اشتراک‌گذاری

لینک‌های بلند را در چند ثانیه کوتاه کنید

شروع رایگان در zqz.ir راهنمای استفاده

نظرات (۰)

هنوز نظری تأیید نشده است.

ارسال نظر

برای ارسال نظر باید عضو شوید و وارد حساب کاربری خود شوید.

ورود ثبت‌نام رایگان