قفل رمزنگاری مبدأ در وب‌آتن: چرا پروکسی‌های فیشینگ دیگر کارساز نیستند؟

احراز هویت چندعاملی سنتی دیگر نمی‌تواند امنیت حساب‌های کاربری را در برابر کارزارهای پیشرفته فیشینگ تضمین کند. مهاجمان امروزه به‌سادگی با بهره‌گیری از پروکسی‌های معکوس که اطلاعات هویتی را در لحظه رله می‌کنند، کدهای پیامکی و نرم‌افزارهای تولید رمز یک‌بارمصرف را دور می‌زنند. در این میان، سازوکاری که عملاً مانع این حمله می‌شود پروتکل «وب‌آتن» (WebAuthn) است؛ استانداردی که اساساً عامل انسانی را از حلقه اعتبارسنجی دامنه کنار می‌گذارد.[1][2]

وب‌آتن با پیوند دادن رمزنگاری‌شده فرآیند ورود به نوار آدرس مرورگر، داده‌های به‌سرقت‌رفته را از نظر ریاضی کاملاً بی‌ارزش می‌کند. این پروتکل اصلاً بر تشخیص دامنه‌های جعلی یا خطاهای ظریف املایی توسط کاربر تکیه ندارد؛ بلکه مرورگر را مجبور می‌کند تا نشانی دقیق مبدأ (Origin) را مستقیماً در بسته داده‌های امضا بگنجاند.[1][5]

این سازوکار که «پیوند به مبدأ» (Origin Binding) نام دارد، بنیان کلیدهای عبور (Passkeys) و کلیدهای سخت‌افزاری امنیتی FIDO2 به‌شمار می‌رود. درحالی‌که تبلیغات شرکت‌ها معمولاً بر راحتی و سرعت اثر انگشت یا تشخیص چهره تمرکز دارند، ارتقای واقعی امنیت به‌شکلی نامرئی رخ می‌دهد؛ حسگر زیست‌سنجی فقط کلید خصوصی را باز می‌کند، اما این قفل مبدأ است که مانع امضای یک چالش جعلی با آن کلید می‌شود.[2][3]

کنسرسیوم وب جهان‌گستر (W3C) این شیوه را نخستین‌بار در قالب نسخه اول وب‌آتن در سال ۲۰۱۹ استانداردسازی کرد و سپس آن را در نسخه دوم در سال ۲۰۲۱ توسعه داد. با تشدید حملات واسطه در مسیر (AiTM)، شناخت دقیق شیوه عمل این مرزهای رمزنگاری ضروری است؛ آسیب‌پذیری اصلی راهکارهای سنتی چندعاملی، نه در ضعف خود عامل، بلکه در قابلیت جابه‌جایی و انتقال آن نهفته است.[1][6]

پروکسی‌های معکوس چگونه نشست‌ها را می‌دزدند؟

برای درک علت موفقیت وب‌آتن، ابتدا باید نقطه شکست احراز هویت چندعاملی متداول را واکاوی کرد. جعبه‌ابزارهای تجاری فیشینگ مانند Tycoon 2FA و Evilproxy وقت خود را صرف کرک کردن رمز عبور یا حدس زدن کدهای یک‌بارمصرف زمان‌محور نمی‌کنند؛ بلکه صرفاً یک سرور میانی بین کاربر قربانی و سامانه اصلی احراز هویت قرار می‌دهند.[2][6]

هنگامی که کاربر روی یک پیوند فیشینگ کلیک می‌کند، وارد سرور پروکسی تحت کنترل مهاجم می‌شود که معمولاً دامنه‌ای مشابه سایت واقعی دارد. این پروکسی صفحه ورود اصلی را مستقیماً از بانک یا سامانه مقصد دریافت کرده و به کاربر نشان می‌دهد. صفحه کاملاً واقعی به نظر می‌رسد چون محتوای واقعی است که از یک کانال متخاصم بازپخش می‌شود.[2][5]

به‌محض اینکه کاربر رمز خود را تایپ می‌کند، پروکسی نویسه‌ها را ذخیره کرده و فوراً به سرور اصلی تحویل می‌دهد. اگر سرور یک کد اعتبارسنجی شش‌رقمی بخواهد، پروکسی همان فرم را به قربانی نشان می‌دهد؛ کاربر کد را وارد می‌کند و سرور پروکسی با ارسال آن به سرور اصلی، فرآیند را تکمیل می‌نماید.[1][4]

در راهنمای پیاده‌سازی شرکت Adaptive Security در سال ۲۰۲۶ آمده است: «روند حمله کاملاً خودکار و یکپارچه است. قربانی به صفحه‌ای می‌رود که مو نمی‌زند، نام کاربری و رمز را می‌نویسد و زیرساخت مهاجم در همان ثانیه داده‌ها را ارسال می‌کند.»

به‌محض پذیرش کد از سوی سرور اصلی، کوکی نشست (Session Cookie) برای زنده نگه‌داشتن ورود صادر می‌شود. پروکسی معکوس این کوکی را تصاحب کرده، نسخه‌ای از آن را به مهاجم اختصاص می‌دهد و باقی را به مرورگر قربانی می‌فرستد. از این لحظه، مهاجم صاحب نشستی کاملاً معتبر است و چندعاملی را به زانو درآورده است.[2][5]

جایگزینی امضای رمزنگاری به‌جای اطلاعات محرمانه

وب‌آتن این زنجیره حمله را با کنار گذاشتن کامل «اسرار اشتراکی» از بین می‌برد. رمزهای عبور، پیامک‌ها و کدهای برنامه‌های احراز هویت همگی یک نقطه ضعف ساختاری دارند: آن‌ها رشته‌داده‌هایی قابل جابه‌جایی و انتقال هستند. اگر مهاجم این رشته را به چنگ آورد، می‌تواند آن را از هر کجای جهان به سرور ارائه کند و سرور راهی برای تشخیص منشأ آن ندارد.[1][4]

در نقطه مقابل، وب‌آتن بر رمزنگاری نامتقارن متکی است. در جریان ثبت‌نام، احرازکننده کاربر — چه تراشه امن درون گوشی هوشمند باشد و چه یک دانگل سخت‌افزاری — یک جفت‌کلید رمزنگاری منحصربه‌فرد می‌سازد. کلید خصوصی برای همیشه در محیط ایزوله سخت‌افزار باقی می‌ماند و بیرون نمی‌رود.[1][3]

تنها کلید عمومی در اختیار سامانه متکی (همان سرور مقصد) قرار می‌گیرد. هنگام تلاش برای ورود، سرور رمزی از کاربر نمی‌خواهد؛ بلکه یک چالش رمزنگاری تصادفی تولید کرده و برای مرورگر می‌فرستد تا با کلید خصوصی معادل امضا شود.[4][5]

کاربر این امضا را به‌صورت محلی، معمولاً با اثر انگشت، تشخیص چهره یا پین دستگاه تأیید می‌کند. احرازکننده چالش را امضا کرده و نتیجه را برای سرور می‌فرستد. چون کلید خصوصی از تراشه تکان نمی‌خورد، نشت پایگاه‌داده سرور یا شنود ترافیک کمکی به مهاجم نمی‌کند.[1][4]

نکته کلیدی این است که این امضا، مالکیت کلید را بدون افشای محتوای آن ثابت می‌کند. سرور با استفاده از کلید عمومی ذخیره‌شده، درستی محاسبات را می‌سنجد. اگر تطبیق انجام شود ورود تأیید می‌شود؛ اما این چرخه چالش-پاسخ به‌تنهایی مانع بازپخش چالش توسط پروکسی معکوس نمی‌شود.[1][5]

مرورگر چگونه دامنه جعلی را به تله می‌اندازد؟

سد قاطع در برابر فیشینگ واسطه در یک ویژگی کلیدی وب‌آتن به نام پیوند به مبدأ نهفته است. وقتی سرور چالش را صادر می‌کند، مرورگر پیش از ارسال آن به قطعه سخت‌افزاری مداخله می‌نماید. مرورگر نام دامنه دقیقی را که در نوار آدرس کاربر باز است، استخراج می‌کند.[1][6]

وب‌آتن برای ایجاد این قفل ساختاری از دو شناسه دامنه مستقل بهره می‌برد. نخست شناسه سامانه متکی (RP ID) است که در زمان ثبت‌نام توسط سرویس تعیین می‌شود و معمولاً همان دامنه اصلی سایت است. احرازکننده از این شناسه یک چکیده SHA-256 سی‌ودو بایتی می‌سازد و درون امضا جای می‌دهد.[4][6]

شناسه دوم، چکیده داده‌های کلاینت (Client Data Hash) است. مرورگر چالش سرور، نشانی اینترنتی مبدأ که کاربر واقعاً در آن قرار دارد و سایر داده‌ها را در قالب یک بسته JSON ترکیب می‌کند. سپس هش SHA-256 این مجموعه تولید شده و همراه با هش سامانه متکی برای امضا به احرازکننده تحویل می‌گردد.[2][5]

اگر کاربر فریب خورده و در یک دامنه پروکسی قلابی باشد، مرورگر همان نشانی نامعتبر را به‌عنوان مبدأ ثبت می‌کند. پروکسی می‌تواند چالش ارسالی از بانک اصلی را منتقل کند، اما دستش به مرورگر قربانی نمی‌رسد تا آن را وادار به جعل نوار آدرس نماید. مرورگر مبدأ جعلی را وارد بسته امضا می‌کند.[1][2]

هنگامی که پروکسی پاسخ امضاشده را به سرور بانک اصلی می‌فرستد، بانک داده‌ها را باز می‌کند. سرور انتظار دارد امضا بر مبنای نشانی خود بانک مهروموم شده باشد، اما با نام دامنه پروکسی روبه‌رو می‌شود. سامانه بی‌درنگ احراز هویت را رد می‌کند و بدین‌ترتیب حمله در سطح پروتکل ناکام می‌ماند.[4][6]

سرقت نشست و خطرات پس از احراز هویت

اگرچه وب‌آتن در لحظه ورود دیواری رسوخ‌ناپذیر پدید می‌آورد، اما همه مشکلات امنیتی را حل نمی‌کند. پروتکل تضمین می‌کند مهاجم نتواند امضای ورود را با دامنه نامربوط صادر کند، اما از نشست کاربر پس از اتمام احراز هویت محافظت نخواهد کرد.[1][5]

اگر سازمانی وب‌آتن را فعال کند اما مسیر بازگشت به رمزهای عبور سنتی را باز بگذارد، مهاجمان به‌سمت همان شیوه ضعیف‌تر خواهند رفت. حفظ این روش‌های جایگزین، آسیب‌پذیری بازپخش داده‌ها را زنده نگه می‌دارد و دستاوردهای پروتکل جدید را کم‌اثر می‌کند.[2][4]

همچنین اگر بدافزاری روی دستگاه کاربر فعال باشد، قادر است کوکی‌های نشست را مستقیماً از حافظه موقت مرورگر به سرقت ببرد. وب‌آتن قفل در ورودی را ضدسرقت می‌کند، اما کوکی دزدیده‌شده به مهاجم اجازه می‌دهد بدون نیاز به ورود مجدد وارد حساب شود.[5][6]

برای مهار این خطر، زیرساخت‌های حساس در پی توسعه پروتکل‌های پیوند توکن هستند تا کوکی نشست مستقیماً به هویت سخت‌افزاری دستگاه قفل شود. تا زمان فراگیر شدن آن استانداردها، ربودن نشست همچنان گزینه‌ای جدی، هرچند پیچیده‌تر، برای هکرهای ماهر خواهد بود.[2][6]

اتحادیه FIDO نیز بر این خطرات باقی‌مانده واقف است. در دستورالعمل سال ۲۰۲۵ این نهاد آمده است که اگرچه کلیدهای عبور مانع هک مستقیم از طریق فیشینگ می‌شوند، نشست‌های لو رفته همچنان می‌توانند انجام عملیات مخرب به‌جای کاربر واقعی را ممکن سازند.[2]

پیاده‌سازی احراز هویت مقاوم در برابر فیشینگ

با تمام این ملاحظات پس از ورود، حرکت به‌سوی وب‌آتن اساسی‌ترین ارتقای امنیت وب در یک دهه گذشته است. بر اساس آمار اتحادیه FIDO در سال ۲۰۲۵، با پشتیبانی پلتفرم‌های بزرگ حدود ۵۳ درصد از کاربران بررسی‌شده کلید عبور را دست‌کم روی یک حساب فعال کرده‌اند.[2][6]

دستور کار برای مدیران فناوری شرکت‌ها کاملاً روشن است. آژانس امنیت سایبری و امنیت زیرساخت آمریکا (CISA) اکنون FIDO2 و وب‌آتن را تنها استانداردهای واقعاً مقاوم در برابر فیشینگ می‌داند و احراز هویت سنتی را برای دسترسی‌های حساس رد می‌کند.[5][6]

پیاده‌سازی این معماری نیازمند دقت فنی بالاست. توسعه‌دهندگان باید چالش، مبدأ، هش شناسه سامانه متکی و امضا را بادقت روی سرور اعتبارسنجی کنند؛ چراکه اهمال در چک کردن مبدأ روی سرور، همه محافظت‌های پیشرفته مرورگر را یک‌شبه بر باد می‌دهد.[1][4]

وب‌آتن بار سنگین امنیت را از دوش دقت کاربر برمی‌دارد و آن را به ریاضیات رمزنگاری می‌سپارد. دیگر نه نیازی به ذره‌بین دست گرفتن کاربران برای خواندن حروف آدرس‌هاست و نه نیازی به دوره‌های آموزشی برای یافتن پروکسی‌های پنهان؛ پروتکل به‌سادگی پذیرش دروغ را رد می‌کند و پرونده رله کردن اعتبارنامه‌ها را می‌بندد.[1][6]