در این مقاله می‌آموزیم که آسیب‌پذیری CSRF (کوتاه‌شده‌ی Cross-Site Request Forgery یا جعل درخواست میانوبگاهی) چیست؟ چند مورد از نمونه‌های رایج آسیب‌پذیری‌های CSRF را تشریح می‌کنیم، و نحوه جلوگیری از حملات CSRF را توضیح می‌دهیم.
جواب سوال خود را پیدا کنید:
- CSRF چیست؟
- دامنه تاثیرات یک حمله CSRF چیست؟
- حمله CSRF چگونه کار می‌کند؟
- نحوه ساختن اکسپلویت CSRF با Burp Suite
- نحوه انتقال اکسپلویت CSRF
- جلوگیری از حملات CSRF
- آسیب‌پذیری‌های رایج CSRF
- روش‌های دفاعی مبتنی‌بر Referer برای جلوگیری از CSRF
- تفاوت XSS و CSRF چیست؟
- آیا با توکن‌های CSRF می‌توان جلوی حملات XSS را گرفت؟
CSRF چیست؟
جعل درخواست فراوبگاهی یا CSRF (که به آن XSRF هم گفته می‌شود) یک آسیب‌پذیری وب است که مهاجم با استفاده از آن می‌تواند کاری کند که کاربران اقداماتی را انجام دهند که قصد انجام آن‌ها را نداشته‌اند. این آسیب‌پذیری به یک مهاجم اجازه می‌دهد، تا حدی سیاست SOP را دور بزنند. سیاست SOP (کوتاه‌شده Same Origin Policy) یا سیاست مبدأ مشترک، به منظور جلوگیری از سرقت داده با ارسال درخواست‌های Cross-Origin (میانوبگاهی) طراحی شده است.
دامنه تاثیرات یک حمله CSRF چیست؟
در یک حمله موفق CSRF، مهاجم باعث می‌شود کاربر قربانی، اقداماتی را به صورت ناخواسته انجام دهد. مثلا مهاجم ممکن است آدرس ایمیل حساب‌های قربانی را عوض کند، پسورد او را تغییر دهد، یا حتی مبلغی را از حساب او انتقال دهد. بسته به نوع اقدامات انجام‌شده، هکر ممکن است کنترل کامل حساب کاربر را به دست گیرد. اگر کاربر هدف یک حساب privileged در اپلیکیشن داشته باشد، مهاجم ممکن است بتواند کنترل تمام داده‌ها و کارکردهای اپلیکیشن را به دست گیرد.
حمله CSRF چگونه کار می‌کند؟
برای این که یک حمله CSRF امکان‌پذیر باشد، سه شرط کلیدی باید برآورده شوند:
- اقدام مطلوب مهاجم: اقدامی داخل اپلیکیشن که مهاجم دلیلی برای انجام آن داشته باشد. مثلا یک اقدام privileged (مثل تغییردادن مجوزهای کاربران دیگر) یا هرگونه اقدامی که روی داده‌های خاص یک کاربر انجام شود (مثل عوض‌کردن پسورد خود کاربر).
- اداره سشن بر مبنای کوکی‌ها: برای انجام اقدامات مختلف لازم است یک یا چند ریکوئست HTTP ارسال شوند، و برای این که امکان انجام حمله CSRF وجود داشته باشد، اپلیکیشن باید برای شناسایی کاربری که ریکوئست را ارسال کرده، فقط و فقط به کوکی‌های سشن (نشست) وابسته باشد، و هیچ مکانیزم دیگری برای ردیابی سشن‌ها یا اعتبارسنجی ریکوئست‌های کاربران وجود نداشته باشد.
- قابل پیش‌بینی‌بودن تمامی پارامترهای ریکوئست: ریکوئست‌هایی که اقدام مورد نظر را انجام می‌دهند، نباید حاوی هیچ‌گونه پارامتری باشند که مهاجم نتواند آن‌ها را تعیین کند یا حدس بزند. برای مثال، هنگامی که مهاجم سعی می‌کند کاربر را وادار به تعویض پسوردش کند، اگر لازم باشد که مهاجم مقدار پسورد فعلی را بداند، کاربر نسبت به تغییر ناخواسته پسورد آسیب‌پذیر نخواهد بود.
برای مثال، فرض کنید یک اپلیکیشن داخل خود قابلیتی دارد که به کاربر اجازه می‌دهد آدرس ایمیل حساب خود را تغییر دهد. وقتی یک کاربر این اقدام را انجام می‌دهد، یک ریکوئست HTTP شبیه ریکوئست زیر ارسال می‌کند:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
این ریکوئست شرایط لازم برای CSRF را دارد:
- اقدام تغییر آدرس ایمیل روی یکی از حساب‌های کاربر، اقدامی مطلوب مهاجم است. پس از این اقدام، مهاجم معمولا می‌تواند پسورد را ریست کند و کنترل کامل حساب کاربر را به دست بگیرد.
- اپلیکیشن برای نشان‌دادن این که کدام کاربر ریکوئست را ارسال کرده، از یک کوکی سشن استفاده می‌کند. هیچ توکن یا مکانیزم دیگری برای ردیابی سشن‌های کاربری وجود ندارد.
- مهاجم به راحتی می‌تواند مقادیر پارامترهای مورد نیاز در ریکوئست برای انجام اقدام مورد نظر را تعیین کند.
با برآورده‌شدن این شرایط، مهاجم می‌تواند یک صفحه وب حاوی کد HTML زیر بسازد:
اگر قربانی از صفحه مهاجم بازدید کند، اتفاقات زیر می‌افتد:
- صفحه‌های مهاجم باعث ارسال یک ریکوئست HTTP به وبسایت آسیب‌پذیر می‌شود.
- اگر کاربر در وبسایت آسیب‌پذیر لاگین کرده باشد، مرورگر به طور خودکار کوکی‌های سشن را نیز در ریکوئست می‌آورد (با فرض این که از قابلیت SameSite در کوکی‌ها استفاده نشده باشد).
- وبسایت آسیب‌پذیر ریکوئست را مانند یک ریکوئست معمولی پردازش می‌کند، و با آن دقیقا مانند باقی ریکوئست‌های کاربر قربانی رفتار می‌کند، و آدرس ایمیل این کاربر را تغییر می‌دهد.
نکته: اگرچه معمولا برای توضیح حمله CSRF، به اداره‌ی سشن مبتنی بر کوکی اشاره می‌شود، اما در شرایط دیگر و اصولا در تمام مواقعی که اپلیکیشن به طور خودکار نوعی از اطلاعات هویتی کاربر را در ریکوئست‌ها می‌آورد، این آسیب‌پذیری به وجود می‌آید. برای مثال این آسیب‌پذیری در احراز هویت پایه‌ی HTTP و احراز هویت مبتنی بر گواهینامه (certificate-based) نیز وجود دارد.
نحوه ساختن اکسپلویت CSRF با Burp Suite
ساختن دستی صفحه HTML لازم برای یک اکسپلویت CSRF نسبتا سخت و زمانبر است، به خصوص وقتی که ریکوئست مورد نیاز تعداد زیادی پارامتر داشته باشد، یا ریزه‌کاری‌های ریکوئست زیاد باشند. راحت‌ترین راه برای ساخت یک اکسپلویت CSRF، استفاده از CSRF PoC Generator است که به‌صورت پیش‌ساخته در نسخه Professional نرم‌افزار Burp Suite قرار دارد:
- در هرجایی از Brup Suite که می‌خواهید تست یا اکسپلویت کنید، یک ریکوئست انتخاب کنید.
- از منویی که با راست‌کلیک باز می‌شود، گزینه Engagement Tools/ Generate CSRF PoC را انتخاب کنید.
- Burp Suite به صورت خودکار یک کد HTML تولید می‌کند که باعث ارسال ریکوئست مورد نظر شما می‌شود (البته بدون کوکی، چون کوکی‌ها بعدا توسط مرورگر قربانی اضافه می‌شوند).
- می‌توانید گزینه‌های مختلف در CSRF PoC Generator را دستکاری کنید تا ویژگی‌های مختلف حمله را دقیقا مطابق میل خودتان تغییر دهید. ممکن است در بعضی موقعیت‌های غیرمعمول، برای دستکاری بعضی از ویژگی‌های خاص ریکوئست، نیاز باشد از این گزینه‌ها استفاده کنید.
- کد HTML تولیدشده را در یک صفحه وب کپی کنید، با یک مرورگر که در یک وبسایت آسیب‌پذیر لاگین کرده باشد آن را باز کنید، و ببینید ریکوئست مد نظر شما با موفقیت ارسال می‌شود و اقدام مورد نظرتان انجام می‌شود یا نه.
نحوه انتقال اکسپلویت CSRF
مکانیزم‌های انتقال حملات CSRF اساسا با حملات reflected XSS یکی هستند. معمولا، مهاجم محتوای مخرب HTML را در وبسایتی قرار می‌دهد که در کنترل خودش باشد، و سپس به روش‌های گوناگون قربانیان را مجاب به بازدید از آن وبسایت می‌کند. این کار را می‌توان از طریق ارسال لینک سایت برای کاربر در یک ایمیل یا پیام در شبکه‌های اجتماعی انجام داد. یا اگر حمله در یک وبسایت پرطرفدار قرار داده شده (مثلا در بخش نظرات یک بلاگ پربازدید)، مهاجم می‌تواند منتظر بنشیند تا کاربران از آن وبسایت دیدن کنند.
توجه داشته باشید که بعضی از اکسپلویت‌های ساده‌ی CSRF ممکن است از متد GET استفاده کنند و در این صورت می‌توانند به طور کامل در یک URL از وبسایت آسیب‌پذیر قرار بگیرند. در این صورت مهاجم دیگر نیاز به یک وبسایت خارجی ندارد و می‌تواند URL مربوطه به دامنه آسیب‌پذیر را مستقیما برای کاربران ارسال کرده و انتقال اکسپلویت را کامل کند. در مثال قبلی، اگر ریکوئست تغییر آدرس با متد GET قابل انجام باشد، در این صورت URL حاوی اکسپلویت به صورت زیر خواهد بود:
< img src=”https://vulnerable-website.com/email/change?email=pwned@evil-user.net”>
جلوگیری از حملات CSRF
مطمئن‌ترین راه برای جلوگیری از حملات، قراردادن یک توکن CSRF در ریکوئست‌های معتبر است. این توکن باید:
- مانند دیگر توکن‌های سشن، غیرقابل پیش‌بینی و به‌شدت تصادفی باشد.
- رابطه یک‌به‌یک با سشن کاربر داشته باشد.
- قبل از انجام هرگونه اقدام مرتبط با ریکوئست، به طور کامل و دقیق اعتبارسنجی شود.
یک راهکار دفاعی دیگر که تا حدودی در برابر CSRF موثر است و می‌توان آن را به صورت مکمل در کنار توکن‌های CSRF به کار برد، استفاده از قابلیت SameSite در کوکی‌های سشن کاربر است.
آسیب‌پذیری‌های رایج CSRF
منشأ جالب‌ترین آسیب‌پذیری‌های CSRF، اشتباهاتی هستند که در اعتبارسنجی توکن‌های CSRF رخ می‌دهند.
در مثال قبلی، فرض کنید اپلیکیشن این بار از توکن CSRF نیز داخل ریکوئست تغییر پسورد کاربر استفاده کرده است:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com
این نوع ریکوئست باید بتواند از حملات CSRF جلوگیری کند، چون شرایط لازم برای وجود آسیب‌پذیری CSRF را نقض می‌کند: دیگر اپلیکیشن برای اداره یا اصطلاحاً handling سشن، صرفا به کوکی‌ها وابسته نیست، و ریکوئست هم حاوی پارامتری است که مهاجم نمی‌تواند به سادگی تعیین کند. با این وجود، راه‌های مختلفی برای شکستن این راهکار دفاعی وجود دارد که به این معناست که اپلیکیشن هنوز نسبت به CSRF آسیب‌پذیر است.
اعتبارسنجی توکن CSRF به متد ریکوئست بستگی دارد
بعضی اپلیکیشن‌ها، وقتی که ریکوئست از متد POST استفاده می‌کند اعتبارسنجی توکن را به درستی انجام می‌دهند، ولی وقتی از متد GET استفاده شود، اعتبارسنجی را انجام نمی‌دهند.
در این مواقع، مهاجم می‌تواند برای دورزدن مرحله اعتبارسنجی از متد GET استفاده کند و حمله‌ی CSRF را انجام دهد:
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
اعتبارسنجی توکن CSRF به وجود توکن بستگی دارد
بعضی اپلیکیشن‌ها، وقتی توکن وجود داشته باشد به‌درستی آن را اعتبارسنجی می‌کنند، ولی اگر توکن در ریکوئست نیامده باشد، اعتبارسنجی را انجام نمی‌دهند.
در این مواقع، مهاجم می‌تواند کل پارامتر حاوی توکن (و نه فقط مقدار آن را) به طور کامل حذف کند تا بتواند اعتبارسنجی را دور زده و حمله CSRF را انجام دهد:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
توکن CSRF متعلق به سشن همان کاربر نیست
بعضی اپلیکیشن‌ها بررسی نمی‌کنند که توکن به همان سشنی که کاربر از آن ریکوئست را ارسال کرده تعلق دارند یا نه. در حقیقت در این مواقع اپلیکیشن یک مخزن از همه‌ی توکنهایی که منتشر کرده در اختیار دارد و هر توکنی را که در آن مخزن وجود داشته باشد می‌پذیرد.
در این مواقع، مهاجم می‌تواند با حساب خودش در اپلیکیشن لاگین کند، یک توکن معتبر به دست آورد، و سپس آن توکن را به عنوان توکن کاربر قربانی در حمله CSRF استفاده کند.
توکن CSRF در کوکی غیر از کوکی سشن قرار گرفته
این آسیب‌پذیری هم نوعی از آسیب‌پذیری قبلی است؛ بعضی اپلیکیشن‌ها توکن CSRF را در یک کوکی قرار می‌دهند، ولی نه آن کوکی که برای ردیابی سشن‌های کاربران استفاده می‌شود. وقتی اپلیکیشن از دو فریم‌‍ورک متفاوت برای اداره سشن‌ها و حفاظت در برابر CSRF استفاده کند، این اتفاق به‌راحتی ممکن است رخ دهد:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com
اکسپلویت‌کردن اپلیکیشن در این حالت سخت‌تر است، ولی به هر حال اپلیکیشن آسیب‌پذیر است. اگر وبسایت قابلیت‌ها و امکاناتی داشته باشد که مهاجم بتواند به‌واسطه آن‌ها در مرورگر قربانی یک کوکی تنظیم کند، در این صورت امکان حمله وجود دارد. مهاجم می‌تواند با اکانت خودش داخل اپلیکیشن لاگین کند، یک توکن معتبر و کوکی مربوط به آن را به دست آورد، از امکان تنظیم کوکی استفاده کرده و کوکی حاوی توکن خودش را در مرورگر قربانی قرار دهد، و سپس از توکنی که در اختیار دارد (و اپلیکیشن به عنوان توکن قربانی می‌شناسد) برای انجام حمله CSRF استفاده کند.
نکته: حتی لازم نیست امکان تنظیم کوکی در خود اپلیکیشنی وجود داشته باشد که آسیب‌پذیری CSRF دارد. عملاً می‌توان از هر اپلیکیشن دیگری که دامنه DNS کلی آن با اپلیکیشن آسیب‌پذیر یکسان است، برای تنظیم کوکی‌ها در اپلیکیشن هدف استفاده کرد؛ البته به شرطی که کوکی‌ها در scope مناسبی کنترل شوند. برای مثال می‌توان از قابلیت تنظیم کوکی در دامنه staging.demo.normal-website.com برای تنظیم کوکی‌هایی استفاده کرد که به دامنه secure.normal-website.com فرستاده می‌شوند.
توکن CSRF صرفا داخل یک کوکی کپی می‌شود
این آسیب‌پذیری هم نوع دیگری از آسیب‌پذیری قبلی است. بعضی اپلیکیشن‌ها، از کوکی‌هایی که صادر کرده‌اند هیچ اطلاعاتی در سمت سرور ذخیره نمی‌کنند، ولی در عوض هر توکن، هم داخل کوکی قرار می‌گیرد و هم داخل پارامتر ریکوئست؛ حال وقتی یک ریکوئست ارسال شد و اپلیکیشن خواست آن را اعتبارسنجی کند، صرفا بررسی می‌کند که توکن ثبت‌شده به عنوان پارامتر ریکوئست و مقدار توکن موجود در کوکی یکی باشند. گاهی اوقات به این روش، راهکار دفاعی « Double Submit » علیه CSRF می‌گویند، و دلیل استفاده‌ی گسترده از آن هم این است که پیاده‌سازی آن راحت است و نیاز به ذخیره اطلاعات در سمت سرور ندارد:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com
در این مواقع نیز اگر وبسایت هرگونه قابلیت تنظیم کوکی داشته باشد، مهاجم می‌تواند یک حمله CSRF صورت دهد. در این‌جا مهاجم حتی نیاز ندارد یک توکن معتبر برای خودش به دست آورد. کافی‌است یک توکن جعلی درست کند (در صورتی که قالب توکن توسط سرور چک می‌شود، این توکن باید قالب مناسبی هم داشته باشد)، و با استفاده از قابلیت تنظیم کوکی، کوکی خود را در مرورگر قربانی قرار دهد، و توکن خود را حین حمله CSRF در ریکوئست‌های قربانی استفاده کند.
روش‌های دفاعی مبتنی‌بر Referer برای جلوگیری از CSRF
علاوه بر روشهایی که از توکن‌های CSRF استفاده می‌کنند، برخی اپلیکیشن‌ها برای دفاع از خود در برابر CSRF، از هدر Referer در ریکوئست‌های HTTP استفاده می‌کنند. این کار معمولا با هدف این امر انجام می‌شود که اپلیکیشن اطمینان حاصل کند، ریکوئست‌ها از دامنه‌ی خودش ارسال شده‌اند. این روش معمولا کمتر موثر واقع می‌شود و اکثر اوقات می‌توان آن را دور زد.
هدر Referer در ریکوئست‌های HTTP (که در واقع منظور از آن کلمه Referrer است و در تعریف HTTP سهواً با غلط املایی آمده است) یک هدر اختیاری است. وقتی لینک یک منبع در یک صفحه قرار می‌گیرد و منبع مورد نظر از طریق آن صفحه ریکوئست می‌شود، URL صفحه‌ی مذکور داخل هدر Referer آن ریکوئست قرار می‌گیرد. معمولا وقتی کاربر با کارهایی مثل کلیک‌کردن روی یک لینک یا ثبت یک فرم، یک ریکوئست HTTP ارسال می‌کند، مرورگر به طور خودکار این هدر را در ریکوئست قرار می‌دهد. متدهای مختلفی وجود دارند که به صفحه‌ای که لینک در آن قرار گرفته اجازه می‌دهند مقدار هدر Referer را تغییر داده یا آن را به کلی حذف کنند. این متدها عمدتا به خاطر حفظ حریم خصوصی استفاده می‌شوند.
اعتبارسنجی Referer به وجود هدر آن بستگی دارد
بعضی اپلیکیشن‌ها فقط زمانی هدر Referer را اعتبارسنجی می‌کنند که در ریکوئست‌ها وجود داشته باشد، ولی اگر این هدر از ریکوئست حذف شده باشد، اعتبارسنجی را انجام نمی‌دهند.
در این مواقع، مهاجم می‌تواند اکسپلویت CSRF خود را به گونه‌ای طراحی کند که باعث شود مرورگر قربانی هدر Referer را از ریکوئست مورد نظر مهاجم حذف کند. راه‌های متنوعی برای انجام این کار وجود دارد، ولی آسان‌ترین راه استفاده از یک تگ META در صفحه‌ی HTML میزبان حمله‌ی CSRF است:
<meta name=”referrer” content=”never”>
اعتبارسنجی Referer قابل دور زدن است
در برخی اپلیکیشن‌ها، اعتبارسنجی هدر Referer با دقت کافی پیاده‌سازی نشده و به همین خاطر می‌توان آن را دور زد. برای مثال، اگر اپلیکیشن فقط بررسی کند که دامنه آمده در Referer با مقدار مورد انتظار یا همان دامنه معتبر شروع می‌شود یا نه، مهاجم می‌تواند دامنه‌ی معتبر را به عنوان زیردامنه‌ای از دامنه‌ی خودش بیاورد:
به همین صورت، اگر اپلیکیشن فقط بررسی کند که Referer صرفاً حاوی دامنه‌ی معتبر باشد، مهاجم می‌تواند دامنه‌ی معتبر را در جای دیگری از URL قرار دهد:
نکته: اگرچه ممکن است بتوانید این رفتار را با استفاده از Burp شناسایی کنید، مدتی است این رویکرد برای تست PoC، دیگر در مرورگرها جواب نمی‌دهد. دلیل آن هم این است که برای کمترشدن خطر نشت داده‌های حساس از این طریق، بسیاری از مرورگرها به صورت پیش‌فرض استرینگ کوئری را از هدر Referer حذف می‌کنند.
برای تغییر این رفتار، باید اطمینان حاصل کنید که در پاسخی که حاوی اکسپلویت شماست، هدر Referrer-Policy: unsafe-url تنظیم شده باشد (دقت کنید که در این‌جا Referrer بدون غلط املایی نوشته می‌شود!). با این کار URL به طور کامل (یعنی به علاوه استرینگ کوئری) ارسال خواهد شد.
تفاوت XSS و CSRF چیست؟
حمله XSS یا «تزریق اسکریپت از طریق وبگاه» به مهاجم اجازه می‌دهد کدهای جاوااسکریپت دلخواه خود را در مرورگر یک کاربر قربانی اجرا کند.
حمله CSRF یا «جعل درخواست میان‌وبسایتی» به مهاجم اجازه می‌دهد که از طریق مرورگر کاربر قربانی و بدون خواست و اطلاع او، اقداماتی را از طرف قربانی انجام دهد.
عواقب آسیب‌پذیری‌های XSS معمولا خطرناک‌تر از آسیب‌پذیری‌های CSRF هستند:
- حمله CSRF معمولا به زیرمجموعه‌ای کوچک از اقدامات محدود می‌شود که کاربر قادر به انجام آن‌هاست. بسیاری از اپلیکیشن‌ها راهکارهای دفاع در برابر CSRF را به صورت کلی پیاده‌سازی می‌کنند تا اگر یکی-دو اقدام حساس از قلم افتاد، آن اقدامات نیز پوشش داده شوند. ولی از طرف دیگر، یک اکسپلویت XSS عمدتا می‌تواند از طرف کاربر قربانی هر اقدامی را که آن کاربر قادر به انجام آن باشد، انجام دهد، فارغ از این که آسیب‌پذیری به خاطر کدام قابلیت اپلیکیشن به وجود آمده است.
- CSRF را می‌توان به عنوان یک آسیب‌پذیری «یک‌طرفه» تعریف کرد، یعنی وقتی مهاجم بتواند از طرف قربانی یک ریکوئست HTTP ارسال کند، نمی‌تواند پاسخ آن ریکوئست را به دست آورد. بر خلاف CSRF، آسیب‌پذیری XSS یک آسیب‌پذیری «دوطرفه» است، یعنی اسکریپت تزریق شده توسط مهاجم می‌تواند ریکوئست‌های دلخواه او را تولید و ارسال کند، پاسخ‌ها را بخواند، و داده‌ها را استخراج کرده و به یک دامنه‌ی خارجی متعلق به مهاجم ارسال کند.
آیا با توکن‌های CSRF می‌توان جلوی حملات XSS را گرفت؟
شاید جالب باشد که برخی از حملات XSS با استفاده‌ی موثر و درست از توکن‌های CSRF قابل پیشگیری هستند. یک آسیب‌پذیری ساده Reflected XSS را در نظر بگیرید که می‌توان آن را به این صورت اکسپلویت کرد:
حالا فرض کنید که این قابلیت آسیب‌پذیر، از یک توکن CSRF هم استفاده کند:
با فرض این که سرور به درستی توکن CSRF را اعتبارسنجی می‌کند، و ریکوئست‌هایی را که یک توکن معتبر ندارند ریجکت می‌کند، در این صورت توکن از اکسپلویت‌شدن آسیب‌پذیری XSS جلوگیری می‌کند. دلیل آن را هم از نام آسیب‌پذیری می‌توان فهمید: «تزریق اسکریپت بین-سایتی»؛ اکسپلویت این آسیب‌پذیری، یا حداقل در اکسپلویت نوع Reflected آن، نیاز به ارسال یک ریکوئست بین-سایتی یا «فراوبگاهی» دارد. اپلیکیشن با جلوگیری از ارسال یک ریکوئست بین-سایتی توسط مهاجم، از اکسپلویت ساده و بی‌دردسر آسیب‌پذیری XSS جلوگیری می‌کند.
- اگر آسیب‌پذیری Reflected XSS هرجای دیگری در وبسایت و در قابلیتی وجود داشته باشد که توسط توکن CSRF حفاظت نشده است، در این صورت می‌توان آسیب‌پذیری XSS را به همان روش‌های معمولی اکسپلویت کرد.
- اگر در هرجایی از وبسایت یک آسیب‌پذیری XSS وجود داشته باشد که امکان اکسپلویت آن وجود دارد، در این صورت می‌توان با استفاده از آن آسیب‌پذیری کاری کرد که کاربر قربانی اقدامات مورد نظر مهاجم را انجام دهد، حتی اقداماتی که خودشان توسط توکن‌های CSRF حفاظت شده‌اند. در این مواقع، اسکریپت مهاجم می‌تواند یک توکن CSRF معتبر را از صفحه مورد نظرش ریکوئست کند، و سپس از آن توکن برای انجام غیرمجاز یک اقدام حفاظت‌شده استفاده کند.
- توکن‌های CSRF حفاظتی در برابر آسیب‌پذیری‌های stored XSS فراهم نمی‌کنند. اگر یک صفحه با توکن CSRF حفاظت شده باشد، ولی در آن آسیب‌پذیری stored XSS وجود داشته باشد، در این صورت می‌توان این آسیب‌پذیری XSS را با روش‌های معمولی اکسپلویت کرد، و پی‌لود XSS بدون هیچ مشکلی هنگام بازدید کاربر از صفحه اجرا می‌شود.
سلام روز بخیر
برای ورود به برنامه ای این پیام نشون داده میشه و اجازه ورود نمیده
CSRF token missing or incorrect
باید چه کاری انجام بدم؟