فراتر از اصول اولیه: چرا باید عمیق‌تر شویم؟

قبل از ورود به جزئیات، بیایید بپذیریم که اصول اولیه غیرقابل انکار هستند. استفاده از HTTPS برای رمزنگاری داده‌ها در حال انتقال، اعتبارسنجی ورودی‌ها برای جلوگیری از حملات تزریقی (Injection Attacks) و پیاده‌سازی صحیح احراز هویت و مجوزدهی، ستون‌های اصلی هر API امنی را تشکیل می‌دهند. اما مهاجمان دائماً در حال یافتن راه‌های جدید برای نفوذ هستند و یک استراتژی دفاعی چندلایه، امری ضروری است. ترفندهایی که در ادامه می‌آیند، لایه‌های دفاعی بیشتری را به برنامه شما اضافه می‌کنند.

۱. غنی‌سازی دینامیک مجوزها با IClaimsTransformation

بسیاری از سیستم‌ها از توکن‌های JWT برای انتقال اطلاعات هویتی و مجوزها (Claims) استفاده می‌کنند. معمولاً این توکن در زمان لاگین صادر می‌شود و شامل نقش‌های (Roles) کاربر در همان لحظه است. اما اگر نقش‌ها یا مجوزهای کاربر پس از صدور توکن تغییر کند چه؟ آیا باید کاربر را مجبور به لاگین مجدد کنیم؟

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

چرا کمتر شناخته شده است؟ چون اکثر آموزش‌ها بر روی صدور توکن با مجوزهای ثابت تمرکز دارند و به نحوه به‌روزرسانی دینامیک آن‌ها نمی‌پردازند.

پیاده‌سازی:

ابتدا، یک کلاس جدید برای پیاده‌سازی این رابط ایجاد کنید. در این مثال، ما از یک سرویس فرضی برای دریافت مجوزهای به‌روز کاربر از پایگاه داده استفاده می‌کنیم.

using System.Security.Claims;
using Microsoft.AspNetCore.Authentication;

public class PermissionTransformation : IClaimsTransformation
{
    private readonly IPermissionService _permissionService;

    public PermissionTransformation(IPermissionService permissionService)
    {
        _permissionService = permissionService;
    }

    public async Task TransformAsync(ClaimsPrincipal principal)
    {
        // جلوگیری از افزودن مجدد مجوزها در صورت اجرای چندباره
        if (principal.HasClaim(c => c.Type == "PermissionsRefreshed"))
        {
            return principal;
        }

        var userId = principal.FindFirstValue(ClaimTypes.NameIdentifier);
        if (string.IsNullOrEmpty(userId))
        {
            return principal;
        }

        // دریافت آخرین مجوزها از پایگاه داده
        var latestPermissions = await _permissionService.GetUserPermissionsAsync(userId);

        var claimsIdentity = new ClaimsIdentity();
        foreach (var permission in latestPermissions)
        {
            claimsIdentity.AddClaim(new Claim("permission", permission));
        }

        claimsIdentity.AddClaim(new Claim("PermissionsRefreshed", DateTime.UtcNow.Ticks.ToString()));

        principal.AddIdentity(claimsIdentity);
        return principal;
    }
}

سپس، این سرویس را در Program.cs (یا Startup.cs) ثبت کنید:

builder.Services.AddTransient();

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

۲. سخت‌گیری هدرهای HTTP برای یک لایه دفاعی اضافی

هدرهای پاسخ HTTP ابزارهای قدرتمندی برای افزایش امنیت در سمت کلاینت (مرورگر) هستند که اغلب توسط توسعه‌دهندگان API نادیده گرفته می‌شوند. از آنجایی که APIها ممکن است توسط برنامه‌های تحت وب (Single Page Applications) مصرف شوند، تنظیم صحیح این هدرها می‌تواند از حملات متداولی مانند Cross-Site Scripting (XSS) و Clickjacking جلوگیری کند.

چرا کمتر شناخته شده است؟ چون تمرکز اصلی در امنیت API معمولاً بر روی سرور است، در حالی که این هدرها یک لایه دفاعی مهم در سمت کلاینت ایجاد می‌کنند.

هدرهای کلیدی و پیاده‌سازی آن‌ها:

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

public class SecurityHeadersMiddleware
{
    private readonly RequestDelegate _next;

    public SecurityHeadersMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // جلوگیری از نمایش محتوا در یک frame یا iframe
        context.Response.Headers.Append("X-Frame-Options", "DENY");

        // جلوگیری از حدس زدن نوع محتوا توسط مرورگر
        context.Response.Headers.Append("X-Content-Type-Options", "nosniff");

        // فعال کردن فیلتر XSS داخلی مرورگر
        context.Response.Headers.Append("X-XSS-Protection", "1; mode=block");

        // تعریف یک سیاست امنیتی محتوا (CSP)
        context.Response.Headers.Append(
            "Content-Security-Policy",
            "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests;");

        // کنترل اطلاعاتی که در هدر Referer ارسال می‌شود
        context.Response.Headers.Append("Referrer-Policy", "no-referrer");

        await _next(context);
    }
}

و سپس این Middleware را در Program.cs ثبت کنید:

app.UseMiddleware();

استفاده از کتابخانه‌هایی مانند NetEscapades.AspNetCore.SecurityHeaders نیز می‌تواند این فرآیند را ساده‌تر و جامع‌تر کند.

۳. محدودسازی نرخ درخواست (Rate Limiting) هوشمند و چندلایه

محدودسازی نرخ درخواست یک تکنیک شناخته‌شده برای جلوگیری از حملات Denial-of-Service (DoS) و سوءاستفاده از API است. اما یک ترفند کمتر شناخته‌شده، پیاده‌سازی استراتژی‌های هوشمند و چندلایه برای این کار است. ASP.NET Core 7.0 به بعد، یک Middleware داخلی قدرتمند برای این منظور ارائه می‌دهد.

ترفند چیست؟ به جای یک محدودیت کلی برای همه، می‌توانید محدودیت‌ها را بر اساس هویت کاربر، آدرس IP، نقش کاربر یا حتی Tenant در یک سیستم چندمستأجره (Multi-tenant) اعمال کنید.

پیاده‌سازی پیشرفته:

در Program.cs، می‌توانید سیاست‌های مختلفی را تعریف کنید:

using System.Threading.RateLimiting;

builder.Services.AddRateLimiter(options =>
{
    // یک سیاست ثابت برای کاربران ناشناس بر اساس IP
    options.AddFixedWindowLimiter(policyName: "anonymous", opt =>
    {
        opt.PermitLimit = 100;
        opt.Window = TimeSpan.FromHours(1);
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    });

    // یک سیاست انعطاف‌پذیرتر برای کاربران احراز هویت شده بر اساس شناسه کاربری
    options.AddSlidingWindowLimiter(policyName: "authenticated", opt =>
    {
        opt.PermitLimit = 1000;
        opt.Window = TimeSpan.FromHours(1);
        opt.SegmentsPerWindow = 5; // تقسیم پنجره زمانی برای دقت بیشتر
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    });

    // یک سیاست ویژه برای یک Endpoint خاص و سنگین
    options.AddTokenBucketLimiter(policyName: "heavy-endpoint", opt =>
    {
        opt.TokenLimit = 5;
        opt.TokensPerPeriod = 2;
        opt.ReplenishmentPeriod = TimeSpan.FromMinutes(1);
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    });
});

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

[ApiController]
[Route("api/[controller]")]
public class DataController : ControllerBase
{
    // اعمال سیاست بر اساس وضعیت احراز هویت
    [HttpGet]
    [EnableRateLimiting(policyName: "anonymous")]
    public IActionResult GetPublicData() { /* ... */ }

    [HttpGet("protected")]
    [Authorize]
    [EnableRateLimiting(policyName: "authenticated")]
    public IActionResult GetProtectedData() { /* ... */ }

    [HttpPost("process")]
    [Authorize(Roles = "PremiumUser")]
    [EnableRateLimiting(policyName: "heavy-endpoint")]
    public IActionResult ProcessHeavyData() { /* ... */ }
}

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

۴. جلوگیری از حملات جعل درخواست بین سایتی (CSRF) در APIهای مبتنی بر کوکی

حملات Cross-Site Request Forgery (CSRF) معمولاً با برنامه‌های وب سنتی مرتبط دانسته می‌شوند، اما APIهایی که از احراز هویت مبتنی بر کوکی (مثلاً در کنار یک SPA که روی همان دامنه میزبانی می‌شود) استفاده می‌کنند نیز در معرض خطر هستند. ASP.NET Core مکانیزم‌های ضدجعل قدرتمندی دارد، اما فعال‌سازی صحیح آن برای APIها نیازمند توجه ویژه است.

چرا کمتر شناخته شده است؟ چون در معماری‌های مدرن که اغلب از توکن‌های Bearer استفاده می‌شود، خطر CSRF کمتر است و توسعه‌دهندگان ممکن است هنگام استفاده از کوکی برای APIها، این آسیب‌پذیری را فراموش کنند.

پیاده‌سازی:

۱. در Program.cs، سرویس ضد جعل را پیکربندی کنید تا توکن را در یک کوکی قرار دهد و از یک هدر سفارشی برای اعتبارسنجی آن استفاده کند.

builder.Services.AddAntiforgery(options =>
{
    options.HeaderName = "X-CSRF-TOKEN";
});

۲. یک Middleware ایجاد کنید تا توکن ضد جعل را برای درخواست‌های GET تولید کرده و در یک کوکی برای کلاینت ارسال کند. این کار به SPA شما اجازه می‌دهد تا توکن را بخواند و در درخواست‌های بعدی (POST, PUT, DELETE) آن را در هدر ارسال کند.

using Microsoft.AspNetCore.Antiforgery;

app.Use((context, next) =>
{
    var tokens = antiforgery.GetAndStoreTokens(context);
    context.Response.Cookies.Append("CSRF-TOKEN", tokens.RequestToken!,
        new CookieOptions { HttpOnly = false });
    return next(context);
});

۳. در سمت کلاینت (مثلاً با استفاده از Axios در جاوااسکریپت)، باید کدی بنویسید که مقدار کوکی CSRF-TOKEN را خوانده و در هدر X-CSRF-TOKEN برای تمام درخواست‌های تغییر وضعیت (state-changing) قرار دهد.

۴. در نهایت، روی اکشن‌های API خود از اتریبیوت [ValidateAntiForgeryToken] استفاده کنید تا هر درخواستی که این توکن را به درستی در هدر نداشته باشد، رد شود.

این روش، امنیت برنامه‌های مبتنی بر کوکی را به شدت افزایش می‌دهد.

نتیجه‌گیری: تفکر امنیتی به عنوان یک فرهنگ

امنیت API یک مقصد نیست، بلکه یک سفر مداوم است. تکیه بر روش‌های استاندارد اگرچه ضروری است، اما کافی نیست. ترفندهای پیشرفته‌ای مانند غنی‌سازی دینامیک مجوزها، سخت‌گیری هدرهای HTTP، محدودسازی هوشمند نرخ درخواست و محافظت در برابر CSRF در APIهای مبتنی بر کوکی، لایه‌های دفاعی حیاتی را به برنامه شما می‌افزایند. با به کارگیری این تکنیک‌های کمتر شناخته‌شده، می‌توانید یک گام جلوتر از مهاجمان باشید و از داده‌های ارزشمند کاربران خود به بهترین شکل ممکن محافظت کنید. امنیت را نه به عنوان یک چک‌لیست، بلکه به عنوان یک فرهنگ در فرآیند توسعه خود نهادینه کنید.