‫تحول در امنیت ASP.NET Core 11: بررسی عمیق مکانیسم خودکار و بدون پیکربندی مقابله با حملات CSRF

راهکار: باید روی این مسیرهای خاص، محافظت ضد جعل را غیرفعال کنید:

app.MapPost("/api/payment-callback", ...).DisableAntiforgery();
// یا در کنترلرها
[IgnoreAntiforgeryToken]

• از چند نام دامنه مختلف (مثلاً app.example.com و api.example.com) استفاده می‌کرده.
• یا سیاست‌های CORS را به صورت نام‌گذاری‌شده (Named Policies) تعریف کرده بوده (builder.Services.AddCors(options => options.AddPolicy("MyPolicy", ...))).
• یا در CORS از AllowAnyOrigin() استفاده می‌کرده.

راهکار: باید دامنه‌های موثق را حتماً در Default Policy مربوط به CORS ثبت کنید:

builder.Services.AddCors(options => {
    options.AddDefaultPolicy(policy => {
        policy.WithOrigins("https://app.example.com");
    });
});

• بررسی Webhookها: روی تمام Endpointهایی که از خارج از برنامه داده‌های فرم دریافت می‌کنند، .DisableAntiforgery() بگذارید.
• بررسی CORS: مطمئن شوید دامنه‌های مورد اعتماد شما در Default CORS Policy تعریف شده‌اند نه فقط در Named Policies.
• عدم دستکاری میدل‌ورها: اگر از Blazor استفاده می‌کنید، نیازی به حذف یا اضافه‌کردن کدهای عجیب برای ضدجعل ندارید؛ بگذارید WebApplicationBuilder کار خود را به صورت پیش‌فرض انجام دهد.

• سیستم توکن برای تولید و رمزنگاری کلیدها به زیرساخت Data Protection متکی است. در معماری‌های کلود (مثل Kubernetes) یا Web Farmها، همگام‌سازی و ذخیره‌سازی امن این کلیدها میان نسخه‌های متعدد (Replicas) نیاز به تنظیمات پیچیده (مانند Redis یا Azure Key Vault) دارد.

• در الگوی توکن سنتی، معمولاً آخرین صفحه‌ای که بارگذاری می‌شود حاوی توکن معتبر است. اگر کاربر فرمی را در یک تب باز نگه دارد و در تب دیگر با برنامه کار کند، توکن تب اول باطل شده و با ارسال فرم خطای Invalid Token دریافت می‌کند.

• عملیات رمزنگاری/داده‌گشایی توکن برای هر فرم و عدم امکان کش کردن صفحات استاتیک (به دلیل یکتا بودن توکن هر درخواست)، کارایی برنامه را کاهش می‌دهد.

[ ورود درخواست به CsrfProtectionMiddleware ]
   │
   ├── ۱. آیا متد HTTP امن است؟ (GET, HEAD, OPTIONS, TRACE, QUERY) ──> [ مجاز ]
   ├── ۲. آیا Sec-Fetch-Site برابر same-origin یا none است؟ ───────> [ مجاز ]
   ├── ۳. آیا Origin در لیست مجاز CORS endpoint هست؟ ───────────────> [ مجاز ]
   ├── ۴. آیا Sec-Fetch-Site وجود دارد؟ (مقادیر cross-site / same-site) ──> [ مسدود ]
   ├── ۵. آیا Origin موجود است؟
   │       ├── تطابق Origin با هدر Host ─────────────────────────────> [ مجاز ]
   │       └── عدم تطابق Origin با Host ─────────────────────────────> [ مسدود ]
   └── ۶. هدرهای Sec-Fetch-Site و Origin وجود ندارند؟
           └── درخواست غیرمرورگری است (مثل cURL / Postman) ───────────> [ مجاز ]

• درخواست از طریق مرورگر ارسال شود.
• احراز هویت مبتنی بر Cookie باشد.
• داده‌ها به صورت فرم ارسال شوند.

public class DisableAntiForgeryTagHelperInitializer : ITagHelperInitializer<FormTagHelper>
{
    public void Initialize(FormTagHelper helper, ViewContext context)
    {
        // غیرفعال کردن ساخت input مخفی توکن
        helper.Antiforgery = false;
    }
}

// ثبت در DI Container:
builder.Services.AddSingleton<ITagHelperInitializer<FormTagHelper>>(
    new DisableAntiForgeryTagHelperInitializer());

public class RemoveAntiforgeryConvention : IPageApplicationModelConvention, IControllerModelConvention
{
    public void Apply(PageApplicationModel model) => RemoveFilter(model.Filters);
    public void Apply(ControllerModel controller) => RemoveFilter(controller.Filters);

    private static void RemoveFilter(IList<IFilterMetadata> filters)
    {
        var antiforgeryFilter = filters.FirstOrDefault(f => f is AutoValidateAntiforgeryTokenAttribute);
        if (antiforgeryFilter != null)
        {
            filters.Remove(antiforgeryFilter);
        }
    }
}

// اضافه کردن Convention در تنظیمات:
builder.Services.AddRazorPages(options => options.Conventions.Add(new RemoveAntiforgeryConvention()));
builder.Services.AddControllersWithViews(options => options.Conventions.Add(new RemoveAntiforgeryConvention()));

public class CsrfProtectionAuthorizationFilter : IAuthorizationFilter, IAntiforgeryPolicy
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        // بررسی وضعیت اعتبارسنجی که قبلاً توسط CsrfProtectionMiddleware ثبت شده است
        var validationFeature = context.HttpContext.Features.Get<IAntiforgeryValidationFeature>();
        
        if (validationFeature is { IsValid: false })
        {
            // رد کردن درخواست در صورت غیرمجاز بودن Cross-Site
            context.Result = new AntiforgeryValidationFailedResult();
        }
    }
}

هشدار امنیتی: دستکاری فوق یک راهکار آزمایشگاهی برای یکپارچه‌سازی کامل MVC است. در محیط‌های عملیاتی (Production)، توصیه می‌شود تا انتشار نسخه‌های نهایی .NET 11 و پشتیبانی رسمی مایکروسافت، در MVC از رفتار پیش‌فرض (دفاع دو لایه‌ای) استفاده کنید.

• رفتار قبلی: توسعه‌دهندگان صرفاً با تنظیم خط‌مشی‌های CORS، درخواست‌های بین درگاهی را در مرورگر مجاز می‌کردند.
• تغییر در .NET 11: چون درگاه‌های متفاوت از دیدگاه مرورگر Cross-Origin محسوب می‌شوند، درخواست‌های POST، PUT، PATCH یا DELETE هدر Sec-Fetch-Site: cross-site دریافت کرده و توسط لایه جدید CSRF رد می‌شوند.

راهکار توسعه: اتکا به CORS در محیط محلی دیگر کافی نیست. سرورهای توسعه فرانت‌اند باید به گونه‌ای پیکربندی شوند که درخواست‌های API را پروکسی کنند تا ارتباط از دید مرورگر کاملاً Same-Origin به نظر برسد:

// نمونه پیکربندی در vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'https://localhost:5001',
        changeOrigin: true,
        secure: false
      }
    }
  }
}

• پایانه‌های ابطال توکن (Revocation Endpoint)
• پایانه‌های بررسی صحت توکن (Introspection Endpoint)
• پایانه‌های تفویض اختیار یا تبادل توکن سفارشی (RFC 8693 Token Exchange)

┌─────────────────────────────────────────────────────────┐
│                      مرورگر کاربر                          
│  ┌───────────────────────┐   Same-Origin POST / PUT     
│  │   برنامه تک‌صفحه‌ای   │─────────────────────────┐         
│  │         (SPA)         │                    │    
│  └───────────────────────┘                    │    
└───────────────────────────────────────────────┼─────────┘
                                                ▼
┌─────────────────────────────────────────────────────────┐
│              لایه میزبان BFF (Same-Origin)                  
│                                                         
│  - دریافت درخواست‌ها در دامنه اصلی                              
│  - مدیریت کوکی‌های فقط-سرور (HttpOnly Cookies)               
│  - حذف اصطکاک هدرهای Sec-Fetch-Site                      
└────────────────────────────┬────────────────────────────┘
                             │
                  Server-to-Server (بدون هدر مرورگر)
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│       وب‌سرویس‌های تجاری / سرویس احراز هویت (IdP)              
└─────────────────────────────────────────────────────────┘

• ارتباط مرورگر با BFF همیشه Same-Origin بوده و دچار تداخل با قوانین CSRF نمی‌شود.
• ارتباط BFF با سرور هویت یا سایر میکروسرویس‌ها به‌صورت Server-to-Server انجام می‌گیرد؛ بنابراین مرورگر در آن نقشی ندارد و هدرهای مرورگری مسبب مسدودسازی ارسال نخواهند شد.

• برخی بسترهای WebView محلی، فاقد ارسال هدر Sec-Fetch-Site هستند (که در این حالت، فریم‌ورک آن‌ها را کلاینت غیر مرورگری فرض کرده و مجاز می‌داند).
• برخی دیگر دامنه محلی را با پیشوندهایی مثل capacitor://localhost یا app:// ارسال می‌کنند که سبب ایجاد یک مقدار نامتعارف در هدر Origin و مغایرت با Host سرور می‌شود.

نکته کلیدی: برنامه‌هایی که بک‌اند .NET 11 دارند اما سرویس‌گیرنده آن‌ها اپلیکیشن‌های هیبریدی بر پایه WebView هستند، باید حتماً رفتار این کلاینت‌ها را در ارسال هدرها بررسی کرده و در صورت رد درخواست، مبدأهای داخلی وب‌ویو را در لیست دامنه‌های مجاز قرار دهند یا از پیاده‌سازی سفارشی ICsrfProtection استفاده کنند.

{
  "CrossOriginProtection": "disable"
}

// مستثنی‌سازی مسیر تبادل توکن یا فرآیندهای بازگشتی در Minimal APIs
app.MapPost("/connect/token", HandleTokenExchange)
   .DisableAntiforgery();