حمله جعل درخواست (CSRF) چیست و چطور در مقابل آن ایمن بمانیم؟

آیا تا به حال با لینک و فایل‌های عجیب و مشکوک روبه‌رو شده‌اید؟ احتمالا تا کنون شنیده‌اید که نباید بر چنین لینک‌هایی کلیک کرد یا نباید هر فایلی را دانلود کرد! یکی از دلایل آن آسیب پذیری یا باگ CSRF است. CSRF درواقع مخفف Cross site request forgery است که یکی از خطرناک‌ترین حملات سمت سرور است. این آسیب پذیری که با نام‌های دیگری نیز شناخته می‌شود، از حملات هدفمند و هوشمندانه به‌ سایت‌های دارای سیستم احراز هویت است که حتی سرویس‌های معروفی مانند YouTube نیز دچار آن بوده‌اند. در ادامه به معرفی و بررسی دقیق‌تر این آسیب پذیری و نحوه جلوگیری از آن می‌پردازیم.

آسیب پذیری CSRF چیست؟

گفتیم اصطلاح CSRF مخفف Cross Site Request forgery است که معنی لغوی آن حملات جعل درخواست است. این باگ یا آسیب پذیری با نام‌های sea surfing، (موج سواری) XSRF، (جلسه رانی)session Riding، (پیوند خصمانه) Hostile linking و (حمله تک کلیکی) one click attack نیز شناخته می‌شود. همانطور که گفتیم این آسیب پذیری سمت سرور یا server side است و بیشتر وب‌سایت‌های دارای سیستم احراز هویت مانند سرویس‌های بانکی، آنلاین شاپ‌ها، مراکز آموزشی و… دچار این حمله می‌شوند.

در این نوع حمله مهاجم با استفاده از آسیب پذیری CSRF کاربران را به نوعی وادار به انجام اقداماتی می‌کند که مهاجم می‌خواهد درواقع مهاجم با کمک کاربر قربانی، درخواست خود را به سمت سرور می‌فرستد. این نوع آسیب پذیری به مهاجم اجازه می‌دهد تا حدودی سیاست‌های SOP (Same origin policy) یا سیاست‌های مبدا مشترک را دور بزند.

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

در حملات CSRF مهاجم می‌تواند کاربر قربانی را وادار به انجام اقدامات ناخواسته کند و بر اساس سطح عملکرد برنامه و سطح دسترسی کاربر قربانی، می‌تواند آسیب‌های متفاوتی وارد کند که چند مورد را شرح خواهیم داد:

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

• در وب‌سایت‌هایی که کاربران امکان نشر محتوا دارند، مهاجم می‌تواند محتوای مورد نظر خود را با حساب قربانی منتشر کند.

• در برنامه‌های بانکی دارای این آسیب پذیری مهاجم می‌تواند وجه را با حساب و هویت کاربر قربانی انتقال دهد.

• بسته به سطح کاربر قربانی، مهاجم می‌تواند اقدامات متفاوت انجام دهد مثلا در مورد کابر سطح بالا می‌تواند اطلاعات برنامه را نیز تغییر دهد.

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

این حمله اولین بار در تاریخ ۴ اکتبر سال ۲۰۰۵ توسط یک بدافزار کرمی (worm) به نام Samy در شبکه اجتماعی MySpace اتفاق افتاد. در این حمله در عرض ۲۰ ساعت تصویر پروفایل بیش از یک میلیون کاربر این شبکه اجتماعی به متن (But most of all, samy is my hero) به معنی اما سامی بیشتر از همه قهرمان من است، تغییر پیدا کرد و افراد تحت حمله به صورت ناخواسته درخواست دوستی با اکانتی به نام samy را فرستادند. جالب است بدانید سامی درواقع سامی کامکار، یک کارشناس هک کامپیوتر و کارآفرین ایرانی نسب متولدآمریکا در سال ۱۳۶۴ است.

آسیب پذیری CSRF چگونه کار می‌کند؟

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

اقدام مطلوب برای مهاجم

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

اداره نشست بر مبنای کوکی‌ها (cookies)

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

امکان پیش‌بینی پارامتر‌های درخواست

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

انواع آسیب پذیری CSRF کدام‌اند؟

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

سناریو متد GET

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

مثال: در یک برنامه بانکی مهاجم می‌خواهد پنج ملیون تومن به شماره کارت فرضی ۶۰۳۷ واریز کند و پس از تعیین مبلغ و شماره کارت گیرنده روی گزینه انتقال کلیک می‌کند و درخواستش در حال ارسال است. در متد GET کد URL یک الگو مشخص دارد. مثلا شماره کارت با الگو acctد و مبلغ با پارامتر amount نمایش داده می‌شود و همچنین احراز هویت بر اساس کوکی‌ها انجام می‌شود. بنابراین اگر مهاجم به‌جای شماره کارت مقصد، شماره کارت مورد نظر خود را وارد کند و قربانی وارد صفحه مورد نظر شود، مبلغ به حساب دلخواه مهاجم واریز خواهد شد. فرض کنید URL مانند مثال زیر است:

http://bank.com/transfer.do?acct=6037&amount=3000000

حالا مهاجم می‌تواند با تکنیک‌های خود و لینک پیوندی، لینک ساختگی خود را برای قربانی ارسال می‌کند و پس از کلیک قربانی بر روی لینک، درخواست را با روش GET و کمک کوکی ب ای بانک ارسال می‌کند و مبلغ به حساب مورد نظر مهاجم واریز می‌شود. نمونه آن مانند لینک زیر است:

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

البته این روش بیشتر برای مواردی به کار می‌رود که مهاجم فقط می‌تواند یک متن و لینک را ارسال کند مانند پیامک و بخش نظرات وب‌سایت‌ها و…. در برخی موارد مهاجم امکان استفاده از تگ‌های جعلی مانند <Img> را دارد. در این موارد با باز کردن صفحه‌ی این کد، مرورگر قربانی به صورت خودکار درخواست مهاجم را برای باز کردن تصویر به وب‌سایت بانک ارسال می کند. یپس درخواست با روش GET ارسال می شود و کاربر قربانی سایت بانک و تصویر را مشاهده‌ نمی‌کند. در این حالت طول و عرض تصویر روی صفر تنظیم شده است. لینک آن موردی مانند لینک زیر است:

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

مثال واقعی حمله CSRF در متد GET

در 17 ژانویه 2016‌‌، در سایت HackerOne ( پلتفرم‌ معروف باگ بانتی)‌‌، گزارشی توسط یک کارشناس تست نفوذ از WeSecureApp مبنی بر وجود آسیب پذیری یکی از دامنه‌های مرتبط با Twitter با نام shopify به آدرس twittercommerce.shopifyapps.com ثبت شد. این دامنه به منظور ارتباط کاربران صاحب فروشگاه ایجاد شده بود و قابلیت خارج کردن حساب توییتر متصل به آن پلتفرم را داشت. کارشناس متوجه شد که خروج از حساب با متد get و URL زیر امکان پذیر است

https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect/

این مورد نوعی آسیب پذیری CSRFو است و او از کد زیر برای اثبات مفهوم (poc) استفاده کرد و در نهایت ۵۰۰ دلار به عنوان جایزه دریافت کرد.

<html>
<body>
<img src=”https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect">
</body>
</html>

سناریو متد POST

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

وب‌سایتی با نام فرضی com.siteر را در نظر بگیرید که قابلیت تغییر ایمیل را برای کاربران فراهم کرده است. هنگام درخواست تغییر ایمیل، درخواست با الگوی خاص Http ارسال می‌شود که این اقدام همه موارد مورد نیاز برای استفاده از آسیب پذیری CSRF، مانند استفاده از کوکی‌ها برای شناسایی کاربر، اقدام تغییر ایمیل که مناسب این نوع حملات است و قابلیت تشخیص پارامتر‌ها در لینک را دارد. به عنوان مثال کد زیر:

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

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

<form action=https://site.com/email/change method=”POST”> <input type=”hidden” name=”email” value=hacker@.com /> </form> <script> document.forms[0].submit  </script>

مثال واقعی حمله CSRF در متد POST

در تاریخ ۹ آگوست سال ۲۰۱۵ یک آسیب پذیری csrf مربوط به وب‌سایت instacart گزارش شد. این پلتفرم که یک فروشگاه مواد غذایی با امکان خرید آنلاین و پست محصول است که ارسال کنندگان محصول منطقه مشخص دارند و سفارش‌های مربوط به هر منطقه به آن‌ها واگذار می‌شود. کارشناس متوجه شد که محصول در پنل ارسال کنندگان با لینک زیر به حملات CSRF آسیب پذیر است که با مهاجم با دستور خاص html می‌توانست پس از باز شدن لینک منطقه فعالیت ارسال کننده را متوجه شود و بدون آنکه سایت آسیب‌پذیر پی ببرد، آن را تغییر دهد.

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

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

جلوگیری از حملات CSRF

روش‌های زیادی برای جلوگیری از حملات CSRF استفاده می‌شود که دو مورد از رایج‌ترین آن‌ها را بررسی خواهیم کرد.

توکن‌های CSRF

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

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

بستگی اعتبارسنجی توکن CSRF به متد درخواست

برخی مواقع در استفاده از متد POST اعتبارسنجی به درستی انجام می‌شود اما در متد GET اعتبارسنجی درست صورت نمی‌گیرد؛ در این مواقع مهاجم برای دور زدن اعتبارسنجی از متد GET استفاده می‌کند تا حمله خود را انجام دهد.

بستگی اعتبارسنجی توکن CSRF به وجود توکن

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

توکن CSRF متعلق به نشست همان کاربر نیست

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

قرار گرفتن توکن CSRF در کوکی غیر از کوکی نشست

گاهی نیز وب‌سایت توکن را در کوکی نشست قرار می‌دهد ولی نه الزاما کوکی که برای ردیابی کاربر استفاده می‌شود! این اتفاق زمانی امکان پذیر است که وب‌سایت از دو فریم‌ورک برای حفاظت در برابر CSRF و اداره نشست‌ها استفاده می‌کند.

توکن CSRF فقط در یک کوکی کپی می‌شود

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

استفاده از Referer برای جلوگیری از CSRF

علاوه بر استفاده از توکن، برخی از وب‌سایت‌ها برای دفاع از خود در برابر حملات CSRF، از هدر Referer در درخواست‌های HTTP استفاده می‌کنند. این کار معمولا با هدف اطمینان از ارسال درخواست‌ها از دامنه خودشان انجام می‌شود که دور زدن آن ساده است. دلایل فراوانی وجود دارد که این روش امنیت کافی را تامین نمی‌کند:

بستگی اعتبارسنجی Referer به وجود هدر آن

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

قابلیت دور زدن اعتبارسنجی Referer!

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

ابزار‌های کشف آسیب پذیری‌ CSRF کدام‌اند؟

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

• Postmab
• Burp suite
• Fiddler

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