حمله CSRF چیست؟ و راهکارهای مقابله با آن

زمان مطالعه: ۴ دقیقه

Cross Site Request Forgery یا CSRF زمانی رخ می دهد که یک سایت یا برنامه مخرب باعث می شود مرورگر کاربر هنگام تأیید اعتبار کاربر، اقدام ناخواسته ای را در یک سایت معتبر انجام دهد. هرگونه اقدام مخرب محدود به قابلیت وب سایتی است که کاربر به آن احراز هویت می شود.

به عنوان مثال، کاربر هنگام بررسی ایمیل خود به پورتال بانکی آنلاین خود وارد شود. در آنجا، او ممکن است بر روی پیوند در یک ایمیل فیشینگ کلیک کند (احتمالاً توسط سایت کوتاه کننده پیوند مبهم است) که شامل درخواست از بانک برای انتقال پول به حسابی است که در اختیار هکر است.

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

درخواست ها و کوکی های HTTP چیست؟

درخواست HTTP GET

این درخواستی است که برای درخواست داده از سرور وب (به عنوان مثال تایپ کردن در URL (درخواست وب سایت) که منجر به بارگیری آن می شود) استفاده می شود.

درخواست HTTP Post

این درخواستی است که برای ارسال داده به سرور وب (به عنوان مثال ارسال فرم وب) استفاده می شود.

برخی از درخواست های GET و POST بدون تعامل کاربر (مانند پیشنهادات جستجو یا دانلود محتوای تصویر با ویژگی img src) به صورت خودکار فعال می شوند.

کوکی های مربوط به جلسه (Session Cookies)

کوکی های جلسه روشی است که HTTP وضعیت را کنترل می کند. وب سایت ها برای شناسایی کاربران و حفظ جلسه خود از کوکی های جلسه (حاوی شناسه منحصر به فرد) استفاده می کنند.

پس از تنظیم، مرورگر کاربر برای شناسایی کاربر به سایت، کوکی را با هر درخواست از سرور ارسال می کند.

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

یک مثال عملی از سوء استفاده از کوکی ها را در دوره CEH می توانید مشاهده کنید.

Cross Site Request Forgery چگونه کار می کند؟

برای اینکه یک مهاجم حمله CSRF را انجام دهد، موارد مختلفی باید درست باشد:

عملی در برنامه وجود دارد که یک مهاجم می خواهد انجام دهد – مانند تغییر رمز عبور، انتقال وجه و غیره.

پارامترهای درخواست غیرقابل پیش بینی وجود ندارد – مهاجم می تواند تمام پارامترهایی را که برنامه انتظار دارد از این نوع درخواست ها حدس بزند (یا آنها را می داند).

این اقدام را می توان با درخواست (های) HTTP انجام داد و برای بررسی تأیید درخواست از طرف کاربر، فقط از کوکی ها استفاده می شود.

CSRF می تواند بر برنامه های تحت وب که از کوکی ها برای تأیید اعتبار مرورگر یا گواهینامه های سمت مشتری برای تأیید اعتبار کاربران استفاده می کنند، تأثیر بگذارد. اساساً می تواند در هر موردی اتفاق بیفتد که برنامه به طور خودکار اعتبار یا هویت کاربران را به یک درخواست ضمیمه کند.

حمله CSRF می تواند از یک درخواست GET یا یک درخواست POST استفاده کند (اگرچه درخواست POST پیچیده تر است و بنابراین غیر معمول است).

هرکدام باید شروع کنند به این که مهاجمی قربانی را برای بارگذاری یا ارسال اطلاعات به یک برنامه وب فریب دهد. این می تواند به روش های مختلفی اتفاق بیفتد – برای مثال از طریق پیوند فیشینگ.

متناوباً ، همانند XSS (برنامه نویسی بین سایت)، CSRF می تواند یک آسیب پذیری ذخیره شده باشد. CSRF ذخیره شده زمانی اتفاق می افتد که یک مهاجم حمله را در فیلدی ذخیره کند که HTML مانند برچسب IMG یا IFRAME را قبول می کند. این بدان معنی است که هرکسی صفحه را مشاهده کند می تواند تحت تأثیر قرار گیرد. سواستفاده می تواند به عنوان یک پیوند معمولی پنهان شود و یا در برچسب تصویر پنهان شود.

به عنوان مثال، به عنوان یک لینک معمولی در یک صفحه وب:

<a href=“malicious link”>Unsubscribe here</a>

یا ، به عنوان برچسب تصویر:

<img src=“malicious link” width=“۰” height=“۰” border=“۰”>

نمونه ای از CSRF

تصور کنید که بانک شما (bank.com) نقل و انتقالات را با استفاده از درخواست های GET پردازش می کند که شامل چندین پارامتر است (هویت گیرنده انتقال و میزان انتقال شما).

به عنوان مثال، اگر کاربر بخواهد به شخصی ۱۰ تومان بفرستد، ممکن است درخواست به این شکل باشد:

http://bank.com/transfer?recipient=Keyvan&amount=10

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

 

اکنون، یک مهاجم ممکن است کاربر را متقاعد کند تا روی پیوندی که به این شکل است کلیک کند (اما توسط کوتاه کننده URL کوتاه شده است یا به طور هوشمندانه پیوند داده شده است):

http://bank.com/transfer?recipient=Hacker&amount=100000

از آنجا که کاربر از قبل وارد سیستم شده است، مرورگر وی کوکی خود را با درخواست ارسال می کند – بنابراین بانک وی معتقد است که وی درخواست انتقال را دارد و درخواست انجام می شود.

چگونه جلوی حملات CSRF را بگیریم؟

چارچوب های خود را با دقت انتخاب کنید

از فریم ورکهایی استفاده کنید که برای محافظت در برابر CSRF ساخته شده است، مانند NET. پیکربندی صحیح کلید است. اگر چارچوبی که استفاده می کنید از محافظت برخوردار نیست، می توانید با Anti-CSRF Tokens محافظت کنید.

از توکن های ضد CSRF استفاده کنید

Tokens (همچنین به عنوان الگوهای رمز synchronizer شناخته می شود) یک محافظت سمت سرور است که در آن سرور یک توکن منحصر به فرد ایجاد شده به طور تصادفی در مرورگر کاربر ایجاد می کند و هر درخواست را بررسی می کند تا ببیند آیا مرورگر قبل از انجام درخواست آن را پس می فرستد یا خیر.

این رمز از طریق یک قسمت پنهان ارسال می شود و باید یک عدد تصادفی غیرقابل پیش بینی باشد که پس از مدت کوتاهی منقضی شود و امکان استفاده مجدد از آن وجود ندارد.

بسته به حساسیت صفحه، می توان از توکن های مختلفی برای هر درخواست یا به سادگی برای فرم های مختلف استفاده کرد. توکن ها باید به روشی ایمن مقایسه شوند (مانند مقایسه هش ها) و نباید آنها را با درخواست HTTP دریافت کرد زیرا بخشی از URL نیستند و نمی توانند از طریق سربرگ Referrer به بیرون درز کنند.