‫امنیت نشست‌ها در عصر جدید وب: بررسی قابلیت آزمایشی DBSC در ASP.NET Core 11x

• احراز هویت اولیه همچنان با همان منطق مرسوم (فرم لاگین، OAuth/OIDC و...) انجام می‌شود.
• فعال‌سازی قابلیت تنها وابسته به ارسال یک هدر اختیاری از سمت سرور است؛ مرورگرهایی که پروتکل را نمی‌شناسند، به‌سادگی هدر مربوطه را نادیده گرفته و با همان کوکی سنتی ادامه می‌دهند. بنابراین، اضافه شدن DBSC هیچ‌گونه تغییر مخربی (Breaking Change) در رفتار سیستم ایجاد نمی‌کند.

[Browser / Client]                                             [Server]
        |                                                          |
        | ----- (1) Initial Login Request -----------------------> |
        | <---- (2) Set-Cookie + Secure-Session-Registration ----- |
        |                                                          |
        | ----- (3) POST /dbsc/registration (JWT + Cookie) ------> |
        | <---- (4) 200 OK + JSON Instructions + Short-Lived Cookie|
        |                                                          |
        |  ... [Subsequent normal requests using Short-Lived Cookie] ...
        |                                                          |
        | ----- (5) POST /dbsc/refresh (Sec-Secure-Session-Id) --> |
        | <---- (6) 403 Forbidden + Secure-Session-Challenge ----- |
        |                                                          |
        | ----- (7) POST /dbsc/refresh (Signed JWT Challenge) ---> |
        | <---- (8) 200 OK + New Short-Lived Cookie -------------- |

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/dbsc/registration"; challenge="4a96e2cab06e76e2366b5e802bfcbabfe81e52c81abfcc71afc97010157ae9bd"
Set-Cookie: MyAuthCookie=CfDJ8Apn9==; Path=/; SameSite=Lax; HttpOnly

• (ES256 RS256): الگوریتم‌های رمزنگاری امضایی که سرور برای مرورگر مجاز دانسته است (مانند ECDSA P-256 یا RSA).
• path: اندپوینتی که مرورگر باید برای ثبت نشست به آن درخواست بفرستد.
• challenge: یک رشته تصادفی (Nonce/Challenge) که مرورگر ملزم به امضای آن جهت اثبات تصاحب کلید است.

POST /dbsc/registration HTTP/1.1
Cookie: MyAuthCookie=CfDJ8Apn9==
Secure-Session-Response: eyJhbGciOiJFUzI1NiIsImp3ayI6eyJ...

// Header
{
  "alg": "ES256",
  "jwk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "lHN3ar-wlVSSAdy8OJXqxhHwBiuur2rTlmbxcgim9_o",
    "y": "zf_y79p8rpb7ztnQGZ25xPX_Lq_r7o1Ch9jvne70tJ4"
  },
  "typ": "dbsc+jwt"
}

// Payload
{
  "jti": "4a96e2cab06e76e2366b5e802bfcbabfe81e52c81abfcc71afc97010157ae9bd"
}

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: MyDbscCookie=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=300

{
  "session_identifier": "199d6f60681",
  "refresh_url": "/dbsc/refresh",
  "scope": {
    "origin": "https://example.com",
    "include_site": false
  },
  "credentials": [
    {
      "type": "cookie",
      "name": "MyDbscCookie",
      "attributes": "Path=/; Secure; HttpOnly; SameSite=Lax"
    }
  ]
}

• session_identifier: شناسه منحصربه‌فرد نشست DBSC که مرورگر باید در هر بار تمدید آن را ارائه دهد.
• refresh_url: آدرسی که مرورگر برای دریافت کوکی جدید کوتاه‌مدت باید فراخوانی کند.
• credentials: کوکی مورد نظر و مشخصات آن جهت اعمال در تراکنش‌ها.

POST /dbsc/refresh HTTP/1.1
Sec-Secure-Session-Id: 199d6f60681

HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "4524d32ab2b9"; id="199d6f60681"

POST /dbsc/refresh HTTP/1.1
Sec-Secure-Session-Id: 199d6f60681
Secure-Session-Response: <Signed-JWT-Containing-New-Challenge>

تعویق درخواست‌ها (Request Deferral): اگر عمر کوکی منقضی شده باشد و کاربر روی لینکی کلیک کند، مرورگر درخواست کاربر را در صف نگه می‌دارد (Defer می‌کند)، فرآیند پس‌زمینه تمدید را کامل کرده و سپس درخواست کاربر را با کوکی جدید ارسال می‌کند؛ بدون اینکه کاربر با لاگین مجدد یا خطای احراز هویت مواجه شود.

• افزونه‌های مرورگر و Ad-Blockerها: با توجه به غیرمعمول بودن رفتارهایی مانند فراخوانی‌های پشت‌صحنه POST و مسیرهای خاص، برخی ابزارهای مسدودساز تبلیغات ممکن است به اشتباه درخواست‌های تمدید نشست یا ثبت نشست را مسدود کنند.
• پیچیدگی پیاده‌سازی خام (Manual Implementation): مدیریت مواردی چون همگام‌سازی چالش‌ها، اعتبارسنجی JWT، مدیریت Race Conditionها در تمدید هم‌زمان، و تعامل با خطاهای شبکه بسیار حساس است. بنابراین توصیه می‌شود توسعه‌دهندگان به جای نوشتن دستی این فرآیند، از کتابخانه‌های رسمی مانند پکیج ارائه‌شده در ASP.NET Core استفاده کنند.

• کوکی لاگین اولیه (Original Auth Cookie): کوکی استاندارد صادرشده در هنگام فراخوانی HttpContext.SignInAsync که کلاینت را به فرآیند ثبت DBSC هدایت می‌کند.
• کوکی نشست کوتاه‌مدت (Short-Lived Session Cookie): کوکی سبک‌وزنی که برای احراز هویت درخواست‌های عادی وب استفاده شده و طول عمر آن با ShortLivedCookieExpiration (مثلاً ۱۰ دقیقه) محدود می‌شود.
• کوکی تمدید با دامنه مسیر خاص (Path-Scoped Refresh Cookie): کوکی حساس و رمزنگاری‌شده‌ای که مرورگر تنها در زمان فراخوانی اندپوینت /.well-known/dbsc/refresh ارسال می‌کند.

• ذخیره کلید عمومی سمت کلاینت: در زمان ثبت نشست، مقدار کلید عمومی کلاینت (DbscPublicKeyJwk) به همراه شناسه نشست در ویژگی‌های احراز هویت (AuthenticationProperties) قرار داده شده و داخل کوکی تمدید (Refresh Cookie) مهروموم (Encrypt) می‌شود:

refreshProperties.Items["DbscPublicKeyJwk"] = jwtResult.PublicKeyJwk;
refreshProperties.Items["DbscSessionId"] = sessionId;
await Context.SignInAsync(Options.RefreshScheme, principal, refreshProperties);

• تأیید اصالت بدون نگهداری نانس (Stateless Nonces): سرور نانس‌های صادرشده در challenge را در حافظه ذخیره نمی‌کند. در عوض، هر چالش به صورت یک توکن رمزنگاری‌شده با Data Protection تولید می‌شود که حاوی هویت کاربر، شناسه نشست و تاریخ انقضا است. بررسی چالش صرفاً با رمزگشایی مجدد و راستی‌آزمایی فیلدهای درون آن انجام می‌گیرد.
• جداسازی اهداف رمزنگاری (Purpose Isolation): چالش‌های ثبت اولیه (Registration) و تمدید (Refresh) از برچسب‌های Data Protection Purpose کاملاً مجزا استفاده می‌کنند؛ در نتیجه چالش صادرشده در یکی از جریان‌ها به هیچ وجه در جریان دیگر رمزگشایی و پذیرفته نمی‌شود.
• مقیاس‌پذیری افقی (Horizontal Scalability): تمام سرورهای پشت لودبلانسر، در صورت اشتراک کلیدهای Data Protection، بدون نیاز به کش مشترک یا چسبندگی نشست (Sticky Sessions) قادر به تمدید کوکی‌ها هستند.

• کاهش طول عمر: پنجره سوءاستفاده مهاجم در صورت سرقت کوکی کوتاه‌مدت را کوچک‌تر می‌کند.
• سربار تراشه TPM: ماژول‌های سخت‌افزاری TPM سیستم‌های اشتراکی در سطح سیستم‌عامل هستند و برای جلوگیری از حملات منع سرویس محلی، نرخ عملیات رمزنگاری محدودی (Rate-Limiting) دارند.
• هزینه فرکانس تمدید: انتخاب مقادیر بسیار کوتاه (مانند ۱ یا ۲ دقیقه) موجب افزایش چرخه‌های امضای نامتقارن، افزایش بار شبکه به دلیل فرآیند دو مرحله‌ای 403 Forbidden و ایجاد تأخیر در تجربه کاربری می‌شود. بازه پیش‌فرض ۱۰ دقیقه تعادلی بهینه میان امنیت و بار عملیاتی سخت‌افزار است.

• چالش ابطال نشست (Session Revocation): از آنجا که جدول وضعیت متمرکزی در سرور وجود ندارد، ابطال فوری نشست از طریق سرور میسر نیست؛ در صورت نیاز به لغو اضطراری، سامانه باید لیست سیاه نشانه‌ها را تا موعد تمدید بعدی بررسی کند.
• حملات مبتنی بر دسترسی هم‌زمان (Malware Present at Registration): اگر پیش از ثبت‌نام DBSC، بدافزار روی ماشین قربانی حضور فعال داشته باشد، می‌تواند در حین نشست دستور امضا را به TPM ارسال کرده یا ترافیک رجیستریشن اولیه را شنود کند. DBSC دسترسی سرقت‌شده را محدود به همان دستگاه کرده و مانع استفاده مهاجم در ماشین‌های ثانویه می‌شود، اما جایگزین راهکارهای دفاع ضد بدافزار محلی نیست.
• تفاوت تمدید با ثبت در ساختار JWT: توکن JWT ارسالی در درخواست تمدید برخلاف ثبت اولیه، فاقد شیء jwk در هدر خود است، چرا که سرور کلید عمومی را از درون کوکیِ تمدید بازگشایی می‌کند.

// ثبت پیش‌فرض Identity
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

// متصل کردن لایه DBSC به شمای کوکی پیش‌فرض Identity
new AuthenticationBuilder(builder.Services)
    .AddDeviceBoundSession(sourceScheme: IdentityConstants.ApplicationScheme, options =>
    {
        options.ShortLivedCookieExpiration = TimeSpan.FromMinutes(10);
    });

[ Incoming Request ]
        │
        ▼
[ PolicySchemeHandler: Identity.Application.Dbsc ]
        │
        ├── آیا کوکی کوتاه‌مدت نشست در هدر موجود است؟
        │         ├── بله ──► مسیریابی به [ Identity.Application.Dbsc.Session ]
        │         └── خیر  ──► عقب‌نشینی به [ Identity.Application ] (Source Scheme)
        │
[ Refresh Scheme: Identity.Application.Dbsc.Refresh ] (محدود به مسیر /.well-known/dbsc)

• طرح کوکی نشست (Identity.Application.Dbsc.Session): این طرح مسئول مدیریت کوکی احراز هویت اصلی با طول عمر کوتاه است (با پیشوند نام .AspNetCore.Identity.Application.Dbsc.Session).
• طرح کوکی تمدید (Identity.Application.Dbsc.Refresh): کوکی این طرح به‌طور سخت‌گیرانه به مسیر /.well-known/dbsc محدود (Path-scoped) شده و تنها در درخواست‌های تمدید خوانده می‌شود.

• برای جلوگیری از شکست نشست در زمان لاگین کاربرانی که هنوز نشست DBSC را نهایی نکرده‌اند یا مرورگرهای فاقد پشتیبانی، یک PolicyScheme با عنوان {sourceScheme}.Dbsc تزریق می‌شود.
• ویژگی ForwardDefaultSelector این طرح، وجود کوکی نشست کوتاه‌مدت را در درخواست ورودی جستجو می‌کند؛ در صورت یافتن نام کوکی، اعتبارسنجی را به طرح Session واگذار می‌کند و در غیر این صورت، درخواست را به طرح اولیه (Source Scheme) ارجاع می‌دهد تا خروج ناخواسته (Logout) رخ ندهد.

• PostConfigureDeviceBoundSessionCookieOptions: با زنجیره‌سازی متد OnSigningIn، فراخوانی DeviceBoundSessionRegistrationHeader.Emit() را انجام می‌دهد تا هدر Secure-Session-Registration همراه با پاسخ لاگین ارسال شود. همچنین در رویداد خروج، حذف هر سه کوکی را برنامه‌ریزی می‌کند.
• PostConfigureDeviceBoundSessionDerivedCookieOptions: پارامترهای پایه‌ای امنیتی نظیر HttpOnly، Secure، SameSite و دامنه را از کوکی اصلی خوانده و روی کوکی‌های نشست و تمدید اعمال می‌نماید.
• PostConfigureDeviceBoundSessionAuthenticationOptions: نام شمای پیش‌فرض سیستم احراز هویت را به شمای سیاست‌گذاری (PolicyScheme) جدید هدایت می‌کند.

• کروم تبادلات اندپوینت‌های ثبت (/registration) و تمدید (/refresh) را در تب اصلی Network نمایش نمی‌دهد.
• جهت ارزیابی فعال بودن پروتکل، باید به تب اختصاصی Device Bound Sessions در ابزار توسعه مرورگر مراجعه کرد؛ این بخش وضعیت نشست و وضعیت تصمیم‌گیری برای تعویق درخواست کاربر (Deferral Decision) را مشخص می‌کند.

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 POST https://localhost:7029/.well-known/dbsc/registration - - 0
info: Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler[10]
      AuthenticationScheme: Identity.Application.Dbsc.Refresh signed in.
info: Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler[10]
      AuthenticationScheme: Identity.Application.Dbsc.Session signed in.
info: Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler[11]
      AuthenticationScheme: Identity.Application signed out.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/2 POST https://localhost:7029/.well-known/dbsc/registration - 200 - application/json

• ورود موفق به طرح Refresh
• ورود موفق به طرح Session
• خروج و ابطال طرح بلندمدت پیشین (Identity.Application signed out)

• شناسه دستگاه (DeviceId): یک توکن یا رشته متنی حامل است. در صورتی که مهاجم آن را به همراه کوکی سرقت کند، می‌تواند همان مقدار را بازپخش (Replay) نماید.
• اثر انگشت مرورگر (Browser Fingerprinting): متکی بر ویژگی‌های محیطی (رزولوشن، فونت‌ها، کارت گرافیک و...) است. این روش مبتنی بر حدس و شباهت ظاهری است، دقت قطعی ندارد و با تغییر تنظیمات یا به‌روزرسانی سیستم مخدوش می‌شود.
• کلید دستگاه (Device Key): متکی بر رمزنگاری نامتقارن است. کلاینت دارا بودن کلید خصوصی را بدون ارسال آن و صرفاً با امضای یک چالش به اثبات می‌رساند. سرور به جای اعتماد به یک مقدار ارسالی، عملیات ریاضیاتی صحت امضا را ارزیابی می‌کند.

// تولید جفت‌کلید ECDSA روی منحنی استاندارد P-256
const keyPair = await window.crypto.subtle.generateKey(
    {
        name: "ECDSA",
        namedCurve: "P-256"
    },
    false, // extractable: کلید خصوصی قابل اکسپورت نیست
    ["sign", "verify"]
);

• مفهوم extractable = false: مرورگر دسترسی توابعی مانند exportKey را به کلید خصوصی مسدود می‌کند؛ در نتیجه کدهای جاوااسکریپت عادی نمی‌توانند بایت‌های خام کلید را استخراج کنند.
• محدودیت امنیتی در برابر XSS: تنظیم extractable: false مانع از سرقت خود کلید می‌شود، اما اگر برنامه‌ دچار آسیب‌پذیری Cross-Site Scripting (XSS) باشد، کد مخرب تزریق‌شده همچنان می‌تواند با فراخوانی متد crypto.subtle.sign() در همان کانتکست مرورگر، پیام‌های دلخواه خود را توسط کلید قربانی امضا کند. بنابراین پیاده‌سازی لایه‌های دفاع در عمق مانند CSP و بهداشت کد کماکان الزامی است.

• فرمت خام (IEEE P1363): یک اتصال ساده از دو پارامتر r و s به‌صورت فیلدهای ثابت (r || s). این فرمت پیش‌فرض خروجی متد crypto.subtle.sign در مرورگرها است (برای منحنی P-256 طول آن دقیقا ۶۴ بایت است).
• فرمت ASN.1/DER (RFC 3279): ساختار ساخت‌یافته حاوی متادیتا که اغلب در پلتفرم‌های رمزنگاری کلاسیک و گواهی‌های X.509 استفاده می‌شود.

using System.Security.Cryptography;
using System.Text;

public class SignatureVerificationService
{
    public bool VerifyClientSignature(string base64PublicKey, string rawMessage, string base64Signature)
    {
        byte[] publicKeyBytes = Convert.FromBase64String(base64PublicKey);
        byte[] dataBytes = Encoding.UTF8.GetBytes(rawMessage);
        byte[] signatureBytes = Convert.FromBase64String(base64Signature);

        using var ecdsa = ECDsa.Create();
        
        // ایمپورت کلید عمومی ارسالی از کلاینت (فرمت استاندارد SubjectPublicKeyInfo / SPKI)
        ecdsa.ImportSubjectPublicKeyInfo(publicKeyBytes, out _);

        // تلاش برای اعتبارسنجی با پشتیبانی از هر دو فرمت IEEE P1363 و ASN.1 DER
        return TryVerify(ecdsa, dataBytes, signatureBytes, DSASignatureFormat.IeeeP1363FixedFieldConcatenation) ||
               TryVerify(ecdsa, dataBytes, signatureBytes, DSASignatureFormat.Rfc3279DerSequence);
    }

    private static bool TryVerify(ECDsa ecdsa, byte[] data, byte[] signature, DSASignatureFormat format)
    {
        try
        {
            return ecdsa.VerifyData(data, signature, HashAlgorithmName.SHA256, format);
        }
        catch (CryptographicException)
        {
            return false;
        }
    }
}

• مکانیزم Nonce یک‌بارمصرف: سرور در هر درخواست یا نشست، یک مقدار تصادفی موقت (Nonce) صادر می‌کند و بلافاصله پس از بررسی، آن را باطل می‌سازد.
• برچسب زمانی (Timestamp): بازه زمانی مشخصی (مثلاً حداکثر ۳۰ ثانیه اختلاف ساعت) برای پذیرش امضا تعیین می‌شود.
• پوشش کامل عناصر درخواست (Canonical Request): رشته‌ای که برای تولید امضا به crypto.subtle.sign داده می‌شود، باید ترکیبی هش‌شده از مشخصات کلیدی درخواست باشد: DataToSign = HttpMethod + Path + Nonce + Timestamp + SHA256(RequestBody)
• این رویکرد تضمین می‌کند که هدرها، متد، مسیر و بدنه ارسالی در حین انتقال قابل دستکاری (Tampering) توسط واسطه‌ها نخواهند بود.