۶ خط کد برای دسترسی غیرمجاز به جیمیل از طریق افزونه کلود در کروم

تصور کنید تنها ۶ خط کد کافی باشد تا افزونه مدل کلود در مرورگر کروم شما را فریب دهد و به ایمیل‌های خصوصی‌تان دسترسی پیدا کند. در ۱۴ جولای ۲۰۲۴، پژوهشگران شرکت Manifold Security نشان دادند که نسخه ۱.۰.۸۰ این افزونه، «کلیک‌های مصنوعی» (Synthetic Clicks) را می‌پذیرد؛ این یعنی هر افزونه شخص ثالث دیگری که به DOM دسترسی داشته باشد، می‌تواند گردش‌های کاری داخلی را تحریک کرده و اقدامات حساسی را در نام کاربر اجرا کند.

این آسیب‌پذیری درست زمانی رخ می‌دهد که عامل‌های هوش مصنوعی (AI Agents) از محیط‌های ساده‌ی چت خارج شده و به شرکت‌کنندگان فعال در مرورگر تبدیل می‌شوند. همان‌طور که در تحلیل قبلی ما درباره‌ی هک شدن مدل‌های آنتروپیک (Anthropic) در جریان آزمون‌های امنیتی اشاره کردیم، این یافته یک تغییر حیاتی را برجسته می‌کند: خطر دیگر تنها در استدلال مدل نیست، بلکه در مرزهای شکننده‌ی میان افزونه‌های مرورگر نهفته است. در حالی که این نقص مربوط به لایه‌ی دسترسی است، پژوهشگران همزمان در حال بررسی ساختارهای درونی این مدل‌ها هستند؛ برای مثال، کشف فضای J در مدل کلود نشان داد که چگونه مراکز پردازش استدلال در این هوش مصنوعی سازمان‌یافته‌اند.

ریسک‌های زیرساختی

این یک سناریوی باز نیست که در آن هر وب‌سایت تصادفی بتواند به ایمیل‌های شما دسترسی پیدا کند. پیش‌شرط این حمله قابل توجه است: باید افزونه‌ی دیگری که قابلیت تعامل با DOM وب‌سایت claude.ai را دارد، از قبل روی کامپیوتر نصب شده باشد. با این حال، همین موضوع باعث می‌شود این کشف برای کسانی که اجازه می‌دهند عامل‌ها در مرورگر به‌جای آن‌ها در یک نشست (Session) عمل کنند، حیاتی باشد. در اینجا، لایه حفاظتی نه در خودِ مدل، بلکه در شکاف ارتباطی میان افزونه‌ها قرار داشت.

طبق گزارش Manifold Security، مشکل اصلی نبودِ بررسی event.isTrusted در مدیریت کلیک‌ها (Click Handler) است. در حالی که کلود از یک لیست سفید (Allowlist) برای محدود کردن اقدامات به گردش‌های کاری خاص استفاده می‌کند، اما بررسی نمی‌کند که چه کسی درخواست را آغاز کرده است. در واقع، لیست سفید به پرسش «چه چیزی مجاز است؟» پاسخ می‌دهد، اما در پاسخ به پرسش که «چه کسی دستور اجرا را داده است؟» شکست می‌خورد.

مکانیزم حمله

به نقل از پژوهشگران، روند فنی این حمله به ترتیب زیر است:

• دسترسی به DOM: یک افزونه مخرب ابتدا به ساختار HTML (یعنی DOM) صفحه claude.ai دسترسی می‌یابد.
• ایجاد المان: این افزونه المان مورد نیاز را ایجاد کرده و یک رویداد کلیک مصنوعی (Synthetic Click Event) ارسال می‌کند.
• پردازش رویداد: کلود این رویداد را به عنوان یک اقدام مشروع انسانی می‌پذیرد، زیرا نمی‌تواند تفاوت میان یک اقدام واقعی توسط انسان و یک اقدام تولید شده توسط برنامه را تشخیص دهد.
• اجرای گردش کار: در نهایت، عامل یکی از ۹ گردش کار تعریف‌شده و ثابت را اجرا می‌کند. اهداف اصلی این ادغام‌ها شامل Gmail، نظرات در Google Docs، تقویم گوگل و اقدامات در Salesforce است.

سطوح دسترسی و امتیاز CVSS

شدت این اکسپلویت به طور مستقیم به تنظیمات دسترسی کاربر بستگی دارد. در حالت پیش‌فرض، یک پنجره تأیید (Confirmation Window) ظاهر می‌شود. این یک سد کلیدی است، به این معنی که یک کلیک مصنوعی نمی‌تواند به طور خودکار و مخفیانه دسترسی به داده‌ها را به دست آورد. با این حال، این پنجره تأیید می‌تواند به گونه‌ای به کاربر نمایش داده شود که گویی یک اقدام مورد انتظار است. پژوهشگران این سناریوی خاص را با امتیاز CVSS ۷.۷ رتبه‌بندی کردند.

اما در حالت «اجرا بدون پرسش» (Act without asking)، عملیات می‌تواند بدون هیچ‌گونه دیالوگی اجرا شود. برای این پیکربندی خاص، Manifold امتیاز بحرانی ۹.۶ را اختصاص داد. تفاوت در اینجا این نیست که مدل کلود «خطرناک‌تر» شده است، بلکه مسئله این است که در لحظه اجرا، چه مقدار کنترل در دستان کاربر باقی مانده است.

رسانه The Hacker News با تحلیل ۹۰ بسته جاوااسکریپت از نسخه ۱.۰.۸۰، این نقص را به‌طور مستقل تأیید کرد. نکته مهم این است که این آسیب‌پذیری فارغ از اینکه کاربر مدل‌های Opus، Sonnet یا Fable را در نوار کناری انتخاب کرده باشد، تکرارپذیر بود. این موضوع ثابت می‌کند که راه حل، نیازمند تغییر در منطق مدیریت رویدادها و تأیید اعتماد (Trust Verification) است، نه یک به‌روزرسانی در مدل هوش مصنوعی.

ضعف‌های معماری

پژوهشگران همچنین پارامتر skipPermissions=true را شناسایی کردند. اگرچه این پارامتر مسیری معماری به سمت یک حالت ویژه (Privileged Mode) باز می‌کند، اما به عنوان یک اکسپلویت آماده برای حمله از راه دور (Remote Exploit) شناخته نمی‌شود. در مورد نسخه ۱.۰.۸۰، این مورد بیشتر به عنوان یک «ضعف معماری» توصیف شد تا یک مسیر اکسپلویت از راه دور که به‌طور مستقل تأیید شده باشد. اگرچه این مورد نیاز به اصلاح دارد، اما سطحی از ریسک را ثابت نمی‌کند که شواهد موجود بتوانند آن را پشتیبانی کنند.

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

چک‌لیست بازرسی و کاهش ریسک

برای کاهش این ریسک‌ها، باید به یک عامل مرورگر به چشم یک «کارمند دارای کارت شناسایی» نگاه کنید، نه صرفاً یک چت‌بات. از گام‌های بازرسی زیر استفاده کنید:

• پاکسازی افزونه‌ها: لیست افزونه‌های مرورگر خود را بررسی کرده و مواردی که دیگر نیاز به دسترسی به سایت‌های دارای نشست‌های کاری فعال ندارند را حذف کنید.
• غیرفعال‌سازی دسترسی سریع: گزینه «Act without asking» را برای Gmail، تقویم‌ها، سیستم‌های CRM یا اسناد غیرفعال کنید، به‌خصوص اگر اقدامات انجام شده توسط عامل، سریعاً قابل بازگشت نباشند.
• تفکیک حساب‌ها: محیط‌های آزمایشی عامل‌های هوش مصنوعی را از نشست‌هایی (Sessions) که برای ایمیل‌های کاری استفاده می‌کنید، جدا نگه دارید.
• ثبت فراخوانی ابزارها: گزارش‌های فراخوانی ابزارها (Tool-call logs) را حفظ کنید تا بتوان تفاوت بین یک درخواست کاربر و یک اجرای خودکار را تشخیص داد.

توسعه‌دهندگان رابط‌های عاملی (Agentic Interfaces) باید با رویدادهای مرورگر به عنوان ورودی‌های غیرقابل اعتماد برخورد کنند. یک دیالوگ تأیید، یک الگوی تجربه کاربری (UX) مفید است، اما نمی‌تواند کنترل امنیتی اصلی برای تأیید قصد انسان باشد. هنگامی که چندین مدل در یک فرآیند واحد عمل می‌کنند، نباید به طور خودکار مجوزهای نشست (Session Permissions) آن فرآیند را به ارث ببرند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.