آموزش جلوگیری از حملات CSRF در FortiWeb 7.6 با GUI و CLI

این مقاله بر اساسFortiWeb 7.6نوشته شده است. در نسخه‌های دیگر ممکن است مسیرهای GUI، نام فیلدها یا رفتار برخی قابلیت‌ها متفاوت باشد.

مروری بر این مقاله

1. حمله CSRF چیست و چگونه اجرا می‌شود؟
2. FortiWeb چگونه از درخواست‌ها محافظت می‌کند؟
3. پیش‌نیازها و محدودیت‌های مهم
4. طراحی Page List و URL List
5. سناریوی نمونه کانفیگ
6. پیکربندی CSRF در GUI
7. پیکربندی CSRF در CLI
8. استفاده از Parameter Filter
9. روش تست و اعتبارسنجی
10. خطاهای رایج و Troubleshooting
11. Best Practiceهای عملیاتی
12. چک‌لیست اجرایی

1. حمله CSRF چیست و چگونه اجرا می‌شود؟

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

نمونه اثرهای احتمالی

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

بر اساس راهنمای OWASP، دفاع اصلی باید در خود برنامه شامل توکن ضد CSRF، کنترل مجدد مجوزها و طراحی صحیح نشست باشد. FortiWeb یک لایه دفاعی تکمیلی در جلوی برنامه ایجاد می‌کند و نباید جایگزین کنترل‌های امنیتی داخل Application در نظر گرفته شود.

2. FortiWeb چگونه از درخواست‌ها محافظت می‌کند؟

قابلیت CSRF Protection در FortiWeb بر اساس ارتباط میان دو فهرست کار می‌کند

هنگامی که کاربر صفحه‌ای از Page List را دریافت می‌کند، FortiWeb در پاسخ HTML اسکریپتی قرار می‌دهد که مقدارtknfvرا به لینک‌ها و فرم‌های صفحه اضافه می‌کند. مقدار توکن با کوکی صادرشده توسط Client Management مرتبط است. وقتی مرورگر درخواستی به یکی از URLهای موجود در URL List ارسال می‌کند، FortiWeb مقدار توکن و نشست را بررسی می‌کند.

اگر توکن وجود نداشته باشد یا با مقدار مورد انتظار نشست تطبیق نکند، FortiWeb بر اساس Action تنظیم‌شده می‌تواند فقط Log ایجاد کند، درخواست را مسدود کند، بدون Log آن را رد کند یا برای یک بازه زمانی Client را Block کند.

محافظت از درخواست‌های AJAX در FortiWeb 7.6

در FortiWeb 7.6 امکان افزودن توکن به درخواست‌های JavaScript مبتنی برXMLHttpRequestوجود دارد. برای این کار باید گزینهJS Request StatusیاAjaxcheck Statusفعال باشد. مستند رسمی به‌طور مشخص از تابع بومیXMLHttpRequestنام می‌برد؛ بنابراین در برنامه‌هایی که ازfetchکتابخانه‌های سفارشی، WebSocket، Mobile Client یا API Clientهای بدون مرورگر استفاده می‌کنند، حتماً رفتار واقعی برنامه را آزمایش کنید.

3. پیش‌نیازها و محدودیت‌های مهم

پیش‌نیازهای اصلی

• ترافیک باید از یکInline Protection Profileعبور کند.
• Client Managementدر Web Protection Profile فعال باشد.
• Web Protection Profile موردنظر روی Server Policy فعال و در مسیر واقعی ترافیک باشد.
• صفحات Page List و درخواست‌های URL List دقیقاً با جریان واقعی برنامه تطبیق داده شوند.
• در صورت استفاده از Host Status، ابتدا Protected Host مربوط به دامنه یا IP تعریف شده باشد.

محدودیت حالت استقرار

طبق مستندFortinetاین قابلیت در حالت‌هایOffline ProtectionوTransparent Inspectionپشتیبانی نمی‌شود. علت عملیاتی این محدودیت آن است که FortiWeb برای این مکانیزم باید پاسخ HTML را تغییر دهد و کوکی نشست موردنیاز Client Management را مدیریت کند.

4. طراحی Page List و URL List

مهم‌ترین بخش کانفیگ، شناخت Flow واقعی برنامه است. قبل از ساخت Rule مشخص کنید هر عملیات حساس از کدام صفحه آغاز می‌شود و به کدام Endpoint درخواست می‌فرستد.

Simple String یا Regular Expression؟

برای URLهای مشخص و ثابت ازSimple Stringاستفاده کنید. استفاده بی‌دلیل از Regular Expression می‌تواند Scope Rule را بیش از حد گسترده کند و احتمال False Positive را افزایش دهد. Regular Expression زمانی مناسب است که ساختار URL متغیر است و الگوی آن دقیقاً شناخته شده باشد.

5. سناریوی نمونه کانفیگ

در این سناریو، کاربر از صفحه پروفایل وارد فرم تغییر ایمیل می‌شود و فرم یک درخواست POST به Endpoint تغییر ایمیل ارسال می‌کند

در مرحله اول Rule را روی Alert قرار می‌دهیم تا درخواست‌های واقعی، Endpointهای فراموش‌شده و Clientهای غیرمرورگری مشخص شوند. پس از بررسی Logها و رفع False Positiveها، Action به Alert & Deny تغییر می‌کند.

6. پیکربندی CSRF در GUI

مرحله اول: ساخت CSRF Protection Rule

1. رویCreate Newکلیک کنید.
2. در قسمت Name مقدارPARTIAN-CSRFرا وارد کنید.
3. در شروع Tune، Action را رویAlertقرار دهید.
4. Severity را متناسب با سیاست Log سازمان انتخاب کنید؛ برای شروع مقدارMediumمناسب است.
5. در صورت نیاز Trigger Action را برای ارسال Alert یا اجرای Trigger Policy انتخاب کنید.
6. برای برنامه‌های دارای درخواست AJAX مبتنی بر XMLHttpRequest، گزینهJS Request StatusیاAjaxcheck Statusرا فعال کنید.
7. تنظیمات را ذخیره کنید.

مرحله دوم: افزودن صفحه به Page List Table

در داخل Rule و در بخشPage List TableرویCreate Newکلیک کنید و مقادیر زیر را وارد کنید

مرحله سوم: افزودن Endpoint به URL List Table

در بخشURL List TableرویCreate Newکلیک کنید

مرحله چهارم: فعال‌کردن Rule در Inline Protection Profile

1. Profile متصل به Server Policy برنامه را Edit کنید.
2. Client Managementرا فعال کنید.
3. در فیلدCSRF ProtectionRule با نامPARTIAN-CSRFرا انتخاب کنید.
4. Profile را ذخیره کنید.
5. اطمینان حاصل کنید همین Web Protection Profile در Server Policy فعال برنامه استفاده شده است.

7. پیکربندی CSRF در CLI

ساخت Rule در حالت Alert

config waf csrf-protection edit "PARTIAN-CSRF" set action alert set severity Medium set ajaxcheck enable config csrf-page-list edit 1 set request-url "/account/profile" set request-type plain next end config csrf-url-list edit 1 set request-url "/api/account/email" set request-type plain next end next end

در CLI مقدارplainمعادل Simple String و مقدارregularمعادل Regular Expression است. گزینهajaxcheck enableبرای افزودن توکن به درخواست‌های XMLHttpRequest استفاده می‌شود.

اتصال Rule به Inline Protection Profile

config waf web-protection-profile inline-protection edit "PARTIAN-INLINE-PROFILE" set client-management enable set csrf-protection "PARTIAN-CSRF" next end

نامPARTIAN-INLINE-PROFILEرا با نام واقعی Web Protection Profile متصل به Server Policy جایگزین کنید.

محدودکردن Rule به Protected Host

اگر یک Profile برای چند دامنه استفاده می‌شود، بهتر است Page List و URL List را به Protected Host مشخص محدود کنید. نام Host باید از قبل در Protected Host Names تعریف شده باشد.

config waf csrf-protection edit "PARTIAN-CSRF" config csrf-page-list edit 1 set host-status enable set host "portal.example.com" set request-url "/account/profile" set request-type plain next end config csrf-url-list edit 1 set host-status enable set host "portal.example.com" set request-url "/api/account/email" set request-type plain next end next end

تغییر Action به Alert & Deny پس از Tune

config waf csrf-protection edit "PARTIAN-CSRF" set action alert_deny next end

گزینه‌های Action در CLI

8. استفاده از Parameter Filter

گاهی URL نمایش صفحه و URL دریافت فرم یکسان است. برای مثال درخواست GET به/post.aspصفحه را نمایش می‌دهد و درخواست POST به همان URL فایل را آپلود می‌کند. در این وضعیت FortiWeb باید تشخیص دهد کدام درخواست برای تزریق JavaScript و کدام درخواست برای بررسی توکن است.

Parameter Filter امکان می‌دهد Match علاوه بر URL، بر اساس یک پارامتر موجود در Query String یا HTTP Body انجام شود. در مثال زیر، وجود پارامترSUB1با هر مقداری نشان می‌دهد که درخواست مربوط به Submit فرم است

config waf csrf-protection edit "PARTIAN-CSRF-UPLOAD" set action alert config csrf-page-list edit 1 set request-url "/post.asp" set request-type plain next end config csrf-url-list edit 1 set request-url "/post.asp" set request-type plain set parameter-filter enable set parameter-name "SUB1" set parameter-value-type regular set parameter-value "*" next end next end

9. روش تست و اعتبارسنجی

مرحله اول: تست تزریق توکن

1. Rule را ابتدا روی Alert قرار دهید.
2. با یک Browser جدید یا Private Window وارد برنامه شوید تا نشست تازه ساخته شود.
3. صفحه/account/profileرا از مسیر FortiWeb باز کنید.
4. در Browser DevTools، تب Network را باز کنید.
5. فرم تغییر ایمیل را ارسال کنید.
6. در Request مربوط به/api/account/emailوجود پارامترtknfvرا در Query String یا Request Body بررسی کنید.

مرحله دوم: تست تطبیق توکن

1. یک درخواست سالم را با ابزار تست مجاز سازمان یا Browser DevTools ثبت کنید.
2. در محیط آزمایش، همان درخواست را بدون پارامترtknfvیا با مقدار تغییرکرده ارسال کنید.
3. در حالت Alert باید درخواست عبور کند اما Attack Log مربوط به CSRF ایجاد شود.
4. پس از فعال‌کردن Alert & Deny، همان درخواست ناقص باید Block شود.

مرحله سوم: تست Flowهای جانبی

• تمام دکمه‌ها و فرم‌های صفحه، نه فقط مسیر اصلی، آزمایش شوند.
• درخواست‌های AJAX در Chrome، Firefox و Edge بررسی شوند.
• Login مجدد، Session Timeout، Logout و بازکردن صفحه در Tab جدید آزمایش شود.
• Mobile App، API Client، Integration و Jobهای خودکار که Endpoint یکسان را مصرف می‌کنند تست شوند.
• در صورت وجود CDN، Reverse Proxy یا Load Balancer جلوی FortiWeb، مسیر واقعی کوکی و Host Header بررسی شود.

10. خطاهای رایج و Troubleshooting

شرایط رسمی Fortinet برای تزریق صحیح اسکریپت

• نوع صفحه باید HTML باشد و تگ‌هایورا داشته باشد.
• HTTP Response Code صفحه باید200 OKباشد.
• برای پاسخ فشرده، Uncompress Policy متناظر تنظیم شده باشد.
• مقدار Maximum Body Cache Size از اندازه صفحه بزرگ‌تر باشد.

11. Best Practiceهای عملیاتی

1. از Alert شروع کنیدابتدا رفتار واقعی سامانه را مشاهده و سپس Block را فعال کنید.
2. Scope را کوچک نگه داریدفقط عملیات‌های State-Changing و حساس را وارد URL List کنید.
3. Page و URL را مستند کنیدبرای هر Endpoint حساس، صفحه یا Flow تولیدکننده درخواست مشخص باشد.
4. Host Status را در محیط Multi-Tenant فعال کنیدURL مشابه در دامنه‌های مختلف نباید ناخواسته Match شود.
5. Regex را محدود کنیدSimple String برای URL ثابت امن‌تر و قابل‌پیش‌بینی‌تر است.
6. Clientهای غیرمرورگری را فراموش نکنیدMobile App، Integration و API Client ممکن است توکن تزریق‌شده به HTML را دریافت نکنند.
7. همه Browserها را تست کنیدJavaScript، Cookie Policy و Extensionهای مرورگر می‌توانند روی Flow اثر بگذارند.
8. Application-Level CSRF را حفظ کنیدتوکن داخلی Framework، SameSite Cookie، کنترل Origin/Referer و Authorization را حذف نکنید.
9. Log و Trigger را فعال کنیدبدون Log کافی، Tune و تشخیص False Positive دشوار می‌شود.
10. پس از تغییر برنامه Regression Test انجام دهیدتغییر Frontend، Form Action یا API Route می‌تواند Mapping قبلی را نامعتبر کند.

12. چک‌لیست اجرایی

• نسخه و Build دقیق FortiWeb ثبت شده است.
• Deployment Mode از CSRF Protection پشتیبانی می‌کند.
• Server Policy و Inline Protection Profile صحیح شناسایی شده‌اند.
• Client Management فعال است.
• تمام Pageهای تولیدکننده درخواست حساس شناسایی شده‌اند.
• تمام Endpointهای نیازمند توکن در URL List قرار گرفته‌اند.
• Host Status در محیط چنددامنه‌ای بررسی شده است.
• برای URLهای مشترک، Parameter Filter طراحی شده است.
• JS Request Status/Ajaxcheck برای XMLHttpRequest بررسی شده است.
• Rule ابتدا در حالت Alert آزمایش شده است.
• وجودtknfvدر درخواست سالم تأیید شده است.
• درخواست بدون توکن در Log شناسایی شده است.
• مرورگرها، Mobile Appها و Integrationها Regression Test شده‌اند.
• پس از Tune، Action به Alert & Deny تغییر کرده است.
• Attack Log و Trigger Policy مانیتور می‌شوند.
• مستندات Application Flow پس از هر Release به‌روزرسانی می‌شوند.

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