درک حملات جعل درخواست بین سایتی (CSRF): چگونه کار می کنند و چگونه از آنها جلوگیری کنیم
CSRF از اعتماد مرورگر برای ربودن اقدامات کاربر سوء استفاده می کند. یاد بگیرید که چگونه کار می کند و چگونه از برنامه های وب خود دفاع کنید
جعل درخواست های بین سایتی (CSRF) یک آسیب پذیری امنیتی وب حیاتی است که از اعتماد یک برنامه وب به یک کاربر تأیید شده سوء استفاده می کند. برخلاف سایر حملات که مستقیماً مکانیسم‌های امنیتی یک برنامه وب را هدف قرار می‌دهند، CSRF یک کاربر وارد شده را فریب می‌دهد تا به طور ناآگاهانه اقدامات ناخواسته را در وب‌سایتی که در آن احراز هویت می‌شوند، اجرا کند. این حمله به‌ویژه خطرناک است، زیرا از نحوه استفاده مرورگرها با توکن‌های احراز هویت، مانند کوکی‌ها، استفاده می‌کند و آن را برای برنامه‌های کاربردی وب که به احراز هویت مبتنی بر جلسه متکی هستند، به خطری دائمی تبدیل می‌کند.
در این مقاله، نحوه عملکرد CSRF، چرایی انحصار آن برای برنامه‌های کاربردی وب و چگونگی استفاده مهاجمان از مهندسی اجتماعی برای سوء استفاده از این آسیب‌پذیری را توضیح خواهیم داد. همچنین بحث خواهیم کرد که چرا مکانیسم‌های امنیتی مدرن، مانند سیاست‌های همان منبع (SOP) و اشتراک‌گذاری منابع متقاطع (CORS)، نقش حیاتی در کاهش این حملات دارند.
حملات CSRF چگونه کار می کنند
حملات CSRF از روشی که مرورگرها به طور خودکار اعتبارنامه‌های احراز هویت (مانند کوکی‌ها، شناسه‌های جلسه یا سرصفحه‌های احراز هویت HTTP) را در هنگام درخواست به وب‌سایتی که در آن کاربر قبلاً احراز هویت شده است، استفاده می‌کنند. هدف مهاجم فریب قربانی برای ارسال ناآگاهانه درخواست مخرب به برنامه مورد نظر است.
درخواست‌های هدف برای مهاجمان آنهایی هستند که تغییراتی را روی برنامه انجام می‌دهند، مانند انتقال وجه. از آنجایی که مهاجم پاسخ‌ها را دریافت نمی‌کند، درخواست‌هایی که چیزی را تغییر نمی‌دهند و فقط داده‌ها را برمی‌گردانند برای او بی‌ارزش هستند.
چرا CSRF فقط بر برنامه های وب تأثیر می گذارد؟
حملات CSRF منحصر به برنامه های کاربردی وب هستند زیرا به مرورگر متکی هستند که به طور خودکار اعتبار ذخیره شده را ارسال می کند. هنگامی که کاربر وارد یک وب سایت می شود، مرورگر او نشانه های احراز هویت (مانند کوکی های جلسه) را حفظ می کند. اگر همان کاربر در حالی که هنوز وارد سایت شده است از یک وب سایت مخرب بازدید کند، سایت مخرب می تواند بدون اطلاع کاربر درخواست هایی را برای سایت مورد نظر آغاز کند.
در مقابل، APIهای بدون حالت که به توکن‌های دسترسی در هدرهای HTTP نیاز دارند (مانند توکن‌های حامل در OAuth2) در برابر CSRF آسیب‌پذیر نیستند. این به این دلیل است که مرورگرها به طور خودکار سرصفحه‌های مجوز را هنگام درخواست‌های متقاطع وارد نمی‌کنند و CSRF را در برابر چنین APIهایی ناکارآمد می‌سازد.
یک مثال فرضی حمله CSRF
سناریو: یک برنامه بانکداری آنلاین
تصور کنید یک کاربر به حساب بانکی آنلاین خود وارد می شود https://bank.example.com. این برنامه از کوکی ها برای حفظ احراز هویت جلسه استفاده می کند. در حالی که کاربر وارد سیستم شده است، یک ایمیل با یک پیوند به ظاهر بی ضرر دریافت می کند:
Click here to claim your reward:
از آنجایی که مرورگر هنگام بازدید به طور خودکار کوکی جلسه را شامل می شود bank.example.com، با کلیک روی پیوند، 1000 دلار به حساب مهاجم منتقل می شود بدون نیاز به احراز هویت اضافی کاربر.
CSRF با استفاده از ارسال فرم مخرب (حمله POST Request)
مهاجمان نیز می توانند اهرمی را اعمال کنند فرم های پنهان HTML برای انجام حملات CSRF سناریوی زیر را در نظر بگیرید:
قربانی از یک وب سایت مخرب حاوی HTML زیر بازدید می کند:
document.forms[0].submit();
به محض بازدید قربانی از صفحه، فرم به طور خودکار ارسال می شود و تراکنش غیرمجاز را انجام می دهد. از آنجایی که درخواست از مرورگر قربانی انجام می شود و جلسه آنها فعال است، بانک تراکنش را پردازش می کند.
نقش مهندسی اجتماعی در حملات CSRF
حملات CSRF وابسته به مهندسی اجتماعی برای فریب قربانیان به انجام اقدامات ناخواسته. تاکتیک های رایج عبارتند از:
- ایمیل های مخرب: مهاجمان ایمیل های فیشینگ حاوی لینک ها یا فرم های فریبنده ارسال می کنند.
-
تصاویر یا اسکریپت های جاسازی شده: یک حمله CSRF را می توان در یک تگ تصویر جاسازی کرد:
src="
-
وب سایت های شخص ثالث در معرض خطر: مهاجمان محموله های CSRF را به انجمن ها، تبلیغات یا صفحات وب در معرض خطر که کاربران ناآگاه از آنها بازدید می کنند، تزریق می کنند.
نمودار توالی حمله CSRF
برای درک آسان تر، بیایید به نمودار توالی زیر نگاهی بیندازیم:
چرا CSRF با برخی از روش های HTTP کار نمی کند؟
مرورگرهای مدرن این را اجرا می کنند خط مشی مبدأ یکسان (SOP) برای محدود کردن تعاملات متقابل. به عنوان بخشی از این سیاست، مرورگرها اجازه می دهند درخواستها را دریافت و ارسال کنید زمانی که کاربر احراز هویت شده روی پیوند کلیک می کند یا فرمی را بارگیری می کند، به طور خودکار ساخته می شود. با این حال، درخواست‌های PUT، DELETE و PATCH مسدود می شوند مگر اینکه صریحاً از طریق بررسی های قبل از پرواز CORS مجاز باشند.
به همین دلیل است که معمولاً حملات CSRF شامل می شود دریافت یا ارسال کنید درخواستها به جای درخواست‌های PUT یا DELETE، که به بررسیهای قبل از پرواز نیاز دارند که مهاجمان نمیتوانند بدون پیکربندی نادرست سمت سرور صریح از آن عبور کنند.
خطر پیکربندی نادرست هدرهای CORS
CORS (به اشتراک گذاری منابع متقابل) مکانیزمی است که کنترل می کند کدام دامنه های خارجی می توانند به منابع روی سرور دسترسی داشته باشند. با این حال، برخی از توسعه دهندگان به اشتباه تنظیم می کنند Access-Control-Allow-Origin سربرگ به *، که درخواست از هر مبدأ را مجاز می کند. این خطرناک است زیرا موثر است سیاست همان مبدأ را غیرفعال می کند، به مهاجمان اجازه می دهد تا درخواست های غیرمجاز متقاطع را انجام دهند که در غیر این صورت ممکن است مسدود شوند.
نمونه ای از پیکربندی خطرناک CORS
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Credentials: true
تنظیم Access-Control-Allow-Credentials: true در حالی که اجازه هرگونه منشأ (*) یک خطر امنیتی بزرگ است زیرا به هر وب سایتی اجازه می دهد تا درخواست های تأیید شده را با استفاده از اعتبار قربانی ارسال کند. یک رویکرد امن این است که فقط دامنه های قابل اعتماد مجاز است:
Access-Control-Allow-Origin:
محافظت در برابر حملات CSRF
برای جلوگیری از CSRF، توسعه دهندگان باید اقدامات امنیتی زیر را اجرا کنند:
- از توکن های CSRF استفاده کنید – توکن‌های CSRF مقادیر تصادفی هستند که برای هر جلسه کاربر تولید می‌شوند و باید در درخواست‌هایی که دادههای سمت سرور را تغییر می‌دهند گنجانده شوند.
-
به کوکی های SameSite نیاز دارید – تنظیم کوکی ها با
SameSite=strictیاSameSite=laxویژگی مانع از ارسال آنها در درخواست های متقاطع می شود. -
از CORS به طور ایمن استفاده کنید – مجوزهای CORS را به دامنه های قابل اعتماد محدود کنید و هرگز تنظیم نکنید
Access-Control-Allow-Origin: *برای منابع تایید شده - اجرای احراز هویت کاربر برای اقدامات حساس – قبل از انجام اقدامات مهم مانند تراکنش ها یا تغییرات حساب، به احراز هویت مجدد یا احراز هویت چند عاملی (MFA) نیاز داشته باشید.
نتیجه گیری
به دلیل اینکه مرورگرها چگونه احراز هویت جلسه را مدیریت می کنند، CSRF یک حمله رایج در برنامه های کاربردی وب است. با سوء استفاده از اعتماد کاربر و استفاده از مهندسی اجتماعی، مهاجمان می توانند اقدامات غیرمجاز را از طرف قربانیان انجام دهند. با این حال، با کنترلهای امنیتی مناسب مانند توکن‌های CSRF، کوکیهای SameSite و پیکربندیهای ایمن CORS، توسعهدهندگان میتوانند به طور موثر این خطر را کاهش دهند.
همانطور که تهدیدات امنیتی وب در حال تکامل هستند، حفظ درک قوی از آسیب پذیری هایی مانند CSRF و اجرای بهترین شیوه ها برای محافظت از کاربران و برنامه ها بسیار مهم است.
بیایید وصل شویم!
📧 یک پست را از دست ندهید! مشترک شدن در خبرنامه من!
📖 آخرین کتاب OAuth2 من را بررسی کنید!
➡️ لینکدین
🚩 پست اصلی
