Search
Close this search box.
، ،

آسیب‌پذیری CSRF چیست؟

بهار قربانپور
اشتراک‌گذاری در:
آسیب‌پذیری CSRF

آسیب‌پذیری CSRF، یک حمله سایبری است که کاربر را به انجام یک اقدام ناخواسته با استفاده از اعتبار خود در یک برنامه وب فریب می‌دهد.

اصطلاح CSRF کوتاه‌شدۀ عبارت Cross Site Request Forgery به معنای جعل درخواست سایت متقابل است که از اعتماد یک برنامه وب به یک کاربر معتبر سوءاستفاده می‌کند.

حملات CSRF با حملات cross-site scripting که به‌اختصار (XSS) نامیده می‌شوند متفاوت است؛ زیرا این نوع حملات (XSS) نیاز به احراز هویت دارند درحالی‌که در CSRF این‌گونه نیست.

اثرات مخرب آسیب‌پذیری CSRF

همان‌طور که در مقدمه، عنوان شد این نوع حمله، به‌معنای جعل درخواست سایت است. (یا نزد متخصصان امنیت و شبکه، به‌طور خلاصه، CSRF نامیده می‌شود).

از آن‌جایی که CSRF به مهاجم (هکر) اجازه می‌دهد تا کاربران را وادار به انجام اقداماتی کند که قصد انجام آن را ندارند نوعی آسیب‌پذیری امنیتی وب به شمار می‌رود.

در این نوع حمله (Attack)، مهاجم (Hacker) تا حدی پیش می‌رود که تمام امور سایت را به دست می‌گیرد و عملاً کنترل سایت از دست کارشناسان، خارج می‌شود.

در یک حمله موفق CSRF، مهاجم باعث می‌شود کاربرِ قربانی، «ناخواسته» کاری را انجام دهد که نباید. به‌عنوان مثال، تغییر ادرس ایمیل در حساب خود، تغییر رمز عبور خود و یا انتقال وجه به آدرس و لینکی که به آن اعتماد دارد اما در واقع، جعلی است.

نکته: باتوجه‌به ماهیت عمل، مهاجم ممکن است بتواند کنترل کامل حساب کاربر را به‌دست آورد.

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

پیشنهاد مطالعه: حمله VLAN Hopping چیست؟/راه‌های جلوگیری از آن

آسیب‌پذیری CSRF چگونه عمل می‌کند؟

سه شرط کلیدی لازم برای وقوع حملۀ CSRF و موفقیت آن:

حملۀ CSRF چگونه عمل می‌کند؟

1. اقدام مرتبط در آسیب‌پذیری CSRF

به این معناست که یک عامل در برنامه، مهاجم (hacker) را ترغیب می‌کند تا دست به اقدام و حمله بزند. مثلاً اجازۀ دسترسی به سایت به تعداد زیادی از کارکنان سازمان یا تغییر رمز عبور کاربر توسط خود او.

2. راهبری مبتنی بر کوکی

این اقدام شامل صدور یک یا چند درخواست HTTP است؛ به‌عبارت‌بهتر، برنامه، برای شناسایی کاربری که درخواست‌ها را انجام داده است، تنها به کوکی‌های جلسه متکی است. این یعنی هیچ مکانیسم دیگری برای ردیابی جلسات یا اعتبارسنجی درخواست‌های کاربر وجود ندارد.

3. بدون پارامترهای درخواست غیر قابل‌ پیش‌بینی

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

به‌عنوان مثال، فرض کنید یک برنامه، حاوی یک تابع است که به کاربر اجازه می‌دهد آدرس ایمیل را در حساب خود تغییر دهد. هنگامی که کاربر، این عمل را انجام می‎‌دهد یک درخواست HTTP مانند زیر ایجاد می‌کند

البته این کار، به شرایط مورد نیاز برای CSRF منطبق است که عبارتند از:

  • تغییر ادرس ایمیل در حساب کاربری، مورد توجه مهاجم (Hacker) است. پس از این اقدام، مهاجم، به طور معمول، قادر به تنظیم مجدد رمز عبور و کنترل کامل حساب کاربر خواهد بود.
  • این برنامه، برای شناسایی این‌که کدام کاربر درخواست را صادر کرده است از یک session cookie استفاده می‌کند. در واقع، هیچ نشانه یا مکانیسم دیگری برای ردیابی جلسات کاربر وجود ندارد.
  • مهاجم(hacker) به‌راحتی می تواند مقادیر پارامترهای درخواست مورد نیاز برای انجام عمل را تعیین کند.

با استفاده از این شرایط، مهاجم (Hacker) می‌تواند یک صفحه وب حاوی HTML به شکل زیر بسازد.

اگر کاربر قربانی، از صفحۀ وب مهاجم (hacker) بازدید کند موارد زیر رخ می‌دهد:

  • صفحۀ مهاجم، یک درخواست HTTP به وب‎‌سایت آسیب‌پذیر، راه‌اندازی می‌کند.
  • اگر قربانی، وارد وب‌سایت آسیب‌پذیر شده باشد مرورگر او، به‌طور خودکار،  session cookie خود را در درخواست اضافه می‌کند (با فرض این‌که از کوکی‌های SameSite استفاده نمی‌شود).
  • وب‌سایت آسیب‌پذیر، درخواست را به روش عادی پردازش می‌کند؛ یعنی آن را به‌گونه‌ای تلقی می‌کند که توسط کاربر قربانی انجام شده است و آدرس ایمیل او را تغییر می‌دهد.

نکته: اگرچه CSRF، معمولاً در رابطه با مدیریت جلسه مبتنی بر کوکی توصیف می‌شود؛ اما در زمینه‌های دیگری نیز رخ می‌دهد مثلاً وقتی که در آن برنامه، به طور خودکار، اعتبار کاربر، به درخواست‌ها اضافه می‌شود. مانند احراز هویت پایه HTTP و تأیید اعتبار مبتنی بر گواهی.

نحوۀ طرح‌ریزی و ساخت یک حملۀ CSRF

نحوۀ طرح‌ریزی و ساخت یک حملۀ CSRF

ایجاد دستی HTML مورد نیاز برای یک اکسپلویت CSRF می‌تواند دست‌وپا گیر باشد؛ به‌خصوص در مواردی که درخواست مورد نظر، حاوی تعداد زیادی پارامتر باشد؛ یا موارد عجیب و غریب دیگری در درخواست وجود داشته باشد. ساده‌ترین راه برای ایجاد یک اکسپلویت CSRF، استفاده از  CSRF PoC generator است که در Burp Suite Professional و تحت این شرایط تعبیه شده است:

  • درخواستی را در هر جایی از Burp Suite Professional وارد نمایید که می‌خواهید آزمایش یا بهره‌برداری کنید.
  • از منوی زمینه کلیک راست، Engagement tools / Generate CSRF PoC را انتخاب کنید.
  • Burp Suite مقداری HTML ایجاد می‌کند که درخواست انتخاب شده را فعال می‌نماید (منهای کوکی‌ها، که به‌طورخودکار، توسط مرورگر قربانی اضافه می‌شوند).
  • می‌توانید گزینه‌های مختلفی را در  CSRF PoC generator تغییر دهید تا جنبه‌های حمله را تنظیم نمایید. ممکن است لازم باشد این کار را در برخی موقعیت‌های غیرعادی انجام دهید تا با ویژگی‌های عجیب درخواست‌ها مقابله کنید.
  • HTML تولید شده را در یک صفحه وب کپی کنید؛ آن را در مرورگری که در وب‌سایت آسیب‌پذیر وارد شده است مشاهده و آزمایش کنید که آیا درخواست مورد نظر با موفقیت صادر شده است یا خیر.

نحوه ارائۀ اکسپلویت CSRF

مکانیسم‌های تحویل برای حملات جعل درخواست متقابل سایت (CSRF) اساساً مانند XSS منعکس شده است.

به‌طور معمول، مهاجم (Hacker) ، HTML مخرب را در وب‌سایتی که کنترل می‌کند قرار می‌دهد و سپس قربانیان را وادار می‌سازد که از آن وب‌سایت بازدید کنند.

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

نکته: برخی از اکسپلویت‌های ساده CSRF از روش GET استفاده می‌کنند و می‌توانند به طور کامل با یک URL واحد در وب‌سایت آسیب‌پذیر، جاخوش کرده باشند.

در این شرایط، هکر ممکن است نیازی به استفاده از یک سایت خارجی نداشته باشد و می‌تواند مستقیماً یک URL مخرب در دامنۀ آسیب‌پذیر به قربانیان ارسال کند.

در مثال قبل، اگر درخواست تغییر آدرس ایمیل را بتوان با متد GET انجام داد در آن صورت، یک حملۀ خودخواسته، به شکل زیر خواهد بود:

دفاع رایج در برابر آسیب‌پذیری CSRF

دفاع رایج در برابر CSRF

حفاظت یا دفاع موفق در برابر آسیب‌پذیری‌ CSRF، اغلب شامل: این موارد است:

CSRF tokens

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

SameSite cookies 

SameSite یک مکانیسم امنیتی مرورگر است که تعیین می‌کند چه زمانی در درخواست‌هایی که از سایر وب‌سایت‌ها نشأت می‌گیرند کوکی‌های یک وب‌سایت، گنجانده می‌شوند.

درخواست‌ها، برای اقدامات حساس، به یک session cookie تأیید شده نیاز دارند؛ بنابراین محدودیت‌های SameSite مناسب ممکن است مانع از راه‌اندازی اقدامات بین‌سایتی توسط مهاجم شود.

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

Referer-based validation

برخی از برنامه‌ها از سرفصل دستوری HTTP برای دفاع در برابر CSRF استفاده می‌کنند؛ (معمولاً با تأیید این‌که درخواست، از دامنه خود برنامه منشا گرفته است.) این، به‌طور کلی، کم‌تر از اعتبارسنجی توکن CSRF موثر است.

+پیشنهاد مطالعه: Quishing چیست؟ چگونه می‌توان از حمله Quishing جلوگیری کرد؟

نظرات ارزشمند شما

بدون دیدگاه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *