حمله CSRF که به معنی جعل درخواست از سایت های دیگر است. این حمله کاربر نهایی را مجبور می کند که عملی را به صورت ناخواسته روی یک Web Application که قبلا کاربر فرآیند Authentication را روی آن اجرا کرده است، انجام دهد. هدف حمله CSRF به طور مشخص، تغییر حالت است و نه دزدیدن اطلاعات، زیرا حمله کننده هیچ راهی برای دیدن پاسخ جعل شده نخواهد داشت. با کمی کمک گرفتن از مهندسی اجتماعی مانند ارسال یک لینک از طریق ایمیل یا چت، یک حمله کننده می تواند با فریب کاربران یک وب اپلیکیشن، درخواست های حمله کننده را اجرا کند. اگر قربانی یک کاربر معمولی باشد، یک حمله موفق CSRF می تواند کاربر را مجبور کند که یک درخواست تغییر حالت (State Changing Request) مانند انتقال وجه، تغییر آدرس ایمیل یا… انجام دهد. اگر قربانی مدیر یک اکانت باشد، حمله CSRF می تواند تمام نرم افزار وب را به خطر بیاندازد. به حملات CSRF ، حملات «XSRF» نیز می گویند.
اقدامات پیشگیرانه ای که کار نمی کنند
ترفندهای امنیتی و راه های زیادی برای جلوگیری از حمله CSRF معرفی شده است. ما در اینجا به راه هایی اشاره می کنیم که شما باید از آن ها اجتناب کنید!
۱- استفاده از کوکی محرمانه
به یاد داشته باشید حتی کوکی های محرمانه در هر Request ارسال می شوند. همچنین همه توکن های احراز هویت بدون در نظر گرفتن اینکه که کاربر نهایی در ارسال درخواست فریب خورده است یا خیر ارسال خواهند شد. علاوه بر این، شناسه سشن (Session) به صورت ساده ای توسط سرور اپلیکیشن به منظور مرتبط کردن یک درخواست با یک شی سشن استفاده می شود. شناسه سشن در نظر نمی گیرد که آیا کاربر نهایی قصد ارسال Request را داشته است یا خیر.
۲- محدود کردن دریافت Request ها به نوع POST
یک نرم افزار می تواند طوری توسعه پیدا کند که فقط Request های از نوع POST را برای اجرای منطق و Business Logic نرم افزار قبول کند. تصور غلط این است که چون حمله کننده نمی تواند یک لینک مخرب بسازد پس یک حمله CSRF قابل اجرا نیست. ولی این منطق غلط است. روش های زیادی وجود دارد که یک حمله کننده می تواند قربانی را مجبور به ارسال یک درخواست از نوع POST جعل شده کند. به طور مثال ممکن است یک فرم ساده در صفحه حمله کننده طراحی شده باشد که دارای ورودی های نوع Hidden باشد. این فرم می تواند توسط جاوا اسکریپت به طور اتوماتیک ارسال شود در حالی که قربانی فکر می کند که فرم هیچ کار خاصی انجام نمی دهد.
۳- فرآیند های چند مرحله ای
فرآیند یا Transaction های چند مرحله ای برای جلوگیری از CSRF کافی نیست. مهاجم می تواند هر مرحله را پیش بینی، استنباط و آن را تکمیل کند تا فرآیند حمله تکمیل شود.
۴- URL Rewriting
این ممکن است که یک راه حل مفید برای جلوگیری از حملات CSRF باشد؛ زیرا حمله کننده نمی تواند Session ID قربانی را حدس بزند. اگرچه Session ID کاربر در URL نمایش داده می شود ولی ما توصیه نمی کنیم که یک نقص امنیتی را حل کنیم اما در کنار آن یک نقص امنیتی دیگر به وجود آوریم. (بخواهیم ابرو را درست کنیم و بزنیم چشم را کور کنیم!)
۵- HTTPS
HTTPS به تنهایی فعالیتی برای جلوگیری از حمله CSRF انجام نمی دهد اما پیش‌نیاز برخی از روش های جلوگیری از این حمله است.
مثال:
این حمله چطور کار می کند؟
روش های زیادی جهت مجبور کار کاربر نهایی به لود کردن اطلاعات از وب یا ارسال و Submit فرم به سمت وب وجود دارد. به منظور اجرای یک حمله، ابتدا باید بدانیم که چگونه یک درخواست Valid برای قربانی خود بسازیم تا آن را اجرا کند. به این مثال توجه کنید: آلیس می خواهد توسط Bank.com که دارای وب اپلیکشنی است که نسبت به حمله CSRF آسیب پذیر است، ۱۰۰ دلار به باب منتقل کند. ماریا که یک Attacker است می خواهد آلیس را مجبور کند که به جای اینکه پول را به باب منتقل کند به حساب او ریخته شود. حمله شامل مراحل زیر است:
۱- ساختن یک URL یا اسکریپت
۲- فریب دادن آلیس به اجرای عملیات توسط مهندسی اجتماعی
سناریوی GET
اگر اپلیکیشن طوری طراحی شده باشد که از درخواست GET برای جابه‌جایی پارامترها و اجرای عملیات استفاده کند، عملیات انتقال وجه مثل یک Request پایین انجام می شود:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
ماریا می خواهد از این وب اپلیکیشن آسیب پذیر بهره برداری کند و آلیس را قربانی خود قرار دهد. ماریا ابتدا برای انتقال پول از حساب آلیس به حساب خودش لینک مخرب زیر را می سازد. او URL اصلی را می گیرد و پارامتر های آن را با پارمتر های مناسب جایگزین می کند:
http://bank.com/transfer.do?acct=MARIA&amount=100000
جنبه مهندسی اجتماعی حمله، آلیس را مجبور می کند این URL را زمانی که به صفحه بانک خود وصل می شود کلیک کند و حمله تکمیل می شود.
راه های کنترل حمله CSRF
۱- اضافه کردن یک nonce به هر Request، همه فرم ها و سشن استاندارد. بسیاری از Framework ها مانند Drupal این نوع محافظت را صورت Built-in در همه فرم ها دارند یا شروع کرده اند آن را به فریمورک خود اضافه کنند و نیازی نیست که برنامه نویس به صورت دستی این موارد را رعایت کند.
۲- اضافه کردن یک Hash به تمامی فرم ها
۳- چک کردن referrer header در request ارسالی کاربر، می تواند از CSRF جلوگیری کند. مطمئن شوید که درخواست http از سایت اصلی می آید و request از سایت های دیگر اجرا نمی شود. به دلیل محدودیت های حافظه، چک های referrer header در سخت افزار شبکه جاسازی شده و به صورت Built-in بسیار رایج است.
۴- با اینکه SCRF اساساً مشکل وب اپلیکیشن ها است و نه کاربران اما کاربران می توانند با پاک کردن کوکی های مرورگر خود (از طریق تنظیمات مرورگر) در پایان هر سشن یا با خروج از حساب کاربری خود در سایت های ضعیف قبل از بازدید از یک سایت دیگر، به حفاظت از حساب های کاربری خود کمک کنند.
منبع: owasp