آسیب‌پذیری CSRF چیست؟ بررسی Cross-Site Request Forgery و روش‌های جلوگیری

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

CSRF مخفف Cross-Site Request Forgery است و در فارسی معمولاً با عنوان «جعل درخواست بین‌سایتی» شناخته می‌شود. در این آسیب‌پذیری، یک وب‌سایت نمی‌تواند به‌درستی تشخیص دهد که درخواست حساس واقعاً با قصد کاربر ارسال شده یا مرورگر او تحت تأثیر یک سایت دیگر آن را ارسال کرده است.

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

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

این آسیب‌پذیری هنوز اهمیت زیادی دارد، اما مرورگرهای مدرن و Frameworkهای جدید ابزارهای دفاعی قدرتمندتری نسبت به گذشته ارائه می‌کنند. SameSite Cookie، CSRF Token، بررسی Origin، استفاده از Frameworkهای دارای محافظت داخلی و طراحی صحیح API می‌توانند خطر را به‌شدت کاهش دهند.

بااین‌حال هیچ‌کدام از این کنترل‌ها نباید بدون شناخت محدودیت‌هایشان استفاده شوند. برای مثال OWASP تأکید می‌کند که ویژگی SameSite یک لایه دفاعی مهم است، اما در بسیاری از معماری‌ها نباید جایگزین کامل CSRF Token یا سایر کنترل‌های اختصاصی شود.

در این مقاله از رخنه کاو بررسی می‌کنیم CSRF چیست، چگونه شکل می‌گیرد، چه شرایطی برای وقوع آن لازم است، چه تفاوتی با XSS دارد، CSRF Token چگونه کار می‌کند، SameSite Cookie چه نقشی دارد و چگونه می‌توان سایت‌های اختصاصی، APIها و سایت‌های وردپرسی را در برابر جعل درخواست بین‌سایتی ایمن کرد.

CSRF چیست؟

Cross-Site Request Forgery نوعی آسیب‌پذیری امنیتی در برنامه‌های وب است که در آن مهاجم تلاش می‌کند مرورگر یک کاربر احراز هویت‌شده را وادار کند در سایتی دیگر عملیاتی انجام دهد که کاربر قصد انجام آن را نداشته است.

مرورگر از دید سایت هدف ممکن است کاملاً معتبر به نظر برسد.

چرا؟

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

این ویژگی مهم‌ترین پایه حمله CSRF است.

مفهوم ساده CSRF

فرض کنید کاربری وارد یک سایت شده است.

سایت پس از ورود، یک Session Cookie برای مرورگر ایجاد می‌کند.

مرورگر در درخواست‌های بعدی آن Cookie را به‌صورت خودکار برای همان سایت ارسال می‌کند.

اکنون اگر برنامه تنها این سؤال را بپرسد:

«آیا این درخواست دارای Session معتبر است؟»

ولی نپرسد:

«آیا خود کاربر واقعاً قصد ارسال این درخواست را داشته است؟»

امکان CSRF به وجود می‌آید.

به همین دلیل Authentication موفق به‌تنهایی تضمین نمی‌کند یک Request مجاز و عمدی است.

چرا مرورگر Cookie را خودکار ارسال می‌کند؟

Cookie بخش اصلی بسیاری از سیستم‌های Session-Based Authentication است.

سرور پس از Login ممکن است Session Identifier را در Cookie قرار دهد.

مرورگر سپس براساس Domain، Path، Secure و سایر Attributeها تشخیص می‌دهد چه زمانی Cookie را همراه Request ارسال کند.

کاربر لازم نیست خودش Cookie را به Request اضافه کند.

همین رفتار برای تجربه کاربری وب ضروری است، اما در صورت نبود کنترل CSRF می‌تواند مورد سوءاستفاده قرار گیرد.

OWASP نیز ریشه اصلی بسیاری از CSRFها را همین رفتار توضیح می‌دهد: مرورگر Credentialهایی مانند Session Cookie را خودکار همراه درخواست به سایت مقصد می‌فرستد و در نبود کنترل اضافه، برنامه نمی‌تواند درخواست واقعی و جعل‌شده را از هم تشخیص دهد.

یک حمله CSRF چه شرایطی نیاز دارد؟

برای ایجاد CSRF کلاسیک معمولاً چند شرط باید هم‌زمان وجود داشته باشد.

قربانی باید در سایت هدف احراز هویت شده باشد

اگر عملیات فقط برای Userهای Login شده قابل انجام باشد، مهاجم به Session فعال قربانی وابسته است.

مرورگر Credential را خودکار ارسال کند

Cookie-Based Authentication نمونه کلاسیک آن است.

اگر Client مجبور باشد Token خاصی را به‌شکل دستی در Header اختصاصی قرار دهد و سایت مهاجم نتواند آن Header را آزادانه ایجاد کند، مدل تهدید متفاوت می‌شود.

یک عملیات حساس وجود داشته باشد

CSRF زمانی ارزش حمله دارد که Request بتواند State سیستم را تغییر دهد.

برای مثال:

• تغییر ایمیل
• تغییر رمز
• ثبت سفارش
• لغو سفارش
• تغییر تنظیمات
• افزودن کاربر
• تغییر Permission
• انجام عملیات مالی
• مدیریت محتوا

درخواست قابل بازسازی باشد

اگر Endpoint برای تأیید درخواست از مقدار غیرقابل پیش‌بینی و وابسته به Session استفاده نکند، سایت مهاجم ممکن است بتواند شکل لازم Request را ایجاد کند.

چرا CSRF بیشتر عملیات تغییر‌دهنده را هدف می‌گیرد؟

در حمله CSRF، مهاجم معمولاً نمی‌تواند Response سایت هدف را مستقیماً بخواند؛ Same-Origin Policy مرورگر در بسیاری از شرایط این کار را محدود می‌کند.

بنابراین صرفاً وادار کردن کاربر به باز کردن یک صفحه خصوصی معمولاً اطلاعات آن صفحه را مستقیماً در اختیار مهاجم قرار نمی‌دهد.

اما برای عملیات State-Changing این محدودیت مانع اصلی نیست.

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

OWASP نیز تأکید می‌کند که CSRF معمولاً روی Functionهایی تمرکز دارد که State سرور را تغییر می‌دهند.

نمونه مفهومی حمله CSRF

فرض کنید یک سایت قابلیتی برای تغییر زبان یا تنظیمات مهم کاربر دارد.

کاربر هنگام Login دارای Session معتبر است.

اگر Endpoint مربوطه صرفاً Session را بررسی کند و هیچ Token، Origin Check یا کنترل دیگری نداشته باشد، یک Request خارجی ممکن است توسط مرورگر قربانی ارسال شود و Cookie نیز در شرایط نامناسب همراه آن برود.

سرور Request را می‌بیند.

Session معتبر است.

درخواست از نظر Format نیز درست است.

اگر هیچ نشانه‌ای برای اثبات قصد واقعی کاربر وجود نداشته باشد، سرور عملیات را انجام می‌دهد.

این همان نقطه‌ای است که CSRF شکل می‌گیرد.

چرا نام Cross-Site Request Forgery انتخاب شده است؟

Cross-Site یعنی آغاز یا تحریک Request از Context سایتی دیگر.

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

به همین دلیل ترجمه «جعل درخواست بین‌سایتی» مفهوم نسبتاً دقیقی از این حمله ارائه می‌کند.

CSRF Token چیست؟

CSRF Token یک مقدار غیرقابل پیش‌بینی است که Server در اختیار Client معتبر قرار می‌دهد و انتظار دارد هنگام ارسال درخواست حساس همان مقدار همراه Request ارسال شود.

سرور هنگام دریافت Request Token را بررسی می‌کند.

اگر Token:

• وجود نداشته باشد
• معتبر نباشد
• با Session ارتباط نداشته باشد

Request رد می‌شود.

OWASP توصیه می‌کند اگر Framework محافظت داخلی CSRF دارد، از همان مکانیزم استفاده شود و در غیر این صورت CSRF Token برای Requestهای تغییر‌دهنده State ایجاد و در Backend اعتبارسنجی شود.

CSRF Token چگونه جلوی حمله را می‌گیرد؟

مهاجم ممکن است بداند Endpoint چیست و چه Parameterهایی نیاز دارد، اما نباید بتواند Token معتبر Session قربانی را حدس بزند.

سایت قانونی هنگام نمایش فرم یا ایجاد Context مربوط به User، Token مناسب را ارائه می‌دهد.

در Request واقعی کاربر:

Session Cookie + CSRF Token معتبر

به Backend می‌رسند.

اما در Request جعل‌شده، مهاجم Token صحیح را در اختیار ندارد.

در نتیجه Server می‌تواند Request را Reject کند.

ویژگی‌های CSRF Token مناسب

Token باید:

• غیرقابل حدس باشد.
• Entropy کافی داشته باشد.
• امن تولید شود.
• به Session یا Context مناسب مرتبط باشد.
• در Request حساس Validate شود.
• از محل‌هایی که به‌راحتی Leak می‌شوند دور نگه داشته شود.

Synchronizer Token Pattern چیست؟

یکی از الگوهای شناخته‌شده دفاع CSRF، Synchronizer Token Pattern است.

در این مدل Server Token را برای Session کاربر تولید می‌کند.

هنگام ارسال Form یا Request تغییر‌دهنده، Client Token را همراه Request ارسال می‌کند.

Backend Token دریافت‌شده را با مقدار مورد انتظار مقایسه می‌کند.

اگر مقادیر با Policy سیستم مطابقت نداشته باشند، Request اجرا نمی‌شود.

این Pattern در Frameworkهای مختلف با Implementationهای متفاوت دیده می‌شود.

Per-Session Token یا Per-Request Token؟

CSRF Token می‌تواند برای کل Session یا هر Request به‌صورت جداگانه تولید شود.

Per-Session Token

یک Token تا پایان Session معتبر است.

مزیت آن سادگی و تجربه کاربری مناسب‌تر است.

Per-Request Token

برای عملیات‌های مختلف Tokenهای متفاوت استفاده می‌شوند.

از نظر امنیتی می‌تواند محدوده استفاده مجدد را کمتر کند، اما پیچیدگی و مشکلات UX بیشتری ایجاد می‌کند.

برای مثال Back Button مرورگر یا چند Tab ممکن است نیازمند مدیریت دقیق‌تری باشند.

انتخاب باید براساس Risk و Framework انجام شود.

Double Submit Cookie چیست؟

Double Submit Cookie یکی دیگر از Patternهای دفاعی است.

در این معماری Token در Cookie و در یک بخش دیگر Request ارسال می‌شود.

Server بررسی می‌کند دو مقدار با یکدیگر سازگار هستند.

OWASP انواع Signed Double Submit Cookie را برای معماری‌هایی که Synchronizer Token مناسب نیست توضیح می‌دهد و استفاده از نسخه‌های دارای Binding قوی‌تر به Session را ترجیح می‌دهد.

آیا CSRF Token باید داخل Cookie باشد؟

در Synchronizer Token Pattern معمولاً Token مورد استفاده نباید صرفاً همان مقدار Cookie Authentication باشد.

علت مشخص است:

اگر مرورگر همه موارد لازم را به شکل خودکار همراه Request ارسال کند، مزیت اصلی Token از بین می‌رود.

هدف این است که Request معتبر دارای مقداری باشد که سایت خارجی نتواند به‌سادگی به آن دسترسی پیدا کند یا مرورگر آن را خودکار در محل مورد انتظار اضافه نکند.

SameSite Cookie چیست؟

SameSite یکی از Attributeهای مهم Cookie است که مشخص می‌کند Cookie در چه شرایطی همراه Requestهای Cross-Site ارسال شود.

سه مقدار رایج عبارت‌اند از:

• Strict
• Lax
• None

MDN توضیح می‌دهد که SameSite کنترل می‌کند Cookie در Requestهایی که از Site دیگری شروع شده‌اند ارسال شود یا خیر و این قابلیت می‌تواند در برابر برخی حملات CSRF محافظت ایجاد کند.

SameSite=Strict چگونه کار می‌کند؟

در حالت Strict، Cookie برای Requestهایی که از Site دیگری آغاز شده‌اند محدودتر می‌شود.

از نظر CSRF گزینه قدرتمندی است.

اما می‌تواند تجربه کاربری را تحت تأثیر قرار دهد.

برای مثال کاربری که از لینک سایت دیگری وارد سرویس می‌شود ممکن است در Navigation اولیه مانند حالت Login شده شناسایی نشود.

بنابراین Strict برای تمام Cookieها همیشه بهترین انتخاب عملی نیست.

SameSite=Lax چیست؟

Lax تعادل بیشتری میان امنیت و تجربه کاربری ایجاد می‌کند.

طبق توضیح MDN، در Cross-Site Navigationهای Top-Level با Methodهای Safe مانند GET ممکن است Cookie ارسال شود، اما بسیاری از Requestهای Cross-Site ناامن محدود می‌شوند.

این موضوع یک نکته امنیتی بسیار مهم ایجاد می‌کند:

GET نباید برای عملیات تغییر‌دهنده State استفاده شود.

اگر سایتی عملیاتی حساس را با GET اجرا کند، SameSite=Lax نمی‌تواند در همه شرایط دفاع قابل اتکایی ایجاد کند.

OWASP نیز همین مورد را از مهم‌ترین محدودیت‌های دفاع مبتنی بر SameSite معرفی می‌کند.

SameSite=None چیست؟

SameSite=None اجازه می‌دهد Cookie در Contextهای Cross-Site نیز ارسال شود.

برای برخی معماری‌هایی که واقعاً Cross-Site Cookie نیاز دارند این گزینه ضروری است.

مرورگرهای مدرن برای Cookieهایی با SameSite=None استفاده از Secure را نیز لازم می‌دانند.

از دید امنیتی چنین Cookieهایی نیازمند کنترل دقیق CSRF هستند.

آیا SameSite به‌تنهایی کافی است؟

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

OWASP صراحتاً SameSite را یک کنترل Defense in Depth معرفی می‌کند و در بسیاری از Deploymentها استفاده هم‌زمان از Token یا Double-Submit Pattern و بررسی Origin را توصیه می‌کند.

چرا SameSite محدودیت دارد؟

یکی از دلایل تفاوت میان مفهوم Site و Origin است.

دو Subdomain ممکن است Cross-Origin باشند ولی همچنان Same-Site محسوب شوند.

برای مثال:

app.example.com

و

shop.example.com

Origin یکسان ندارند، اما ممکن است در محاسبات SameSite زیر یک Site قرار گیرند.

MDN و PortSwigger هر دو روی اهمیت تفاوت Site و Origin در تحلیل SameSite تأکید می‌کنند.

در نتیجه امنیت Subdomainها اهمیت زیادی پیدا می‌کند.

تفاوت Site و Origin چیست؟

Origin از سه جزء تشکیل می‌شود:

• Scheme
• Host
• Port

دو URL برای Same-Origin بودن باید این اجزا را مطابق قواعد Origin داشته باشند.

Site مفهوم گسترده‌تری دارد و معمولاً حول Registrable Domain و Scheme محاسبه می‌شود.

به همین دلیل ممکن است دو URL:

Same-Site باشند

اما

Same-Origin نباشند.

این تفاوت در طراحی Cookie Security بسیار مهم است.

Origin Header چه نقشی در جلوگیری از CSRF دارد؟

در Requestهای مختلف مرورگر ممکن است Origin را ارسال کند.

Backend می‌تواند بررسی کند Origin Request با Originهای مجاز مطابقت دارد یا خیر.

اگر یک درخواست State-Changing از Origin خارجی آمده باشد، برنامه می‌تواند آن را Reject کند.

این روش به‌خصوص به‌عنوان لایه مکمل دفاعی مفید است.

Referer Header چطور؟

Referer نیز می‌تواند اطلاعاتی درباره صفحه مبدأ Request ارائه کند.

اما نباید با مقایسه‌های ضعیف String یا اعتماد کورکورانه استفاده شود.

همچنین در برخی شرایط Policyهای Privacy ممکن است اطلاعات Referer را کاهش دهند یا حذف کنند.

به همین دلیل طراحی باید Fail-Safe و مطابق راهنمای Framework باشد.

OWASP در راهنمای جدید خود Origin/Referer Verification را به‌عنوان یکی از لایه‌های دفاعی مطرح می‌کند، اما آن را بخشی از یک معماری کامل می‌داند نه جایگزین تمام کنترل‌ها.

تفاوت CSRF و XSS چیست؟

CSRF و XSS گاهی با هم اشتباه گرفته می‌شوند، اما ماهیت متفاوتی دارند.

در XSS

مهاجم تلاش می‌کند کد یا محتوای فعال خود را در Context سایت هدف اجرا کند.

در CSRF

مهاجم از Session معتبر قربانی برای تحریک یک Request ناخواسته استفاده می‌کند.

رابطه XSS و CSRF

یک نکته بسیار مهم این است که XSS می‌تواند بسیاری از دفاع‌های CSRF را تضعیف یا بی‌اثر کند.

OWASP صراحتاً هشدار می‌دهد که وجود XSS می‌تواند دفاع‌های CSRF را دور بزند؛ به همین دلیل جلوگیری از XSS و CSRF باید هم‌زمان بخشی از Secure Development باشند.

آیا CSRF Token از XSS جلوگیری می‌کند؟

خیر.

CSRF Token برای اثبات Context یا قصد Request طراحی شده است.

اگر مهاجم بتواند از طریق XSS داخل Origin قانونی JavaScript اجرا کند، مدل تهدید کاملاً تغییر می‌کند.

پس Token ضد CSRF جای Output Encoding، Sanitization و Content Security Policy را نمی‌گیرد.

تفاوت CSRF و Clickjacking چیست؟

در Clickjacking مهاجم تلاش می‌کند کاربر را فریب دهد تا روی عنصر یا کنترل رابط کاربری کلیک کند که کاربر تصور دیگری درباره آن دارد.

در CSRF لزوماً چنین Overlay بصری نیاز نیست.

ریشه هر دو می‌تواند به سوءاستفاده از تعامل مرورگر مربوط باشد، اما کنترل‌های دفاعی متفاوت هستند.

برای Clickjacking ابزارهایی مانند:

• frame-ancestors
• CSP
• X-Frame-Options

اهمیت دارند.

تفاوت CSRF و SSRF چیست؟

این دو به‌رغم شباهت اسمی کاملاً متفاوت هستند.

CSRF

مرورگر کاربر Request ناخواسته‌ای ارسال می‌کند.

SSRF

سرور فریب داده می‌شود تا به Resource یا مقصد دیگری Request بفرستد.

CSRF بیشتر Client/Browser Context را درگیر می‌کند، در حالی که SSRF یک تهدید Server-Side است.

آیا HTTPS از CSRF جلوگیری می‌کند؟

خیر.

HTTPS ارتباط را رمزنگاری می‌کند و مانع شنود یا تغییر ساده Traffic در مسیر می‌شود.

اما اگر مرورگر قربانی خودش Request معتبر HTTPS را به مقصد ارسال کند، TLS نمی‌تواند تشخیص دهد کاربر واقعاً آن عملیات را می‌خواسته است یا نه.

OWASP نیز صراحتاً HTTPS را دفاع مستقیم CSRF نمی‌داند، هرچند HTTPS یک پیش‌نیاز مهم برای امنیت کلی Session و Cookie است.

آیا استفاده از POST جلوی CSRF را می‌گیرد؟

خیر.

این تصور یکی از اشتباهات کلاسیک امنیت وب است.

POST به‌خودی‌خود ثابت نمی‌کند Request از UI قانونی سایت آمده است.

سایت‌های خارجی نیز در شرایط مختلف می‌توانند مرورگر را به ارسال Requestهای POST وادار کنند.

OWASP نیز «فقط قبول کردن POST» را به‌عنوان دفاع ناکافی معرفی می‌کند.

پس چرا GET نباید State را تغییر دهد؟

این دو موضوع تناقض ندارند.

POST به‌تنهایی کافی نیست، اما GET نیز برای State Change طراحی نشده است.

عملیات‌هایی که State سیستم را تغییر می‌دهند باید از Method مناسب استفاده کنند و سپس کنترل CSRF مستقل داشته باشند.

آیا فرم چندمرحله‌ای جلوی CSRF را می‌گیرد؟

نه لزوماً.

اگر مهاجم بتواند مراحل را پیش‌بینی کند و هیچ Token یا کنترل غیرقابل جعل وجود نداشته باشد، Multi-Step بودن Process دفاع امنیتی واقعی ایجاد نمی‌کند.

OWASP نیز صرفاً چندمرحله‌ای کردن Transaction را دفاع کافی در برابر CSRF نمی‌داند.

CSRF در صفحه تغییر رمز عبور

Password Change یکی از عملیات‌های حساس است.

اگر User وارد حساب باشد و Endpoint تغییر رمز فقط Session معتبر را بپذیرد، طراحی می‌تواند ریسک CSRF داشته باشد.

برای عملیات بسیار حساس بهتر است چند کنترل ترکیب شوند:

• CSRF Protection
• Re-authentication
• درخواست Password فعلی
• MFA در شرایط حساس
• Notification امنیتی

وجود CSRF Token به این معنی نیست که Re-authentication برای عملیات بسیار مهم غیرضروری است.

CSRF در تغییر ایمیل

تغییر Email یکی از سناریوهای مهم Account Security است.

Email معمولاً برای:

• Password Reset
• Alert
• Login
• Recovery

استفاده می‌شود.

بنابراین Endpoint تغییر Email باید علاوه بر CSRF Protection، Verification مناسب نیز داشته باشد.

CSRF در پنل مدیریت

شدت CSRF به Permission قربانی وابسته است.

اگر قربانی Admin باشد، عملیات‌هایی مانند:

• تغییر User
• ایجاد حساب
• تغییر Configuration
• انتشار محتوا
• مدیریت دسترسی‌ها

ممکن است تحت تأثیر قرار گیرند.

به همین دلیل Admin Panel باید کنترل‌های CSRF بسیار دقیق داشته باشد.

Login CSRF چیست؟

Login CSRF نوع خاصی از CSRF است که هدف آن لزوماً استفاده از Session فعلی قربانی نیست.

در این سناریو ممکن است کاربر ناخواسته وارد Session یا Account دیگری شود.

این مسئله می‌تواند در برخی Workflowها باعث اشتباه در ثبت داده یا اتصال اطلاعات کاربر به Account ناخواسته شود.

مدیریت Login نیز باید منشأ Request، Session و Flow را به‌درستی کنترل کند.

آیا APIها در برابر CSRF آسیب‌پذیر هستند؟

بستگی به نحوه Authentication دارد.

اگر API از Cookie-Based Session استفاده کند و مرورگر Cookie را خودکار ارسال کند، CSRF همچنان مسئله مهمی است.

اما اگر API از Bearer Token استفاده کند که Client باید آن را در Header خاصی قرار دهد و Token خودکار توسط Browser در Cross-Site Request اضافه نمی‌شود، شرایط CSRF کلاسیک تغییر می‌کند.

بااین‌حال نباید نتیجه گرفت که «REST API هیچ‌وقت CSRF ندارد».

Authentication Model تعیین‌کننده است.

JWT و CSRF

JWT فقط یک Format Token است و به‌تنهایی مشخص نمی‌کند سیستم در برابر CSRF مقاوم است یا خیر.

محل نگهداری و نحوه ارسال JWT اهمیت دارد.

JWT در Cookie

اگر JWT در Cookie قرار داشته باشد و Browser آن را خودکار ارسال کند، CSRF همچنان می‌تواند مطرح باشد.

Token در Authorization Header

اگر Client Token را آگاهانه از Storage مناسب دریافت و در Authorization Header قرار دهد، سایت خارجی معمولاً نمی‌تواند بدون محدودیت همان Header را با Credential قربانی ایجاد کند.

اما این مدل ممکن است مسائل امنیتی دیگری، مخصوصاً در برابر XSS و Token Theft، داشته باشد.

هیچ روش احراز هویتی بدون Trade-Off نیست.

CORS و CSRF

یکی از اشتباهات رایج این است که تصور کنیم فعال کردن یا محدود کردن CORS به‌تنهایی CSRF را حل می‌کند.

CORS یک مکانیزم مرورگر برای کنترل دسترسی JavaScript Originهای مختلف به Response و برخی Requestهای Cross-Origin است.

اما CSRF از این واقعیت سوءاستفاده می‌کند که مرورگر در برخی Requestها Credential را به مقصد می‌فرستد.

در نتیجه:

CORS جای CSRF Protection را نمی‌گیرد.

تنظیم CORS همچنان بخش مهم امنیت API است، اما مسئله متفاوتی را حل می‌کند.

Preflight Request چیست و آیا مانع CSRF می‌شود؟

برخی Cross-Origin Requestهای پیچیده نیازمند Preflight هستند.

Browser ابتدا یک Request OPTIONS ارسال می‌کند تا Permission لازم را بررسی کند.

این رفتار می‌تواند Surface برخی Requestها را محدود کند.

اما نباید تمام دفاع CSRF روی Preflight بنا شود.

Endpoint و Authentication Model باید به‌صورت مستقل ایمن باشند.

Custom Request Header در دفاع CSRF

در برخی SPAها می‌توان برای Requestهای حساس Header اختصاصی نیاز داشت.

Cross-Origin ارسال کردن Header سفارشی معمولاً وارد قواعد CORS و Preflight می‌شود.

این روش می‌تواند بخشی از معماری دفاع باشد.

اما Backend باید Header را واقعاً Validate کند و CORS نیز دقیق تنظیم شده باشد.

Fetch Metadata Headers چیست؟

مرورگرهای مدرن Metadataهایی درباره Context Request ارائه می‌کنند که می‌توانند به Server کمک کنند Cross-Site بودن برخی Requestها را تشخیص دهد.

OWASP استفاده از Fetch Metadata را یکی از لایه‌های جدید دفاع در برابر CSRF مطرح کرده است.

این روش می‌تواند به‌عنوان Defense in Depth مفید باشد، اما مانند SameSite بهتر است براساس Compatibility و معماری به‌درستی طراحی شود.

HttpOnly چه نقشی در CSRF دارد؟

HttpOnly مانع دسترسی معمول JavaScript به Cookie می‌شود.

این ویژگی برای کاهش خطر سرقت Session Cookie از طریق برخی XSSها بسیار مهم است.

اما HttpOnly به‌تنهایی مانع CSRF نمی‌شود.

چرا؟

زیرا برای CSRF مهاجم الزاماً لازم نیست Cookie را بخواند.

کافی است مرورگر در شرایط مناسب Cookie را خودکار به Request اضافه کند.

Secure Cookie چه نقشی دارد؟

Attribute Secure باعث می‌شود Cookie فقط روی ارتباط امن HTTPS ارسال شود.

این قابلیت برای امنیت Session ضروری است.

اما مانند HttpOnly دفاع مستقیم و کامل CSRF نیست.

بهترین Cookie Security معمولاً ترکیبی از Attributeهای مناسب است.

MDN توصیه می‌کند دسترسی Cookie تا حد ممکن محدود شود و از تنظیماتی مانند Secure، HttpOnly و SameSite براساس کاربرد استفاده شود.

Prefixهای __Host- و __Secure-

مرورگرهای مدرن از Prefixهایی برای اعمال محدودیت بیشتر روی Cookieها پشتیبانی می‌کنند.

برای Cookieهای حساس، استفاده صحیح از __Host- می‌تواند Scope Cookie را محدودتر کند و برخی مشکلات ناشی از Subdomainها را کاهش دهد.

MDN استفاده از __Host- را برای Cookieهایی که فقط روی Host مشخص نیاز هستند پیشنهاد می‌کند.

این قابلیت یک لایه مکمل است و جای Token یا Authorization را نمی‌گیرد.

چگونه CSRF Token را به‌درستی Validate کنیم؟

اشتباه Implementation می‌تواند باعث شود Token از نظر ظاهری وجود داشته باشد ولی دفاع واقعی ایجاد نکند.

Token باید اجباری باشد

اگر Request بدون Token همچنان پذیرفته شود، کل مکانیزم بی‌فایده خواهد بود.

Token باید معتبر باشد

صرف وجود Parameter با نام csrf کافی نیست.

Backend باید مقدار را بررسی کند.

Token باید به Context مناسب مرتبط باشد

Token عمومی و یکسان برای تمام کاربران سطح حفاظت مطلوبی ایجاد نمی‌کند.

همه Endpointهای تغییر‌دهنده State باید بررسی شوند

اگر ۹ Endpoint Token داشته باشند ولی Endpoint دهم فراموش شده باشد، همان مسیر می‌تواند ضعف سیستم باشد.

Token نباید در URL حساس قرار گیرد

قرار دادن CSRF Token در Query String می‌تواند باعث ثبت شدن آن در:

• History
• Log
• Analytics
• Referer

شود.

بنابراین بهتر است روش انتقال Token براساس Framework و توصیه امنیتی آن انتخاب شود.

آیا هر فرم باید CSRF Token داشته باشد؟

فرم‌هایی که State حساس سیستم را تغییر می‌دهند و بر Cookie-Based Authentication تکیه دارند، معمولاً به محافظت CSRF نیاز دارند.

فرم‌های کاملاً عمومی که هیچ State شخصی یا عملیاتی را با Credential User انجام نمی‌دهند مدل تهدید متفاوتی دارند.

بااین‌حال Spam و Automation همچنان ممکن است مسئله باشند که با CSRF متفاوت است.

CSRF در وردپرس

وردپرس برای بسیاری از عملیات مدیریتی و Formهای حساس از مکانیزم Nonce استفاده می‌کند.

در وردپرس Nonce یک کنترل برای کاهش خطر اجرای Requestهای ناخواسته است، هرچند از نظر مفهومی دقیقاً مشابه Nonce رمزنگاری یک‌بارمصرف سنتی نیست.

Developer افزونه یا قالب باید هنگام ایجاد عملیات حساس از APIهای امنیتی وردپرس به‌درستی استفاده کند.

CSRF در افزونه وردپرس چگونه ایجاد می‌شود؟

مشکل معمولاً زمانی ایجاد می‌شود که Developer:

• Action حساس ایجاد کند.
• فقط Login بودن User را بررسی کند.
• Nonce را بررسی نکند.
• Permission مناسب را بررسی نکند.

در چنین شرایطی Request ممکن است با Session Admin اجرا شود.

Nonce به‌تنهایی Authorization نیست

یکی از نکات مهم توسعه WordPress این است که Nonce نباید جای Capability Check را بگیرد.

Backend باید هم بررسی کند Request معتبر است و هم User اجازه انجام عملیات را دارد.

پس:

Nonce Verification + Capability Check

هر دو اهمیت دارند.

CSRF در AJAX وردپرس

Endpointهای AJAX نیز باید کنترل شوند.

وجود AJAX به معنی امن بودن Request نیست.

Developer باید برای Action حساس:

• Permission
• Nonce
• Input Validation

را بررسی کند.

تمام کنترل‌ها باید Server-Side باشند.

CSRF در REST API وردپرس

در WordPress REST API نیز Authentication Method اهمیت دارد.

اگر Endpoint اختصاصی Plugin ساخته می‌شود، permission_callback و کنترل Permission باید دقیق باشد.

اگر Request در Context Cookie Authentication انجام می‌شود، مکانیزم‌های امنیتی WordPress نیز باید مطابق Documentation استفاده شوند.

امنیت Formهای اختصاصی PHP

در پروژه‌های PHP خام، Developer ممکن است محافظت Framework آماده نداشته باشد.

در این شرایط نباید CSRF Token با روش‌های دست‌ساز ضعیف مانند Timestamp ساده یا Hash قابل پیش‌بینی تولید شود.

بهتر است از CSPRNG استاندارد زبان و الگوی معتبر استفاده شود.

Server باید Token را در Session نگهداری یا طبق Pattern امن Validate کند.

CSRF در Laravel

Frameworkهای مدرن مانند Laravel مکانیزم CSRF Middleware ارائه می‌کنند.

Developer باید از قابلیت پیش‌فرض Framework استفاده کند و بدون دلیل Endpointهای حساس را از Protection خارج نکند.

یکی از مشکلات رایج، اضافه کردن مسیرهای زیاد به Exception List برای حل سریع خطاهای Frontend است.

این کار می‌تواند دفاع Framework را تضعیف کند.

CSRF در Django

Django نیز مکانیزم داخلی CSRF دارد.

Templateها و Middleware آن در صورت استفاده صحیح بخش زیادی از پیچیدگی را مدیریت می‌کنند.

Developer باید از راهکار Framework استفاده کند نه اینکه Token اختصاصی ضعیف بسازد.

CSRF در SPAها

Single Page Applicationها ممکن است UI را کاملاً با JavaScript مدیریت کنند.

اما اگر Authentication با Cookie انجام شود، CSRF همچنان باید بررسی شود.

معماری رایج می‌تواند شامل:

• Cookie امن
• SameSite مناسب
• CSRF Token
• Custom Header
• Origin Validation

باشد.

انتخاب دقیق به Framework و Backend بستگی دارد.

نقش Same-Origin Policy در CSRF

Same-Origin Policy محدودیت مهمی در Browser است که مانع بسیاری از تعاملات مستقیم میان Originهای مختلف می‌شود.

اما این Policy همیشه مانع ارسال Request نمی‌شود.

بخش مهمی از CSRF دقیقاً از همین تفاوت استفاده می‌کند:

مهاجم ممکن است نتواند Response را بخواند، اما در شرایط آسیب‌پذیر بتواند Browser را به ارسال Request وادار کند.

PortSwigger نیز CSRF را حمله‌ای می‌داند که بخشی از محدودیت‌های Same-Origin Policy را دور می‌زند و User را به انجام عملی ناخواسته وادار می‌کند.

عملیات حساس بهتر است Re-authentication داشته باشند

برای بعضی Actionها فقط CSRF Token کافی نیست.

برای مثال:

• تغییر Password
• تغییر MFA
• حذف Account
• تغییر Recovery Email
• عملیات مالی بزرگ

می‌توان از Re-authentication استفاده کرد.

یعنی کاربر دوباره Password، Passkey یا عامل دوم را تأیید کند.

در این صورت حتی Compromise یک Session محدودتر می‌شود.

آیا CAPTCHA جلوی CSRF را می‌گیرد؟

CAPTCHA برای تشخیص انسان از Bot طراحی شده است.

CSRF الزاماً یک Bot Request مستقیم نیست؛ ممکن است Browser یک انسان واقعی Request را ارسال کند.

بنابراین CAPTCHA دفاع اصلی CSRF محسوب نمی‌شود.

در عملیات بسیار حساس می‌توان CAPTCHA را برای اهداف دیگری استفاده کرد، اما Token و Intent Verification همچنان لازم هستند.

آیا MFA جلوی CSRF را می‌گیرد؟

MFA در Login بسیار مهم است، اما اگر User قبلاً Login کرده و Session فعال باشد، یک Request حساس ممکن است بدون MFA مجدد اجرا شود.

برای Actionهای مهم می‌توان Step-Up Authentication تعریف کرد.

پس MFA دفاع کلی Account Security است ولی به‌خودی‌خود جای CSRF Token را نمی‌گیرد.

آیا WAF جلوی CSRF را می‌گیرد؟

WAF ممکن است بعضی Patternهای مشکوک یا Requestهای خارجی را محدود کند، اما در CSRF Request می‌تواند از نظر HTTP کاملاً معتبر باشد و Cookie واقعی کاربر را همراه داشته باشد.

WAF معمولاً نمی‌داند User واقعاً قصد انجام عملیات را داشته است یا خیر.

پس راه‌حل اصلی باید داخل Application باشد.

اشتباهات رایج در جلوگیری از CSRF

فقط بررسی POST

POST بودن Request اثبات قصد User نیست.

فقط استفاده از HTTPS

HTTPS محتوای Request را محافظت می‌کند، نه قصد آن را.

فقط مخفی کردن Endpoint

مسیر Secret کنترل امنیتی قابل اتکا نیست.

استفاده از Token ثابت

Token ثابت برای تمام کاربران یا تمام Sessionها دفاع ضعیفی ایجاد می‌کند.

قبول Request بدون Token

اگر Token Optional باشد، مهاجم مسیر بدون Token را استفاده خواهد کرد.

Token بدون Binding مناسب

وجود یک رشته تصادفی که ارتباطی با Context User ندارد ممکن است هدف امنیتی موردنظر را تأمین نکند.

تغییر State با GET

این اشتباه به‌خصوص دفاع SameSite=Lax را تضعیف می‌کند.

تکیه کامل به SameSite

SameSite بسیار مفید است، اما در بسیاری از پروژه‌ها باید بخشی از Defense in Depth باشد.

فراموش کردن Subdomainها

Same-Site بودن Subdomainها می‌تواند Trust Boundary را گسترده‌تر از چیزی کند که Developer تصور می‌کند.

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

بهترین رویکرد چندلایه است.

استفاده از محافظت داخلی Framework

اولین انتخاب باید سیستم CSRF Protection Framework باشد.

Frameworkهای بالغ معمولاً جزئیات زیادی مانند:

• تولید Token
• Storage
• Validation
• Error Handling

را مدیریت می‌کنند.

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

CSRF Token برای State-Changing Requestها

در Cookie-Based Applicationها، Requestهای حساس باید Token مناسب داشته باشند.

Server باید Token را قبل از اجرای Business Logic Validate کند.

استفاده صحیح از SameSite

Session Cookie براساس نیاز می‌تواند Lax یا Strict باشد.

None فقط زمانی استفاده شود که Cross-Site Behavior واقعاً لازم است و کنترل‌های دیگر نیز وجود داشته باشند.

بررسی Origin

State-Changing Endpointها می‌توانند Origin Request را براساس Allowlist دقیق بررسی کنند.

استفاده از Fetch Metadata

در Browserهای پشتیبانی‌شده، Fetch Metadata می‌تواند به تشخیص Cross-Site Request کمک کند.

عدم استفاده از GET برای State Change

GET باید برای Retrieval طراحی شود.

عملیات تغییر‌دهنده باید Method مناسب و محافظت CSRF داشته باشد.

Re-authentication برای عملیات حساس

هرچه اثر عملیات بیشتر باشد، سطح تأیید باید بالاتر رود.

مدیریت امن Cookie

استفاده مناسب از:

• Secure
• HttpOnly
• SameSite
• Host Prefix

سطح کلی امنیت Session را افزایش می‌دهد.

جلوگیری از XSS

چون XSS می‌تواند بسیاری از کنترل‌های CSRF را دور بزند، دفاع XSS بخشی از معماری واقعی CSRF است.

چک‌لیست جلوگیری از CSRF

برای ارزیابی سریع سایت می‌توان موارد زیر را بررسی کرد:

• Framework CSRF Protection فعال باشد.
• تمام عملیات State-Changing شناسایی شوند.
• GET هیچ عملیات تغییر‌دهنده مهمی انجام ندهد.
• CSRF Token برای Requestهای حساس معتبر باشد.
• Token غیرقابل پیش‌بینی باشد.
• Token با Context مناسب ارتباط داشته باشد.
• Request بدون Token Reject شود.
• SameSite Cookie آگاهانه تنظیم شود.
• Cookieهای Session از Secure استفاده کنند.
• HttpOnly برای Session Cookie در صورت امکان فعال باشد.
• Domain Cookie بیش از حد گسترده نباشد.
• Origin برای عملیات حساس بررسی شود.
• Referer در صورت استفاده به‌شکل امن Validate شود.
• Subdomainها بخشی از Threat Model باشند.
• عملیات بسیار حساس Re-authentication داشته باشند.
• MFA برای Accountهای مدیریتی فعال باشد.
• CORS دقیق تنظیم شود.
• API Authentication Model مشخص باشد.
• XSS Prevention جدی گرفته شود.
• WAF جای Application Control را نگیرد.
• Security Test دوره‌ای انجام شود.

تست CSRF چگونه باید انجام شود؟

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

هدف ارزیابی دفاعی باید این باشد که مشخص شود:

• آیا عملیات حساس Token دارند؟
• آیا Token واقعاً Validate می‌شود؟
• آیا Token برای User/Session مناسب است؟
• آیا SameSite صحیح است؟
• آیا Origin بررسی می‌شود؟
• آیا Endpoint State را با GET تغییر می‌دهد؟
• آیا API مبتنی بر Cookie Protection مناسب دارد؟

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

Code Review برای پیدا کردن CSRF

در Code Review ابتدا تمام Endpointهای State-Changing پیدا می‌شوند.

برای هر Endpoint باید مشخص شود:

Authentication چگونه انجام می‌شود؟

Cookie؟

Bearer Token؟

روش دیگر؟

آیا Authorization وجود دارد؟

CSRF Protection جای Permission Check را نمی‌گیرد.

آیا Intent Verification وجود دارد؟

Token، Origin یا مکانیزم Framework؟

Method مناسب است؟

GET نباید Business State حساس را تغییر دهد.

SAST و DAST در تشخیص CSRF

ابزارهای خودکار می‌توانند در شناسایی برخی Endpointهای بدون Protection مفید باشند.

اما Scanner ممکن است Context Framework، Business Logic یا معماری Token را کامل درک نکند.

به همین دلیل بررسی دستی و Code Review همچنان مهم هستند.

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

اولین قدم صرفاً مسدود کردن یک Request یا IP نیست.

CSRF یک ضعف طراحی Application است.

Endpointهای حساس را شناسایی کنید

تمام مسیرهای مشابه بررسی شوند.

اگر یک Form آسیب‌پذیر است، احتمال دارد Formهای دیگری نیز همان Pattern را داشته باشند.

محافظت Framework را فعال کنید

اگر Framework قابلیت داخلی دارد، از راهکار استاندارد آن استفاده کنید.

SameSite را اصلاح کنید

Session Cookie براساس نیاز واقعی تنظیم شود.

Origin Validation اضافه کنید

برای State-Changing Requestها Layer اضافی ایجاد کنید.

Methodها را اصلاح کنید

عملیات حساس از GET خارج شوند.

Sessionها و Audit Log را بررسی کنید

اگر شواهد سوءاستفاده واقعی وجود دارد، مشخص شود چه Actionهایی انجام شده‌اند.

Retest انجام دهید

رفع یک Endpoint کافی نیست؛ Pattern باید در تمام Application بررسی شود.

CSRF و Secure Development Lifecycle

بهترین زمان جلوگیری از CSRF هنگام طراحی سیستم است.

مرحله طراحی

مشخص کنید Authentication مبتنی بر چیست.

اگر Cookie Session استفاده می‌شود، CSRF Strategy نیز تعریف شود.

مرحله توسعه

از Middleware یا Component استاندارد Framework استفاده کنید.

Code Review

هر State-Changing Endpoint باید CSRF و Authorization Review شود.

تست

Integration Test می‌تواند اطمینان دهد Request بدون Token معتبر رد می‌شود.

Production

Security Header، Cookie Configuration و Logها پایش شوند.

Threat Modeling برای CSRF

چند سؤال ساده می‌توانند Risk را مشخص کنند:

• آیا Browser Credential را خودکار ارسال می‌کند؟
• آیا Endpoint State را تغییر می‌دهد؟
• آیا Request از Origin خارجی قابل تحریک است؟
• چه چیزی Intent User را اثبات می‌کند؟
• اگر قربانی Admin باشد چه اتفاقی می‌افتد؟
• آیا Subdomain غیرقابل اعتماد وجود دارد؟
• آیا XSS در بخشی از Site می‌تواند Defense را تضعیف کند؟

پاسخ این سؤال‌ها معماری دفاع را مشخص می‌کند.

CSRF و سایت‌های فروشگاهی

در فروشگاه‌ها عملیات‌هایی مانند:

• تغییر Address
• اضافه کردن محصول
• حذف سفارش
• تغییر اطلاعات Account
• اعمال تنظیمات Seller

باید بررسی شوند.

Checkout و Payment نیز معمولاً علاوه بر CSRF به کنترل‌های Business Logic و Idempotency نیاز دارند.

CSRF و سایت‌های مالی

هر عملیات مالی باید سطح بالاتری از Verification داشته باشد.

CSRF Protection پایه ضروری است، اما برای تراکنش‌های حساس می‌توان از:

• Transaction Confirmation
• MFA
• Re-authentication
• Notification

نیز استفاده کرد.

هدف این است که Compromise یک لایه به‌تنهایی برای اجرای تراکنش کافی نباشد.

CSRF و پنل‌های سازمانی

پنل‌های داخلی گاهی اشتباهاً Trusted تلقی می‌شوند.

اما اگر User سازمانی بتواند اینترنت را مرور کند و Session پنل داخلی نیز فعال باشد، CSRF همچنان ممکن است در Threat Model مطرح باشد.

«داخل شبکه بودن» جای کنترل Application Security را نمی‌گیرد.

آیا CSRF هنوز در مرورگرهای مدرن مهم است؟

بله، اما شرایط دفاع نسبت به گذشته بهتر شده است.

SameSite پیش‌فرض مرورگرها و Framework Protection میزان زیادی از CSRFهای ساده را کاهش داده‌اند.

بااین‌حال:

• Legacy Applicationها
• Cookie Configuration اشتباه
• GETهای State-Changing
• Subdomainهای ناامن
• Frameworkهای سفارشی
• Exceptionهای اشتباه

همچنان می‌توانند آسیب‌پذیری ایجاد کنند.

MDN و OWASP هر دو همچنان CSRF را یک تهدید معتبر وب می‌دانند و دفاع‌های چندلایه را مستند می‌کنند.

سوالات متداول درباره CSRF

CSRF چیست؟

CSRF یا Cross-Site Request Forgery آسیب‌پذیری‌ای است که می‌تواند مرورگر کاربر احراز هویت‌شده را وادار کند درخواست ناخواسته‌ای به سایت معتبر ارسال کند. سایت آسیب‌پذیر Request را به دلیل وجود Credential معتبر به نام User اجرا می‌کند.

CSRF مخفف چیست؟

CSRF مخفف Cross-Site Request Forgery است و با نام XSRF نیز دیده می‌شود.

CSRF Token چیست؟

CSRF Token یک مقدار غیرقابل پیش‌بینی است که Client معتبر آن را همراه Request حساس ارسال می‌کند و Server پیش از اجرای عملیات صحت آن را بررسی می‌کند.

آیا SameSite جلوی CSRF را می‌گیرد؟

SameSite بخش مهمی از دفاع CSRF است، اما OWASP توصیه می‌کند در بسیاری از معماری‌ها به‌عنوان Defense in Depth استفاده شود و جای Token یا کنترل‌های دیگر را نگیرد.

تفاوت SameSite=Lax و Strict چیست؟

Strict محدودیت بیشتری برای ارسال Cookie در Contextهای Cross-Site اعمال می‌کند. Lax تجربه کاربری منعطف‌تری دارد و در برخی Top-Level Navigationهای Safe Method اجازه ارسال Cookie را می‌دهد.

آیا HTTPS از CSRF جلوگیری می‌کند؟

خیر. HTTPS Traffic را در مسیر امن می‌کند اما قصد واقعی User را تأیید نمی‌کند.

آیا POST از CSRF جلوگیری می‌کند؟

خیر. Request POST نیز می‌تواند در سناریوهای آسیب‌پذیر جعل شود. Token و سایر کنترل‌ها همچنان لازم هستند.

آیا JWT در برابر CSRF امن است؟

به نحوه نگهداری و ارسال Token بستگی دارد. اگر JWT داخل Cookie خودکار ارسال شود، CSRF همچنان ممکن است مطرح باشد.

آیا CORS جلوی CSRF را می‌گیرد؟

CORS و CSRF دو موضوع متفاوت هستند. CORS کنترل می‌کند JavaScript از Originهای دیگر چگونه با Resource تعامل کند، ولی جای CSRF Protection را نمی‌گیرد.

آیا HttpOnly جلوی CSRF را می‌گیرد؟

خیر. HttpOnly خواندن Cookie توسط JavaScript را محدود می‌کند، اما مرورگر همچنان ممکن است Cookie را خودکار همراه Request ارسال کند.

تفاوت CSRF و XSS چیست؟

در CSRF مهاجم از Session قربانی برای انجام عملیات ناخواسته استفاده می‌کند. در XSS مهاجم تلاش می‌کند کد خود را در Context سایت هدف اجرا کند.

آیا XSS می‌تواند CSRF Token را بی‌اثر کند؟

وجود XSS می‌تواند بسیاری از مکانیزم‌های CSRF را دور بزند؛ به همین دلیل OWASP تأکید می‌کند مقابله با XSS برای امنیت کامل CSRF نیز ضروری است.

آیا وردپرس در برابر CSRF محافظت دارد؟

وردپرس APIهای Nonce برای محافظت از Actionهای حساس ارائه می‌کند. افزونه‌ها و کدهای اختصاصی باید این کنترل‌ها را به‌درستی همراه با Capability Check استفاده کنند.

آیا CSRF فقط سایت‌های بزرگ را تهدید می‌کند؟

خیر. هر Application مبتنی بر Browser و Cookie Session که عملیات حساس بدون Intent Verification داشته باشد می‌تواند در معرض خطر قرار گیرد.

جمع‌بندی

CSRF یا Cross-Site Request Forgery یکی از آسیب‌پذیری‌های مهم امنیت وب است که از اعتماد یک برنامه به Requestهای مرورگر کاربر سوءاستفاده می‌کند. در این حمله مهاجم الزاماً Session Cookie یا Password قربانی را نمی‌دزدد؛ بلکه تلاش می‌کند مرورگر همان کاربر، Credential معتبر را هنگام ارسال یک Request ناخواسته به سایت هدف همراه خود بفرستد.

همین ویژگی CSRF را از بسیاری از حملات دیگر متمایز می‌کند.

برنامه ممکن است کاملاً مطمئن باشد User چه کسی است، اما هنوز نتواند تشخیص دهد آیا User واقعاً قصد انجام آن عملیات را داشته است یا خیر.

دفاع مؤثر باید همین فاصله میان «هویت» و «قصد انجام عملیات» را پوشش دهد.

یکی از مهم‌ترین کنترل‌ها CSRF Token است. Token باید غیرقابل پیش‌بینی باشد، در Requestهای تغییر‌دهنده State ارسال شود و Backend آن را پیش از اجرای عملیات Validate کند. OWASP نیز استفاده از قابلیت CSRF Framework و Tokenهای معتبر برای State-Changing Requestها را از مهم‌ترین روش‌های دفاعی معرفی می‌کند.

ویژگی SameSite Cookie نیز نقش بسیار مهمی دارد. Strict یا Lax می‌توانند ارسال Cookie در بسیاری از Contextهای Cross-Site را محدود کنند. بااین‌حال SameSite محدودیت‌هایی دارد و در بیشتر معماری‌های پیچیده بهتر است بخشی از Defense in Depth باشد، نه تنها کنترل امنیتی.

بررسی Origin، Fetch Metadata، Cookie Configuration مناسب، Re-authentication برای عملیات مهم و عدم استفاده از GET برای تغییر State لایه‌های دیگری هستند که مقاومت Application را افزایش می‌دهند.

در سایت‌های وردپرسی نیز Developer باید Actionهای حساس را با Nonce مناسب و Capability Check محافظت کند. وجود Nonce به‌تنهایی Permission User را اثبات نمی‌کند و وجود Permission نیز Intent Request را تأیید نمی‌کند؛ هر دو باید بررسی شوند.

APIها نیز بسته به Authentication Model ممکن است در برابر CSRF آسیب‌پذیر باشند. REST یا GraphQL بودن API مسئله اصلی نیست؛ سؤال اصلی این است که Credential چگونه ارسال می‌شود و آیا Browser آن را بدون دخالت Client به Request اضافه می‌کند یا خیر.

همچنین هیچ‌وقت نباید به HTTPS، POST، CORS، CAPTCHA یا WAF به‌عنوان جایگزین کامل CSRF Protection نگاه کرد. هرکدام مسئله متفاوتی را حل می‌کنند.

از طرف دیگر، XSS می‌تواند بسیاری از دفاع‌های CSRF را تضعیف کند. بنابراین Secure Coding باید هم‌زمان Output Encoding، Sanitization، Session Security و CSRF Protection را پوشش دهد.

در نهایت معماری امن CSRF را می‌توان در چند اصل خلاصه کرد:

کاربر را احراز هویت کنید؛ دسترسی او را کنترل کنید؛ State را با GET تغییر ندهید؛ Request حساس را با Token معتبر یا مکانیزم استاندارد Framework تأیید کنید؛ Cookie را با SameSite مناسب محدود کنید؛ Origin را بررسی کنید و برای عملیات بسیار حساس از تأیید مجدد هویت استفاده کنید.

امنیت واقعی زمانی ایجاد می‌شود که Server علاوه بر اینکه بداند چه کسی Request را ارسال کرده است، بتواند با سطح اطمینان مناسبی تشخیص دهد که این Request واقعاً در Context مورد انتظار برنامه و با قصد کاربر ایجاد شده است.