اصل ماجرا

در Chrome 146+ مرورگر کلید عمومی را از TPM یا Secure Enclave می‌گیرد و جلسه را به این کلید می‌پیوندد. سرور فقط کلید عمومی را می‌داند و هر چند دقیقه یک‌بار با امضای چالش، ثابت می‌کند دستگاه هنوز کلید را دارد. اگر کوکی به دستگاه دیگر منتقل شود، امضا نمی‌شود و جلسه قطع می‌شود. کتابخانه dbsc‑toolkit این پروتکل را برای Express به‌صورت آماده فراهم می‌کند.

متن کامل ترجمه‌شده

یک کوکی جلسه سرقت شده یک کسب و کار کامل است. حمله کننده کوکی را از پروفایل مرورگر کپی می کند - نرم افزار مخرب infostealer دقیقا این کار را انجام می دهد، در مقیاس - آن را به مرورگر خود می ریزد، و آنها شما هستند. هر دفاعی که ما در (SameSite, Secure, HttpOnly, short TTLs) کپی کرده ایم، شتر انفجار را کاهش می دهد، اما ناخن را بسته نمی کند: یک تکیه برنده یک تکیه برنده است، و هر کس که آن را نگه دارد، برنده می شود. Device Bound Session Credentials (DBSC) آن را بسته می کند. Chrome آن را به ثابت در 146 ارسال کرده است. ایده کوچک است و عواقب آن بزرگ است: در ثبت نام، مرورگر یک EC P-256 کلیدپیکپی کوکی به دستگاه دیگری و تازه سازی بعدی ناکام می شود، زیرا این دستگاه نمی تواند امضای را تولید کند. جلسه در یک چرخه تازه سازی می میرد. این پست از طرف سرور، در Express، پایان به پایان است. من از dbsc-toolkit استفاده می کنم - کتابخانه ای که من نوشتم و با Chrome 147 بر روی نرم افزار واقعی TPM 2.0 تصدیق کردم - بنابراین پروتکل plumbing پردازش می شود و ما می توانیم بر آنچه شما در واقع قفل می کنیم تمرکز کنیم. آنچه شما ایجاد می کنید سه قسمت حرکت در سرور: - پروتکل دو مسیر - /dbsc / ثبت نام(برای مرورگر POST کلید عمومی خود را در اینجا) و /dbsc / refresh(برای مرورگر دوباره ثابت می کند مالکیت در اینجا). شما این را نوشتن نمی کنید؛ middleware آنها را نصب می کند. - یک تماسInstall npm install dbsc-toolkit express Framework and storage drivers are optional peer deps, so you only pull what you use. Memory storage is fine to start; swap in Redis or Postgres for anything that has to survive a restart. The minimum working server import express from “express”; import { randomUUID } from “node:crypto”; import {create Dbsc } from “dbsc-toolkit/express”; import { MemoryStorage } from “dbsc-toolkit/storage/memory”; const app =(); app.use(express.json()); // Configure once install() monts the protocol routes, the bound-route JSON parser, the browser SDK, and trust proxy all — in one call.body constcdbsc؛ اگر (!sessionId) res.status(401).json({ error: “not authenticated” }); res.json({ sessionId, tier }); }); app.listen(3000); این کل سرور است. dbsc.bind() پنج کار را تحت قفل انجام می دهد: خط جلسه را می نویسد، یک چالش واحدی را منتشر می کند، عنوان پاسخ Secure-Session-Registration را ایجاد می کند، نام ها را برای سازگاری قرار می دهد و کوکی های کوتاه عمر را Chrome نیاز دارد تا ثبت نام را تکمیل کند. شما یک عملکرد را در یک مکان که در حال حاضر دارید – مسیر ثبت نام را دعوت می کنید. HTTPS گزینه ای نیست DBSC از __Host-prefixed کوکی ها استفاده می کند، که Chrome فقط HTTPS را با پرچم امن و هیچ atribute Domaاگر شما تنظیم امنیت: جعلی برای HTTP تنها آزمایش های محلی، DBSC متولد هنوز به تعامل نمی کند - Chromium از پروتکل از HTTP رد می کند - اما راه polyfil (برای این در زیر بیشتر) کار می کند از طریق Web Crypto، که به اندازه کافی برای اجرای جریان است. تماشای آن کار برنامه را در یک مرورگر Chromium 146+ از طریق HTTPS باز کنید، DevTools → شبکه را باز کنید و POST /login کلیک کنید. در یک ثانیه یا چند شما یک درخواست خواهید دید که شما هرگز نوشت: POST /dbsc / ثبت نام، توسط مرورگر خود آغاز شده است. این درخواست یک JWS امضا شده توسط کلید Hardware تازه مجهز می کند. سرور امضا خود را بررسی می کند، کلید عمومی را زیر شناسه جلسه ذخیره می کند، __Host-dbs-اگر شما متوقف شده در نایاب، شما ممکن است محافظت از یک سوم از کاربران خود را و ترک همه دیگر را در کوکی های بورس ساده - که یک چیز ناخوشایند برای قرار دادن در بررسی امنیتی است. بنابراین dbsc-toolkit همچنین فرود یک Web Crypto polyfill. آن را می سازد همان جلسه با یک CryptoKey غیر قابل استخراج در IndexedDB. این یک نهچ ضعیف تر از TPM است - کلید زندگی در ذخیره سازی مرورگر به جای یک چپس امنیتی جداگانه، بنابراین آن را در برابر نرم افزار مضر با دسترسی کامل به دستگاه خود کاربر - اما آن را شکست هر سیگنال cookie-replay از راه دور، که تهدیدی است که مهم است برای بخش-DB است. که به شما سه حالت، در معرض res.locals.dbsctier. - dbsctier: - dbscاگر شما به طور خاص می خواهید تنها متولد و هیچ polyfill، وجود دارد یک محدودیت: switch فاسد - اما استاندارد همه را پوشش می دهد. ذخیره راه ها که مهم است Binding جلسه نصف ارزش است. نیمی دیگر نیاز به یک ثابت تازه، هر درخواست قبل از انجام چیزی حساس - یک پرداخت، تغییر رمز عبور، صادرات داده است. این یک محافظت است: وارد { requireProof } از “dbsc-toolkit/express”; app.post(“/payment”, requireProof(), (req, res) => { res.json({ ok: true, tier: res.locals.dbsc.tier }); }); require() رد هر درخواست که از دستگاه متصل نمی شود - یک کوکی تکرار شده از جایی دیگر هرگز در اینجا نمی آید. این کار در تمام سه سطح یکسان است، بنابراین شما یک بار ذخیره کنید ودر Chromium، مرورگر POSTs /dbsc / ثبت چند صد میلی ثانیه بعد از آن؛ در Firefox / Safari، polyfill ابتدا برای پشتیبانی متولد برای چند ثانیه بررسی می کند و سپس ثبت می کند. هرچند، اگر Frontend خود را بررسی می کند که جلسات بلافاصله ثبت نام حل می شود، آن را می بیند سطح: “هیچ” حتی در یک مرورگر به طور کامل پشتیبانی می شود - نه به این دلیل که چیزی شکست، اما به این دلیل که اتصال هنوز اتفاق نیفتاده است. بازنگری نکنید تا آن را صبر کنید؛ تاخیر قابل تغییر است و شما می دانید. مرورگر SDK به شما وعده ای می دهد که دقیقا زمانی که اتصال بلافاصله پایان می یابد حل می شود: constcome = منتظر initBoundDbsc(); اگر (outcome.phase !== “boundبرخی از آنها را در زمان واقعی سوختم، که همه اینها را طرح W3C آشکار نمی کند: - نقطه انتقالات باید به 403 در یک شواهد ناپدید یا غیرفعال پاسخ دهد - هرگز 401. کرومیم به آرامی یک 401 را نادیده می گیرد و اجازه می دهد که جلسه به جای شروع دوباره چالش را بکشد. اولین بار که من “حق” 401 را بازگردانده ام، جلسه به آرامی متوقف شد و من هیچ اشتباهی نداشتم. - ثبت نام و تازه سازی باید پاسخ 200 با بدن JSON-config جلسه، نه یک bare204. A 204 در DevTools به طور کامل خوب به نظر می رسد و باعث می شود کروموم پایان جلسه در هر صورت است. - اعتبارات].[تخصیص در این JSON باید با Real-Set-Cookieheader byte-for-byاین کار است که کتابخانه وجود دارد که در حال حاضر انجام داده است - آن را با انتها به انتها در مقابل Chrome 147 بر روی نرم افزار TPM واقعی تایید شده است، و قرارداد قفل دقیق به عنوان یک اسپیک زبان مستقل با وکتور های آزمایش سفر دور نوشته شده است اگر شما می خواهید آن را در یک زبان دیگر اجرا کنید. کجا بروید بعدی - دمو راه اندازی با هر دو cookie-session و JWT حالت ثبت نام: مثال ها / Express. - Adapters برای Fastify، Hono، و Next.js App Router کشتی در همان بسته. - پروتکل اسپیک و وکتور های آزمایش، اگر شما DBSC در هر جایی خارج از Node: spec / implementing DBSC است.

چرا مهمه؟

اولین تغییر این است که توکن جلسه دیگر فقط یک رشته قابل حمل نیست؛ به کلید سخت‌افزاری بایند می‌شود. این تغییر برای کاربران وب که از Chrome استفاده می‌کنند و برای سرویس‌های حساس مثل پرداخت یا تغییر رمز عبور اثر می‌گذارد. خواننده باید به این خبر اهمیت بده چون می‌تواند ریسک سرقت حساب را به‌طور چشمگیری کاهش دهد و بدون تغییر اساسی در سامانهٔ احراز هویت، امنیت را بالا ببرد.

به درد کی می‌خوره؟

• توسعه‌دهندگان وب با Node.js/Express • تیم‌های امنیت اطلاعات • مدیران فنی سرویس‌های حساس • مهندسان DevOps که زیرساخت HTTPS دارند

تو عمل چی کار کنیم؟

با نصب dbsc‑toolkit می‌توانید در چند خط کد، بایندینگ سخت‌افزاری را به مسیر لاگین اضافه کنید و برای مسیرهای مهم گاردی بگذارید که فقط دستگاه بایند شده بتواند درخواست بدهد. این کار باعث می‌شود حتی اگر کوکی توسط بدافزار استخراج شود، نتواند در مرورگر دیگر استفاده شود و حساب کاربری در امان بماند.

نظر Blue IT News

پیشنهاد می‌کنیم برای همهٔ برنامه‌های جدید HTTPS الزامی کنید و DBSC را به‌عنوان پیش‌فرض امنیت سشن فعال کنید؛ این کار هزینهٔ پیاده‌سازی را به‌دست‌کم می‌کاهد و ریسک سرقت حساب را به‌طور قابل‌توجهی پایین می‌آورد.

<div class=“disclosure”> این صفحه ترجمه و تفسیر کاملی از گزارش اصلی Dev است که توسط تیم تحریریه بلو آی تی نیوز به فارسی ترجمه و تحلیل شده. برای مشاهده نسخه اصلی، به منبع مراجعه کنید. </div>