اعتبار جلسه محدود به دستگاه (DBSC)

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

دانیل روبری
Daniel Rubery

مقدمه

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

این راهنما برای توسعه‌دهندگانی در نظر گرفته شده است که جریان‌های احراز هویت را در برنامه‌های وب مدیریت می‌کنند. این راهنما نحوه‌ی کار DBSC و نحوه‌ی ادغام آن در سایت شما را توضیح می‌دهد.

نحوه کار DBSC

در سطح بالا، DBSC یک جفت کلید رمزنگاری مرتبط با دستگاه کاربر را معرفی می‌کند. کروم این جفت کلید را در هنگام ورود به سیستم تولید می‌کند و در صورت وجود، کلید خصوصی را در سخت‌افزار امن، مانند ماژول پلتفرم قابل اعتماد (TPM) ، ذخیره می‌کند. جلسات از کوکی‌های کوتاه مدت استفاده می‌کنند. هنگامی که یکی از این کوکی‌ها منقضی می‌شود، کروم قبل از به‌روزرسانی آنها، مالکیت کلید خصوصی را اثبات می‌کند. این فرآیند، تداوم جلسه را به دستگاه اصلی مرتبط می‌کند.

اگر دستگاه کاربر از ذخیره‌سازی امن کلید پشتیبانی نکند، DBSC بدون ایجاد اختلال در جریان احراز هویت، به رفتار استاندارد خود بازمی‌گردد.

مرور کلی پیاده‌سازی

برای ادغام DBSC در برنامه خود، باید تغییرات زیر را اعمال کنید:

  • جریان ورود خود را طوری تغییر دهید که شامل یک سربرگ Secure-Session-Registration باشد.
  • یک نقطه پایانی ثبت جلسه اضافه کنید که:
    • یک کلید عمومی را به جلسه کاربر مرتبط می‌کند.
    • پیکربندی جلسه را ارائه می‌دهد.
    • انتقال به کوکی‌های کوتاه‌مدت.
  • یک نقطه پایانی refresh برای مدیریت تمدید کوکی و اعتبارسنجی مالکیت کلید اضافه کنید.

اکثر نقاط پایانی موجود شما نیازی به هیچ تغییری ندارند. DBSC به گونه‌ای طراحی شده است که افزایشی و غیرمخرب باشد.

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

مراحل اجرا

این بخش، تغییرات لازم در سیستم احراز هویت شما، از جمله نحوه تغییر جریان ورود به سیستم، مدیریت ثبت نام جلسه و مدیریت به‌روزرسانی‌های کوتاه‌مدت کوکی‌ها را بررسی می‌کند. هر مرحله به گونه‌ای طراحی شده است که به راحتی با زیرساخت موجود شما ادغام شود.

مراحل پیاده‌سازی از جریان رایجی پیروی می‌کنند که یک کاربر وارد شده هنگام فعال بودن DBSC تجربه می‌کند: ثبت نام در هنگام ورود به سیستم، و به دنبال آن به‌روزرسانی‌های منظم و کوتاه مدت کوکی. شما می‌توانید هر مرحله را بسته به سطح حساسیت جلسه برنامه خود، به طور مستقل آزمایش و پیاده‌سازی کنید.

نموداری که جریان DBSC را نشان می‌دهد

۱. تغییر جریان ورود به سیستم

پس از ورود کاربر، با یک کوکی با طول عمر بالا و یک هدر Secure-Session-Registration پاسخ دهید. برای مثال:

هدر پاسخ HTTP زیر پس از ثبت موفقیت‌آمیز جلسه بازگردانده می‌شود:

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

اگر دستگاه از ذخیره‌سازی امن کلید پشتیبانی کند، کروم با یک کلید عمومی در یک JSON Web Token (JWT) با نقطه پایانی /StartSession تماس می‌گیرد.

auth_cookie در این مثال نشان دهنده توکن جلسه شماست. می‌توانید این کوکی را هر نامی که دوست دارید بگذارید، البته تا زمانی که با فیلد name در پیکربندی جلسه شما مطابقت داشته باشد و به طور مداوم در سراسر برنامه شما استفاده شود.

۲. پیاده‌سازی نقطه پایانی ثبت جلسه

در /StartSession ، سرور شما باید:

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

در مثال زیر، کوکی کوتاه‌مدت طوری پیکربندی شده است که پس از 10 دقیقه منقضی شود:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

۳. پیاده‌سازی نقطه پایانی refresh

وقتی کوکی کوتاه‌مدت منقضی می‌شود، کروم یک جریان به‌روزرسانی را برای اثبات مالکیت کلید خصوصی آغاز می‌کند. این فرآیند شامل اقدامات هماهنگ‌شده توسط کروم و سرور شما است:

  1. کروم درخواست کاربر را به برنامه شما موکول می‌کند و یک درخواست به‌روزرسانی به /RefreshEndpoint ارسال می‌کند:

    POST /RefreshEndpoint HTTP/1.1
    Sec-Secure-Session-Id: session_id
    
  2. سرور شما با یک چالش پاسخ می‌دهد:

    HTTP/1.1 403 Forbidden
    Secure-Session-Challenge: "challenge_value"
    
  3. کروم با استفاده از کلید خصوصی ذخیره‌شده، چالش را امضا می‌کند و درخواست را دوباره امتحان می‌کند:

    POST /RefreshEndpoint HTTP/1.1
    Sec-Secure-Session-Id: session_id
    Secure-Session-Response: <JWT proof>
    
  4. سرور شما مدرک امضا شده را اعتبارسنجی می‌کند و یک کوکی کوتاه‌مدت به‌روزرسانی‌شده صادر می‌کند:

    HTTP/1.1 200 OK
    
    Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
    
  5. کروم کوکی به‌روزرسانی‌شده را دریافت می‌کند و درخواست اولیه‌ی به تعویق افتاده را از سر می‌گیرد.

الگوی ادغام جایگزین

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

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

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

هشدارها و رفتارهای جایگزین

کروم ممکن است در سناریوهای زیر عملیات DBSC را نادیده بگیرد و درخواست‌ها را بدون کوکی کوتاه‌مدت مدیریت‌شده توسط DBSC ارسال کند:

  • به دلیل خطاهای شبکه یا مشکلات سرور، نقطه پایانی refresh قابل دسترسی نیست.
  • TPM مشغول است یا با خطاهای امضا مواجه می‌شود. از آنجا که TPM در فرآیندهای سیستم به اشتراک گذاشته شده است، به‌روزرسانی‌های بیش از حد ممکن است از محدودیت‌های سرعت آن فراتر رود.
  • کوکی کوتاه‌مدت مدیریت‌شده توسط DBSC یک کوکی شخص ثالث است و کاربر کوکی‌های شخص ثالث را در تنظیمات مرورگر خود مسدود کرده است.

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

خلاصه

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

برای اطلاعات بیشتر، به مشخصات DBSC مراجعه کنید.