جعل درخواست سایت متقابل (CSRF)

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

CSRF چیست؟

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

آزمایشگاهها

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

تأثیر حمله CSRF چیست؟

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

CSRF چگونه کار می کند؟

برای اینکه یک حمله CSRF امکان پذیر باشد ، باید سه شرط کلیدی وجود داشته باشد:

• یک عمل مرتبطدر این برنامه اقدامی وجود دارد که مهاجم دلیلی برای القاء دارد. این ممکن است یک اقدام ممتاز (مانند اصلاح مجوزها برای سایر کاربران) یا هرگونه اقدام در مورد داده های خاص کاربر (مانند تغییر رمز عبور خود کاربر) باشد.
• رسیدگی به جلسه مبتنی بر کوکی. انجام این اقدام شامل صدور یک یا چند درخواست HTTP است و برنامه فقط به کوکی های جلسه متکی است تا کاربر را که درخواست ها را انجام داده است ، شناسایی کند. هیچ مکانیسم دیگری برای ردیابی جلسات یا اعتبارسنجی درخواست های کاربر وجود ندارد.
• هیچ پارامتر درخواست غیرقابل پیش بینی وجود ندارد. درخواستهایی که عمل را انجام می دهند شامل پارامترهایی نیستند که مقادیر آن مهاجم نمی تواند تعیین یا حدس بزند. به عنوان مثال ، در هنگام ایجاد کاربر برای تغییر رمز عبور خود ، اگر یک مهاجم نیاز به دانستن ارزش رمز عبور موجود داشته باشد ، عملکرد آسیب پذیر نیست.

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

پست/ایمیل/تغییر http/1. 1 میزبان: آسیب پذیر-website. com محتوا از نوع: برنامه/x-www-form-urlencoded طول محتوا: 30 کوکی: جلسه = yvthwsztyeqkapzeq5ghgtvlyxhfsafe ایمیل=wiener@normal-user. com

این شرایط مورد نیاز CSRF را برآورده می کند:

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

با استفاده از این شرایط ، مهاجم می تواند یک صفحه وب را که حاوی HTML زیر است ، بسازد:

اگر کاربر قربانی از صفحه وب مهاجم بازدید کند ، موارد زیر اتفاق می افتد:

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

توجه داشته باشید

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

نحوه ساخت حمله CSRF

ایجاد دستی HTML مورد نیاز برای سوء استفاده از CSRF می تواند دست و پا گیر باشد ، به ویژه در مواردی که درخواست مورد نظر حاوی تعداد زیادی از پارامترها باشد ، یا موارد دیگری در درخواست وجود دارد. ساده ترین راه برای ساخت سوء استفاده از CSRF استفاده از ژنراتور CSRF POC است که در Burp Suite Professional ساخته شده است:

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

آسیب پذیری CSRF Apprentice بدون دفاع

نحوه ارائه سوء استفاده از CSRF

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

توجه داشته باشید که برخی از سوء استفاده های ساده CSRF از روش GET استفاده می کنند و می توانند با یک URL در وب سایت آسیب پذیر کاملاً خود را به خود اختصاص دهند. در این شرایط ، مهاجم ممکن است نیازی به استفاده از یک سایت خارجی نداشته باشد و به طور مستقیم می تواند یک URL مخرب را در دامنه آسیب پذیر به قربانیان تغذیه کند. در مثال قبلی ، اگر درخواست تغییر آدرس ایمیل با روش GET انجام شود ، یک حمله خودمختار مانند این به نظر می رسد:

بیشتر بخوانید

دفاع مشترک در برابر CSRF

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

• Tokens CSRF - یک نشانه CSRF یک مقدار منحصر به فرد ، مخفی و غیرقابل پیش بینی است که توسط برنامه سمت سرور ایجاد می شود و با مشتری به اشتراک می گذارد. هنگام تلاش برای انجام یک عمل حساس ، مانند ارسال فرم ، مشتری باید توکن صحیح CSRF را در درخواست درج کند. این امر برای یک مهاجم برای یک درخواست معتبر به نمایندگی از قربانی بسیار دشوار است.
• Samesite Cookies - Samesite یک مکانیسم امنیتی مرورگر است که مشخص می کند چه موقع کوکی های یک وب سایت در درخواست های منشاء وب سایت های دیگر گنجانده شده اند. از آنجا که درخواست های انجام اقدامات حساس به طور معمول به یک کوکی جلسه تأیید شده نیاز دارد ، محدودیت های مناسب samesite ممکن است مانع از مهاجمین از تحریک این اقدامات متقابل شود. از سال 2021 ، Chrome به طور پیش فرض محدودیت های Samesite LAX را اعمال می کند. از آنجا که این استاندارد پیشنهادی است ، ما انتظار داریم که سایر مرورگرهای اصلی این رفتار را در آینده اتخاذ کنند.
• اعتبار سنجی مبتنی بر ارجاع - برخی از برنامه ها از هدر مراجعه کننده HTTP برای تلاش برای دفاع در برابر حملات CSRF استفاده می کنند ، به طور معمول با تأیید اینکه این درخواست از دامنه خود برنامه سرچشمه گرفته است. این به طور کلی از اعتبار سنجی توکن CSRF کمتر مؤثر است.

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

بیشتر بخوانید

• آزمایشگاه ها با اعتبار سنجی توکن CSRF
• آزمایشگاه ها محدودیت های کوکی Samesite را دور می زنند
• آزمایشگاه ها از دفاع CSRF مبتنی بر مراجعه کننده دور می شوند

برای جزئیات بیشتر در مورد نحوه اجرای صحیح این دفاع ها به منظور جلوگیری از برخی از این موارد در وب سایت های خود ، به نحوه جلوگیری از آسیب پذیری های CSRF مراجعه کنید

آیا می خواهید پیشرفت خود را پیگیری کنید و تجربه یادگیری شخصی تری داشته باشید؟(این رایگان است!) < Pan> اعتبارسنجی مبتنی بر ارجاع - برخی از برنامه ها از هدر مراجعه کننده HTTP برای تلاش برای دفاع در برابر حملات CSRF استفاده می کنند ، به طور معمول با تأیید اینکه این درخواست از دامنه خود برنامه سرچشمه گرفته است. این به طور کلی از اعتبار سنجی توکن CSRF کمتر مؤثر است.