آسیب پذیری CSRF چیست + توضیحات کامل / 2022

csrf چیست واژه CSRF مختصرCross Site Request Forgery می‌باشد؛ همچنین آن را با نام‌های XSRF، Sea Surf(موج سواری)‌‌، Session Riding(جلسه رانی)‌‌، Hostile Linking(پیوند خصمانه) وOne-click Attack(حمله یک کلیکی) نیز می‌شناسند. این حمله از جمله حملات خطرناک درServer-side یا سمت سرور، هدفمندترین حمله به وب سایت هایی است که دارای سیستم های احراز هویت کاربران هستند، مانند خدمات بانکی، مراکز آموزشی، فروشگاه ها و غیره.

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

تاثیرات حمله CSRF یا جعل درخواست

csrf چیست این حمله بر اساس عملکرد برنامه (Web Application) می تواند آسیب های خاص خود را داشته باشد. شما نمونه هایی از این حمله را بیان خواهید کرد.

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

کشف آسیب‌ پذیری CSRF

برای اینکه بگوییم یک برنامه دارای آسیب‌پذیری CSRF است، باید سه شرط کلیدی زیر را داشته باشد:

وجود یک عملکرد(action)

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

احراز هویت بر اساس کوکی

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

عدم وجود پارامتر‌های غیر قابل حدس

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

ابزار‌های کشف آسیب‌پذیری CSRF

برای شناسایی این آسیب‌پذیری، به ابزاری نیاز داریم که به عنوان یک پروکسی داخلی برای درخواست‌های آنالیز (Request) و پاسخ‌ها (Responses) عمل کند. مانند:.

1. Burp Suite
2. Fiddler
3. Postman

از مزایای این ابزارها می توان به تغییر درخواست و همچنین مشاهده پاسخ ها (Responses) به صورت خام (RAW) اشاره کرد که به ما کمک می کند آسیب پذیری CSRF را آزمایش کنیم.

مطالب مرتبط

انواع آسیب‌پذیری CSRF چیست

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

CSRF را می توان با توجه به نوع اجرا به ۳ قسمت تقسیم کرد:

1. سناریو متد GET
2. سناریو متد POST
3. سناریو متد‌های دیگر

سناریو متد GET

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

در یک برنامه بانکی، نفوذگر قصد دارد ۱۰۰ دلار به شخصی با شماره کارت فرضی ۱۲۳۴ واریز کند و پس از تعیین مبلغ و شماره کارت بانکی گیرنده، روی دکمه “انتقال” کلیک کرده و مشاهده می کند که درخواستش در حال ارسال است. در GET و محتوای URL یک رشته مانند زیر است:

http://bank.com/transfer.do?acct=1234&amount=100

1. وجود عملکرد حساس در GET
2. احراز هویت بر اساس کوکی
3. پارامتر‌های قابل تشخیص

او متوجه می شود که شماره کارت گیرنده با پارامتر acct و مقدار مورد نظر او با پارامتر amount در url تعیین می شود و احراز هویت او از طریق یک کوکی انجام می شود.

بنابراین نتیجه می گیریم که اگر در پارامتر acct به جای شماره کارت بانک مقصد، شماره کارت مورد نظر خود را بنویسد و در پارامتر amount، شخصی که این درخواست را ارسال کرده است، در صورت ورود به سایت بانک مربوطه، ۱۰۰ دلار پرداخت خواهد کرد. به او حساب خود را واریز خواهد کرد.

در اینجا نفوذگر می تواند از روش ها و تکنیک های مهندسی اجتماعی برای هدایت قربانی به ارسال این درخواست جعلی استفاده کند، به عنوان مثال می تواند از تکنیک هایی مانند موارد زیر استفاده کند:

در اینجا نفوذگر می تواند از روش ها و تکنیک های مهندسی اجتماعی برای هدایت قربانی به ارسال این درخواست جعلی استفاده کند، به عنوان مثال می تواند از تکنیک هایی مانند موارد زیر استفاده کند:

• ارسال یک ایمیل به همراه یک فایل html .
• قرار دادن یک URL یا اسکریپت در صفحاتی که ممکن است قربانی حین عملیات بانکی آن را ببیند.

نفوذگر از کد پیوندی استفاده می کند که کاربر را به مسیری مانند کد html زیر در سایت خود یا هر سایتی که به هر دلیلی می تواند از این کد استفاده کند هدایت می کند و با یک متن وسوسه انگیز سعی می کند قربانی را متقاعد کند که روی متن کلیک کند. به نظر می رسد “Click here”:.

<a href="http://bank.com/transfer.do?acct=4321&amount=100"> Click here!</a>

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

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

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

در صورت امکان، از کد html نفوذگر می‌تواند از تگ <img> یا <form> برای ارسال درخواست جعلی استفاده کنید:

<img src=”http://bank.com/transfer.do?acct=4321&amount=1000″ width=”۰″ height=”۰″ border=”۰″>

اگر قربانی صفحه ای حاوی این کد را باز کند، مرورگر قربانی به طور خودکار درخواست نفوذگر را برای باز کردن تصویر به سایت بانک ارسال می کند. در اینجا درخواست با روش GET ارسال می شود و پول منتقل می شود اما قربانی اثری از سایت بانک و تصویر اجرا شده نمی بیند. از آنجایی که ویژگی های برچسب این تصویر ساخته شده است، طول و عرض تصویر روی “۰” تنظیم می شود که باعث می شود تصویر نفوذگر نامرئی شود.

توجه داشته باشید که اگر درخواست از روش POST استفاده می‌کرد، از تگ <img> ‌، تگ‌های پیوند یا ارسال آدرس پیوند برای ارسال درخواست استفاده نمی‌شد. بسیاری از چارچوب های مبتنی بر وب، مانند ruby on rails، Django و دیگران، به طور خودکار برخی از راه حل های پیشگیری CSRF را فقط برای درخواست های POST اعمال می کنند. تاکنون با مشکلات استفاده از روش GET برای ارسال این گونه درخواست ها آشنا شده ایم. در این مقاله با راهکارهای امنیتی برنامه در برابر CSRF بیشتر آشنا می شویم.

سناریو متد POST

تا اینجا یاد گرفتیم که روش GET نباید برای انجام عملکردهای مهم و موثر در سمت سرور استفاده شود. اما با فرض استفاده از روش POST برای چنین درخواست هایی، آیا راهی برای سوء استفاده از آسیب پذیری CSRf وجود نخواهد داشت؟ در ادامه به سناریوی بهره برداری از باگ CSRF با متد POST می پردازیم.

فرض کنید وب سایتی به نام “example.com” قابلیت تغییر ایمیل برای هر کاربر را در پنل کاربری خود دارد و زمانی که کاربر ایمیل را تغییر می دهد، درخواست http زیر ارسال می شود:

POST /email/change HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE [email protected]

که تمام شرایط وجود باگ CSRF را در بر می‌گیرد:

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

بنابراین نفوذگر می تواند این درخواست را تغییر دهد تا ایمیل کاربر را به ایمیل مورد نظر تغییر دهد. برای این کار در پارامتر ایمیل‌ آدرس ایمیل خود را وارد کنید.

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

<form action="https://example.com/email/change" method="POST"> <input type="hidden" name="email" value="[email protected]"/> </form> <script> document.forms[0].submit  </script>

پس از طی مراحل فوق، در صورتی که کاربر قربانی وارد صفحه سایت نفوذگر شود، مراحل زیر انجام می شود:

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

توجه داشته باشید که روش‌های روش POST مانند استفاده از دستور form یا دستور XHR (که در زیر به آن پرداخته می‌شود) را می‌توان در سناریوی متد GET نیز استفاده کرد، اما روش‌های توصیف‌شده در سناریوی GET را نمی‌توان در حملات با سناریوی POST استفاده کرد.

سناریو متد‌های دیگر

باید بپذیریم که آسیب‌پذیری‌های CSRF با این سناریو به اندازه روش‌های GET و POST رخ نمی‌دهند. اما دانستن این موضوع خالی از لطف نیست و ممکن است برای پیپت کردن برخی فیلترها نیز استفاده شود.

فرض کنید یک برنامه وب مبتنی بر وب از روش PUT برای انتقال ۱۰۰ دلار به درخواست کاربر به روش زیر استفاده می کند:

PUT http://bank.com/transfer.do HTTP/1.1 { "acct":"user", "amount":100 }

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

<script>function put() {    var x = new XMLHttpRequest();    x.open("PUT","http://bank.com/transfer.do",true);    x.setRequestHeader("Content-Type", "application/json");    x.send(JSON.stringify({"acct":"attacker", "amount":100})); }</script> <body onload="put()">

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

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

XHR یا XmlHttpRequest چیست؟

XHR یک API پرکاربرد در فناوری برنامه وب Ajax است که به عنوان یک Object در برنامه استفاده می شود. این API برای ارسال و دریافت اطلاعات بین مرورگر و سرور استفاده می شود. به طوری که بدون رفرش صفحه اطلاعات را ارسال و دریافت می کند. به عنوان مثال پس از نوشتن نام کاربری در فیلد مربوطه، حضور یا عدم حضور کاربری که نام آن با تیک یا ضربدر در کنار فیلد نوشته شده مشخص می شود. نمونه های دیگری از این API را می توان در برنامه های وب پویا نیز یافت.

این حمله چگونه کشف شد؟

یک مثال واقعی از این نوع حمله می تواند اولین باری باشد که این نوع حمله مشاهده می شود. این حمله برای اولین بار در ۴ اکتبر ۲۰۰۵ توسط یک بدافزار کرمی (worm) به نام Samy در شبکه اجتماعی MySpace مشاهده شد. نتیجه این حمله این بود که در عرض ۲۰ ساعت عکس پروفایل بیش از ۱ میلیون کاربر این شبکه اجتماعی به متن مقابل تغییر پیدا کرد .

but most of all, samy is my hero

که یعنی “اما بیش تر از همه‌‌، سامی ‌قهرمان من است”

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

سامی‌کامکار متولد ۱۹ آذر ۱۳۶۴ یک محقق امنیتی، کارشناس هک کامپیوتر و کارآفرین است. او در خانواده ای ایرانی الاصل در آمریکا به دنیا آمد. اما با وجود اینکه کامکار خود را ایرانی می داند، این موضوع چندان در رسانه های خارجی مطرح نمی شود.

بایپس‌های حمله CSRF

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

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