Device Bound Session Credentials (DBSC) با افزودن امنیت جلسه سخت افزاری، احراز هویت را تقویت می کند.
مقدمه
بسیاری از وبسایتها برای احراز هویت کاربر به کوکیهای با عمر طولانی متکی هستند، اما این کوکیها در معرض ربودن جلسه هستند. Device Bound Session Credentials (DBSC) لایه ای از امنیت سخت افزاری را برای کاهش این خطر اضافه می کند و اطمینان حاصل می کند که جلسات به دستگاه های خاصی متصل می شوند.
این راهنما برای توسعه دهندگانی است که جریان های احراز هویت را در برنامه های کاربردی وب حفظ می کنند. این توضیح می دهد که چگونه DBSC کار می کند و چگونه آن را در سایت خود ادغام کنید.
نحوه عملکرد DBSC
در سطح بالایی، DBSC یک جفت کلید رمزنگاری مرتبط با دستگاه کاربر را معرفی می کند. Chrome این جفت کلید را در حین ورود به سیستم ایجاد میکند و کلید خصوصی را در سختافزار امن، مانند ماژول پلتفرم مورد اعتماد (TPM) در صورت وجود ذخیره میکند. در جلسات از کوکی های کوتاه مدت استفاده می شود. وقتی یکی از این کوکیها منقضی میشود، Chrome قبل از بازخوانی، داشتن کلید خصوصی را ثابت میکند. این فرآیند تداوم جلسه را به دستگاه اصلی پیوند می دهد.
اگر دستگاه کاربر از ذخیرهسازی کلید ایمن پشتیبانی نمیکند، DBSC به آرامی به رفتار استاندارد بازمیگردد، بدون اینکه جریان احراز هویت قطع شود.
مروری بر پیاده سازی
برای ادغام DBSC در برنامه خود، باید تغییرات زیر را اعمال کنید:
- جریان ورود به سیستم خود را طوری تغییر دهید که یک سرصفحه
Sec-Session-Registration
شامل شود. - یک نقطه پایانی ثبت جلسه اضافه کنید که:
- یک کلید عمومی را با جلسه کاربر مرتبط می کند.
- پیکربندی جلسه را ارائه می دهد.
- انتقال به کوکی های کوتاه مدت.
- برای رسیدگی به تمدید کوکی و تأیید اعتبار در اختیار داشتن کلید، یک نقطه پایان تازهسازی اضافه کنید.
اکثر نقاط پایانی موجود شما نیازی به تغییر ندارند. DBSC به گونه ای طراحی شده است که افزودنی و بدون اختلال باشد.
هنگامی که یک کوکی کوتاه مدت لازم وجود ندارد یا منقضی شده است، Chrome درخواست را موقتاً متوقف می کند و سعی می کند کوکی را بازخوانی کند. این به برنامه شما امکان میدهد از بررسیهای کوکی جلسه معمول خود استفاده کند تا تأیید کند کاربر وارد شده است. از آنجایی که این با جریانهای احراز هویت معمولی مطابقت دارد، DBSC با حداقل تغییرات در منطق ورود به سیستم شما کار میکند.
مراحل پیاده سازی
این بخش تغییرات لازم را در سیستم احراز هویت شما، از جمله نحوه تغییر جریان ورود به سیستم، مدیریت ثبتنام جلسه و مدیریت بازخوانیهای کوتاه مدت کوکی را بررسی میکند. هر مرحله برای ادغام هموار با زیرساخت های موجود شما طراحی شده است.
مراحل پیادهسازی از جریان رایجی پیروی میکنند که یک کاربر وارد سیستم شده هنگام فعال بودن DBSC تجربه میکند: ثبت نام در ورود به سیستم، به دنبال آن بهروزرسانیهای معمولی کوکی کوتاه مدت. بسته به سطح حساسیت جلسه برنامه خود، می توانید هر مرحله را به طور مستقل آزمایش و اجرا کنید.
1. جریان ورود به سیستم را تغییر دهید
پس از ورود کاربر، با یک کوکی طولانی مدت و یک هدر Sec-Session-Registration
پاسخ دهید. به عنوان مثال:
هدر پاسخ HTTP زیر پس از ثبت موفقیت آمیز جلسه برگردانده می شود:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
اگر دستگاه از ذخیرهسازی کلید ایمن پشتیبانی میکند، Chrome با نقطه پایانی /StartSession
با یک کلید عمومی در JSON Web Token (JWT) تماس میگیرد.
auth_cookie
در این مثال نشان دهنده نشانه جلسه شما است. تا زمانی که با فیلد name
در پیکربندی جلسه شما مطابقت داشته باشد و به طور مداوم در سراسر برنامه شما استفاده شود، میتوانید نام این کوکی را هر چه دوست دارید نامگذاری کنید.
2. نقطه پایانی ثبت جلسه را پیاده سازی کنید
در /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"
}]
}
3. نقطه پایانی refresh را پیاده سازی کنید
وقتی کوکی کوتاه مدت منقضی میشود، Chrome یک جریان تازهسازی را برای اثبات داشتن کلید خصوصی آغاز میکند. این فرآیند شامل اقدامات هماهنگ شده توسط Chrome و سرور شما است:
Chrome درخواست کاربر را به برنامه شما موکول می کند و یک درخواست تجدید به
/RefreshEndpoint
ارسال می کند:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id
سرور شما با یک چالش پاسخ می دهد:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"
Chrome چالش را با استفاده از کلید خصوصی ذخیره شده امضا می کند و درخواست را دوباره امتحان می کند:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>
سرور شما مدرک امضا شده را تأیید می کند و یک کوکی کوتاه مدت تازه سازی شده صادر می کند:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
Chrome کوکی تازهسازیشده را دریافت میکند و درخواست معوق اصلی را از سر میگیرد.
الگوی ادغام جایگزین
برای بهبود انعطاف پذیری، سایت ها می توانند یک کوکی دوم غیر DBSC را در کنار کوکی کوتاه مدت اضافه کنند. این کوکی با عمر طولانی فقط برای صدور توکن های کوتاه مدت جدید استفاده می شود و به تمایز بین درخواست های واقعاً احراز هویت نشده و خرابی های موقت DBSC کمک می کند.
- کوکی طولانی مدت حتی اگر DBSC از کار بیفتد باقی می ماند.
- کوکی کوتاه مدت با استفاده از DBSC به روز می شود و برای عملیات حساس مورد نیاز است.
این الگو به سایت ها کنترل بیشتری بر نحوه رسیدگی به موارد لبه می دهد.
هشدارها و رفتار برگشتی
Chrome ممکن است عملیات DBSC را رد کند و بدون کوکی کوتاه مدت مدیریت شده توسط DBSC در سناریوهای زیر درخواست ارسال کند:
- به دلیل خطاهای شبکه یا مشکلات سرور، نقطه پایانی تازهسازی قابل دسترسی نیست.
- TPM مشغول است یا با خطاهای امضا مواجه می شود. از آنجا که TPM در بین فرآیندهای سیستم به اشتراک گذاشته می شود، به روز رسانی بیش از حد ممکن است از محدودیت های نرخ آن فراتر رود.
- کوکی کوتاه مدت مدیریت شده توسط DBSC یک کوکی شخص ثالث است و کاربر کوکی های شخص ثالث را در تنظیمات مرورگر خود مسدود کرده است.
در این شرایط، اگر کوکی هنوز وجود داشته باشد، کروم به استفاده از کوکی طولانی مدت بازمی گردد. این بازگشت تنها زمانی کار میکند که پیادهسازی شما شامل یک کوکی با عمر طولانی و یک کوکی کوتاه مدت باشد. اگر نه، Chrome درخواست را بدون کوکی ارسال می کند.
خلاصه
Device Bound Session Credentials امنیت جلسه را با حداقل تغییرات در برنامه شما بهبود می بخشد. آنها با گره زدن جلسات به دستگاه های خاص، محافظت قوی تری در برابر ربودن جلسه ارائه می کنند. اکثر کاربران بدون هیچ گونه اختلالی سود میبرند و DBSC به خوبی از سختافزار پشتیبانینشده عقب میافتد.
برای اطلاعات بیشتر، به مشخصات DBSC مراجعه کنید.
،Device Bound Session Credentials (DBSC) با افزودن امنیت جلسه سخت افزاری، احراز هویت را تقویت می کند.
مقدمه
بسیاری از وبسایتها برای احراز هویت کاربر به کوکیهای با عمر طولانی متکی هستند، اما این کوکیها در معرض ربودن جلسه هستند. Device Bound Session Credentials (DBSC) لایه ای از امنیت سخت افزاری را برای کاهش این خطر اضافه می کند و اطمینان حاصل می کند که جلسات به دستگاه های خاصی متصل می شوند.
این راهنما برای توسعه دهندگانی است که جریان های احراز هویت را در برنامه های کاربردی وب حفظ می کنند. این توضیح می دهد که چگونه DBSC کار می کند و چگونه آن را در سایت خود ادغام کنید.
نحوه عملکرد DBSC
در سطح بالایی، DBSC یک جفت کلید رمزنگاری مرتبط با دستگاه کاربر را معرفی می کند. Chrome این جفت کلید را در حین ورود به سیستم ایجاد میکند و کلید خصوصی را در سختافزار امن، مانند ماژول پلتفرم مورد اعتماد (TPM) در صورت وجود ذخیره میکند. در جلسات از کوکی های کوتاه مدت استفاده می شود. وقتی یکی از این کوکیها منقضی میشود، Chrome قبل از بازخوانی، داشتن کلید خصوصی را ثابت میکند. این فرآیند تداوم جلسه را به دستگاه اصلی پیوند می دهد.
اگر دستگاه کاربر از ذخیرهسازی کلید ایمن پشتیبانی نمیکند، DBSC به آرامی به رفتار استاندارد بازمیگردد، بدون اینکه جریان احراز هویت قطع شود.
مروری بر پیاده سازی
برای ادغام DBSC در برنامه خود، باید تغییرات زیر را اعمال کنید:
- جریان ورود به سیستم خود را طوری تغییر دهید که یک سرصفحه
Sec-Session-Registration
شامل شود. - یک نقطه پایانی ثبت جلسه اضافه کنید که:
- یک کلید عمومی را با جلسه کاربر مرتبط می کند.
- پیکربندی جلسه را ارائه می دهد.
- انتقال به کوکی های کوتاه مدت.
- برای رسیدگی به تمدید کوکی و تأیید اعتبار در اختیار داشتن کلید، یک نقطه پایان تازهسازی اضافه کنید.
اکثر نقاط پایانی موجود شما نیازی به تغییر ندارند. DBSC به گونه ای طراحی شده است که افزودنی و بدون اختلال باشد.
هنگامی که یک کوکی کوتاه مدت لازم وجود ندارد یا منقضی شده است، Chrome درخواست را موقتاً متوقف می کند و سعی می کند کوکی را بازخوانی کند. این به برنامه شما امکان میدهد از بررسیهای کوکی جلسه معمول خود استفاده کند تا تأیید کند کاربر وارد شده است. از آنجایی که این با جریانهای احراز هویت معمولی مطابقت دارد، DBSC با حداقل تغییرات در منطق ورود به سیستم شما کار میکند.
مراحل پیاده سازی
این بخش تغییرات لازم را در سیستم احراز هویت شما، از جمله نحوه تغییر جریان ورود به سیستم، مدیریت ثبتنام جلسه و مدیریت بازخوانیهای کوتاه مدت کوکی را بررسی میکند. هر مرحله برای ادغام هموار با زیرساخت های موجود شما طراحی شده است.
مراحل پیادهسازی از جریان رایجی پیروی میکنند که یک کاربر وارد سیستم شده هنگام فعال بودن DBSC تجربه میکند: ثبت نام در ورود به سیستم، به دنبال آن بهروزرسانیهای معمولی کوکی کوتاه مدت. بسته به سطح حساسیت جلسه برنامه خود، می توانید هر مرحله را به طور مستقل آزمایش و اجرا کنید.
1. جریان ورود به سیستم را تغییر دهید
پس از ورود کاربر، با یک کوکی طولانی مدت و یک هدر Sec-Session-Registration
پاسخ دهید. به عنوان مثال:
هدر پاسخ HTTP زیر پس از ثبت موفقیت آمیز جلسه برگردانده می شود:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
اگر دستگاه از ذخیرهسازی کلید ایمن پشتیبانی میکند، Chrome با نقطه پایانی /StartSession
با یک کلید عمومی در JSON Web Token (JWT) تماس میگیرد.
auth_cookie
در این مثال نشان دهنده نشانه جلسه شما است. تا زمانی که با فیلد name
در پیکربندی جلسه شما مطابقت داشته باشد و به طور مداوم در سراسر برنامه شما استفاده شود، میتوانید نام این کوکی را هر چه دوست دارید نامگذاری کنید.
2. نقطه پایانی ثبت جلسه را پیاده سازی کنید
در /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"
}]
}
3. نقطه پایانی refresh را پیاده سازی کنید
وقتی کوکی کوتاه مدت منقضی میشود، Chrome یک جریان تازهسازی را برای اثبات داشتن کلید خصوصی آغاز میکند. این فرآیند شامل اقدامات هماهنگ شده توسط Chrome و سرور شما است:
Chrome درخواست کاربر را به برنامه شما موکول می کند و یک درخواست تجدید به
/RefreshEndpoint
ارسال می کند:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id
سرور شما با یک چالش پاسخ می دهد:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"
Chrome چالش را با استفاده از کلید خصوصی ذخیره شده امضا می کند و درخواست را دوباره امتحان می کند:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>
سرور شما مدرک امضا شده را تأیید می کند و یک کوکی کوتاه مدت تازه سازی شده صادر می کند:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
Chrome کوکی تازهسازیشده را دریافت میکند و درخواست معوق اصلی را از سر میگیرد.
الگوی ادغام جایگزین
برای بهبود انعطاف پذیری، سایت ها می توانند یک کوکی دوم غیر DBSC را در کنار کوکی کوتاه مدت اضافه کنند. این کوکی با عمر طولانی فقط برای صدور توکن های کوتاه مدت جدید استفاده می شود و به تمایز بین درخواست های واقعاً احراز هویت نشده و خرابی های موقت DBSC کمک می کند.
- کوکی طولانی مدت حتی اگر DBSC از کار بیفتد باقی می ماند.
- کوکی کوتاه مدت با استفاده از DBSC به روز می شود و برای عملیات حساس مورد نیاز است.
این الگو به سایت ها کنترل بیشتری بر نحوه رسیدگی به موارد لبه می دهد.
هشدارها و رفتار برگشتی
Chrome ممکن است عملیات DBSC را رد کند و بدون کوکی کوتاه مدت مدیریت شده توسط DBSC در سناریوهای زیر درخواست ارسال کند:
- به دلیل خطاهای شبکه یا مشکلات سرور، نقطه پایانی تازهسازی قابل دسترسی نیست.
- TPM مشغول است یا با خطاهای امضا مواجه می شود. از آنجا که TPM در بین فرآیندهای سیستم به اشتراک گذاشته می شود، به روز رسانی بیش از حد ممکن است از محدودیت های نرخ آن فراتر رود.
- کوکی کوتاه مدت مدیریت شده توسط DBSC یک کوکی شخص ثالث است و کاربر کوکی های شخص ثالث را در تنظیمات مرورگر خود مسدود کرده است.
در این شرایط، اگر کوکی هنوز وجود داشته باشد، کروم به استفاده از کوکی طولانی مدت بازمی گردد. این بازگشت تنها زمانی کار میکند که پیادهسازی شما شامل یک کوکی با عمر طولانی و یک کوکی کوتاه مدت باشد. اگر نه، Chrome درخواست را بدون کوکی ارسال می کند.
خلاصه
Device Bound Session Credentials امنیت جلسه را با حداقل تغییرات در برنامه شما بهبود می بخشد. آنها با گره زدن جلسات به دستگاه های خاص، محافظت قوی تری در برابر ربودن جلسه ارائه می کنند. اکثر کاربران بدون هیچ گونه اختلالی سود میبرند و DBSC به خوبی از سختافزار پشتیبانینشده عقب میافتد.
برای اطلاعات بیشتر، به مشخصات DBSC مراجعه کنید.
،Device Bound Session Credentials (DBSC) با افزودن امنیت جلسه سخت افزاری، احراز هویت را تقویت می کند.
مقدمه
بسیاری از وبسایتها برای احراز هویت کاربر به کوکیهای با عمر طولانی متکی هستند، اما این کوکیها در معرض ربودن جلسه هستند. Device Bound Session Credentials (DBSC) لایه ای از امنیت سخت افزاری را برای کاهش این خطر اضافه می کند و اطمینان حاصل می کند که جلسات به دستگاه های خاصی متصل می شوند.
این راهنما برای توسعه دهندگانی است که جریان های احراز هویت را در برنامه های کاربردی وب حفظ می کنند. این توضیح می دهد که چگونه DBSC کار می کند و چگونه آن را در سایت خود ادغام کنید.
نحوه عملکرد DBSC
در سطح بالایی، DBSC یک جفت کلید رمزنگاری مرتبط با دستگاه کاربر را معرفی می کند. Chrome این جفت کلید را در حین ورود به سیستم ایجاد میکند و کلید خصوصی را در سختافزار امن، مانند ماژول پلتفرم مورد اعتماد (TPM) در صورت وجود ذخیره میکند. در جلسات از کوکی های کوتاه مدت استفاده می شود. وقتی یکی از این کوکیها منقضی میشود، Chrome قبل از بازخوانی، داشتن کلید خصوصی را ثابت میکند. این فرآیند تداوم جلسه را به دستگاه اصلی پیوند می دهد.
اگر دستگاه کاربر از ذخیرهسازی کلید ایمن پشتیبانی نمیکند، DBSC به آرامی به رفتار استاندارد بازمیگردد، بدون اینکه جریان احراز هویت قطع شود.
مروری بر پیاده سازی
برای ادغام DBSC در برنامه خود، باید تغییرات زیر را اعمال کنید:
- جریان ورود به سیستم خود را طوری تغییر دهید که یک سرصفحه
Sec-Session-Registration
شامل شود. - یک نقطه پایانی ثبت جلسه اضافه کنید که:
- یک کلید عمومی را با جلسه کاربر مرتبط می کند.
- پیکربندی جلسه را ارائه می دهد.
- انتقال به کوکی های کوتاه مدت.
- برای رسیدگی به تمدید کوکی و تأیید اعتبار در اختیار داشتن کلید، یک نقطه پایان تازهسازی اضافه کنید.
اکثر نقاط پایانی موجود شما نیازی به تغییر ندارند. DBSC به گونه ای طراحی شده است که افزودنی و بدون اختلال باشد.
هنگامی که یک کوکی کوتاه مدت لازم وجود ندارد یا منقضی شده است، Chrome درخواست را موقتاً متوقف می کند و سعی می کند کوکی را بازخوانی کند. این به برنامه شما امکان میدهد از بررسیهای کوکی جلسه معمول خود استفاده کند تا تأیید کند کاربر وارد شده است. از آنجایی که این با جریانهای احراز هویت معمولی مطابقت دارد، DBSC با حداقل تغییرات در منطق ورود به سیستم شما کار میکند.
مراحل پیاده سازی
این بخش تغییرات لازم را در سیستم احراز هویت شما، از جمله نحوه تغییر جریان ورود به سیستم، مدیریت ثبتنام جلسه و مدیریت بازخوانیهای کوتاه مدت کوکی را بررسی میکند. هر مرحله برای ادغام هموار با زیرساخت های موجود شما طراحی شده است.
مراحل پیادهسازی از جریان رایجی پیروی میکنند که یک کاربر وارد سیستم شده هنگام فعال بودن DBSC تجربه میکند: ثبت نام در ورود به سیستم، به دنبال آن بهروزرسانیهای معمولی کوکی کوتاه مدت. بسته به سطح حساسیت جلسه برنامه خود، می توانید هر مرحله را به طور مستقل آزمایش و اجرا کنید.
1. جریان ورود به سیستم را تغییر دهید
پس از ورود کاربر، با یک کوکی طولانی مدت و یک هدر Sec-Session-Registration
پاسخ دهید. به عنوان مثال:
هدر پاسخ HTTP زیر پس از ثبت موفقیت آمیز جلسه برگردانده می شود:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
اگر دستگاه از ذخیرهسازی کلید ایمن پشتیبانی میکند، Chrome با نقطه پایانی /StartSession
با یک کلید عمومی در JSON Web Token (JWT) تماس میگیرد.
auth_cookie
در این مثال نشان دهنده نشانه جلسه شما است. تا زمانی که با فیلد name
در پیکربندی جلسه شما مطابقت داشته باشد و به طور مداوم در سراسر برنامه شما استفاده شود، میتوانید نام این کوکی را هر چه دوست دارید نامگذاری کنید.
2. نقطه پایانی ثبت جلسه را پیاده سازی کنید
در /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"
}]
}
3. نقطه پایانی refresh را پیاده سازی کنید
وقتی کوکی کوتاه مدت منقضی میشود، Chrome یک جریان تازهسازی را برای اثبات داشتن کلید خصوصی آغاز میکند. این فرآیند شامل اقدامات هماهنگ شده توسط Chrome و سرور شما است:
Chrome درخواست کاربر را به برنامه شما موکول می کند و یک درخواست تجدید به
/RefreshEndpoint
ارسال می کند:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id
سرور شما با یک چالش پاسخ می دهد:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"
Chrome چالش را با استفاده از کلید خصوصی ذخیره شده امضا می کند و درخواست را دوباره امتحان می کند:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>
سرور شما مدرک امضا شده را تأیید می کند و یک کوکی کوتاه مدت تازه سازی شده صادر می کند:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
Chrome کوکی تازهسازیشده را دریافت میکند و درخواست معوق اصلی را از سر میگیرد.
الگوی ادغام جایگزین
برای بهبود انعطاف پذیری، سایت ها می توانند یک کوکی دوم غیر DBSC را در کنار کوکی کوتاه مدت اضافه کنند. این کوکی با عمر طولانی فقط برای صدور توکن های کوتاه مدت جدید استفاده می شود و به تمایز بین درخواست های واقعاً احراز هویت نشده و خرابی های موقت DBSC کمک می کند.
- کوکی طولانی مدت حتی اگر DBSC از کار بیفتد باقی می ماند.
- کوکی کوتاه مدت با استفاده از DBSC به روز می شود و برای عملیات حساس مورد نیاز است.
این الگو به سایت ها کنترل بیشتری بر نحوه رسیدگی به موارد لبه می دهد.
هشدارها و رفتار برگشتی
Chrome ممکن است عملیات DBSC را رد کند و بدون کوکی کوتاه مدت مدیریت شده توسط DBSC در سناریوهای زیر درخواست ارسال کند:
- به دلیل خطاهای شبکه یا مشکلات سرور، نقطه پایانی تازهسازی قابل دسترسی نیست.
- TPM مشغول است یا با خطاهای امضا مواجه می شود. از آنجا که TPM در بین فرآیندهای سیستم به اشتراک گذاشته می شود، به روز رسانی بیش از حد ممکن است از محدودیت های نرخ آن فراتر رود.
- کوکی کوتاه مدت مدیریت شده توسط DBSC یک کوکی شخص ثالث است و کاربر کوکی های شخص ثالث را در تنظیمات مرورگر خود مسدود کرده است.
در این شرایط، اگر کوکی هنوز وجود داشته باشد، کروم به استفاده از کوکی طولانی مدت بازمی گردد. این بازگشت تنها زمانی کار میکند که پیادهسازی شما شامل یک کوکی با عمر طولانی و یک کوکی کوتاه مدت باشد. اگر نه، Chrome درخواست را بدون کوکی ارسال می کند.
خلاصه
Device Bound Session Credentials امنیت جلسه را با حداقل تغییرات در برنامه شما بهبود می بخشد. آنها با گره زدن جلسات به دستگاه های خاص، محافظت قوی تری در برابر ربودن جلسه ارائه می کنند. اکثر کاربران بدون هیچ گونه اختلالی سود میبرند و DBSC به خوبی از سختافزار پشتیبانینشده عقب میافتد.
برای اطلاعات بیشتر، به مشخصات DBSC مراجعه کنید.
،Device Bound Session Credentials (DBSC) با افزودن امنیت جلسه سخت افزاری، احراز هویت را تقویت می کند.
مقدمه
بسیاری از وبسایتها برای احراز هویت کاربر به کوکیهای با عمر طولانی متکی هستند، اما این کوکیها در معرض ربودن جلسه هستند. Device Bound Session Credentials (DBSC) لایه ای از امنیت سخت افزاری را برای کاهش این خطر اضافه می کند و اطمینان حاصل می کند که جلسات به دستگاه های خاصی متصل می شوند.
این راهنما برای توسعه دهندگانی است که جریان های احراز هویت را در برنامه های کاربردی وب حفظ می کنند. این توضیح می دهد که چگونه DBSC کار می کند و چگونه آن را در سایت خود ادغام کنید.
نحوه عملکرد DBSC
در سطح بالایی، DBSC یک جفت کلید رمزنگاری مرتبط با دستگاه کاربر را معرفی می کند. Chrome این جفت کلید را در حین ورود به سیستم ایجاد میکند و کلید خصوصی را در سختافزار امن، مانند ماژول پلتفرم مورد اعتماد (TPM) در صورت وجود ذخیره میکند. در جلسات از کوکی های کوتاه مدت استفاده می شود. وقتی یکی از این کوکیها منقضی میشود، Chrome قبل از بازخوانی، داشتن کلید خصوصی را ثابت میکند. این فرآیند تداوم جلسه را به دستگاه اصلی پیوند می دهد.
اگر دستگاه کاربر از ذخیرهسازی کلید ایمن پشتیبانی نمیکند، DBSC به آرامی به رفتار استاندارد بازمیگردد، بدون اینکه جریان احراز هویت قطع شود.
مروری بر پیاده سازی
برای ادغام DBSC در برنامه خود، باید تغییرات زیر را اعمال کنید:
- جریان ورود به سیستم خود را طوری تغییر دهید که یک سرصفحه
Sec-Session-Registration
شامل شود. - یک نقطه پایانی ثبت جلسه اضافه کنید که:
- یک کلید عمومی را با جلسه کاربر مرتبط می کند.
- پیکربندی جلسه را ارائه می دهد.
- انتقال به کوکی های کوتاه مدت.
- برای رسیدگی به تمدید کوکی و تأیید اعتبار در اختیار داشتن کلید، یک نقطه پایان تازهسازی اضافه کنید.
اکثر نقاط پایانی موجود شما نیازی به تغییر ندارند. DBSC به گونه ای طراحی شده است که افزودنی و بدون اختلال باشد.
هنگامی که یک کوکی کوتاه مدت لازم وجود ندارد یا منقضی شده است، Chrome درخواست را موقتاً متوقف می کند و سعی می کند کوکی را بازخوانی کند. این به برنامه شما امکان میدهد از بررسیهای کوکی جلسه معمول خود استفاده کند تا تأیید کند کاربر وارد شده است. از آنجایی که این با جریانهای احراز هویت معمولی مطابقت دارد، DBSC با حداقل تغییرات در منطق ورود به سیستم شما کار میکند.
مراحل پیاده سازی
این بخش تغییرات لازم را در سیستم احراز هویت شما، از جمله نحوه تغییر جریان ورود به سیستم، مدیریت ثبتنام جلسه و مدیریت بازخوانیهای کوتاه مدت کوکی را بررسی میکند. هر مرحله برای ادغام هموار با زیرساخت های موجود شما طراحی شده است.
مراحل پیادهسازی از جریان رایجی پیروی میکنند که یک کاربر وارد سیستم شده هنگام فعال بودن DBSC تجربه میکند: ثبت نام در ورود به سیستم، به دنبال آن بهروزرسانیهای معمولی کوکی کوتاه مدت. بسته به سطح حساسیت جلسه برنامه خود، می توانید هر مرحله را به طور مستقل آزمایش و اجرا کنید.
1. جریان ورود به سیستم را تغییر دهید
پس از ورود کاربر، با یک کوکی طولانی مدت و یک هدر Sec-Session-Registration
پاسخ دهید. به عنوان مثال:
هدر پاسخ HTTP زیر پس از ثبت موفقیت آمیز جلسه برگردانده می شود:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
اگر دستگاه از ذخیرهسازی کلید ایمن پشتیبانی میکند، Chrome با نقطه پایانی /StartSession
با یک کلید عمومی در JSON Web Token (JWT) تماس میگیرد.
auth_cookie
در این مثال نشان دهنده نشانه جلسه شما است. تا زمانی که با فیلد name
در پیکربندی جلسه شما مطابقت داشته باشد و به طور مداوم در سراسر برنامه شما استفاده شود، میتوانید نام این کوکی را هر چه دوست دارید نامگذاری کنید.
2. نقطه پایانی ثبت جلسه را پیاده سازی کنید
در /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"
}]
}
3. نقطه پایانی refresh را پیاده سازی کنید
وقتی کوکی کوتاه مدت منقضی میشود، Chrome یک جریان تازهسازی را برای اثبات داشتن کلید خصوصی آغاز میکند. این فرآیند شامل اقدامات هماهنگ شده توسط Chrome و سرور شما است:
Chrome درخواست کاربر را به برنامه شما موکول می کند و یک درخواست تجدید به
/RefreshEndpoint
ارسال می کند:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id
سرور شما با یک چالش پاسخ می دهد:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"
Chrome چالش را با استفاده از کلید خصوصی ذخیره شده امضا می کند و درخواست را دوباره امتحان می کند:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>
سرور شما مدرک امضا شده را تأیید می کند و یک کوکی کوتاه مدت تازه سازی شده صادر می کند:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
Chrome کوکی تازهسازیشده را دریافت میکند و درخواست معوق اصلی را از سر میگیرد.
الگوی ادغام جایگزین
برای بهبود انعطاف پذیری، سایت ها می توانند یک کوکی دوم غیر DBSC را در کنار کوکی کوتاه مدت اضافه کنند. این کوکی با عمر طولانی فقط برای صدور توکن های کوتاه مدت جدید استفاده می شود و به تمایز بین درخواست های واقعاً احراز هویت نشده و خرابی های موقت DBSC کمک می کند.
- کوکی طولانی مدت حتی اگر DBSC از کار بیفتد باقی می ماند.
- کوکی کوتاه مدت با استفاده از DBSC به روز می شود و برای عملیات حساس مورد نیاز است.
این الگو به سایت ها کنترل بیشتری بر نحوه رسیدگی به موارد لبه می دهد.
هشدارها و رفتار برگشتی
Chrome ممکن است عملیات DBSC را رد کند و بدون کوکی کوتاه مدت مدیریت شده توسط DBSC در سناریوهای زیر درخواست ارسال کند:
- به دلیل خطاهای شبکه یا مشکلات سرور، نقطه پایانی تازهسازی قابل دسترسی نیست.
- TPM مشغول است یا با خطاهای امضا مواجه می شود. از آنجا که TPM در بین فرآیندهای سیستم به اشتراک گذاشته می شود، به روز رسانی بیش از حد ممکن است از محدودیت های نرخ آن فراتر رود.
- کوکی کوتاه مدت مدیریت شده توسط DBSC یک کوکی شخص ثالث است و کاربر کوکی های شخص ثالث را در تنظیمات مرورگر خود مسدود کرده است.
در این شرایط، اگر کوکی هنوز وجود داشته باشد، کروم به استفاده از کوکی طولانی مدت بازمی گردد. این بازگشت تنها زمانی کار میکند که پیادهسازی شما شامل یک کوکی با عمر طولانی و یک کوکی کوتاه مدت باشد. اگر نه، Chrome درخواست را بدون کوکی ارسال می کند.
خلاصه
Device Bound Session Credentials امنیت جلسه را با حداقل تغییرات در برنامه شما بهبود می بخشد. آنها با گره زدن جلسات به دستگاه های خاص، محافظت قوی تری در برابر ربودن جلسه ارائه می کنند. اکثر کاربران بدون هیچ گونه اختلالی سود میبرند و DBSC به خوبی از سختافزار پشتیبانینشده عقب میافتد.
برای اطلاعات بیشتر، به مشخصات DBSC مراجعه کنید.