با گسترش ابزارهای ساخت وبسایت مبتنی بر هوش مصنوعی (AI app-builders) و پلتفرمهای بدون کدنویسی (No-code)، یک آسیبپذیری امنیتی ناشی از پیکربندی نادرست شناسایی شده است که میتواند منجر به افشای کلیدهای حساس و اعتبارنامههای حیاتی در کدهای سمت کلاینت (Client-side code) شود.
الگوهای افشای اعتبارنامهها
تحقیقات نشان میدهد که مهاجمان میتوانند با بررسی ساده کدهای فرانتاند (Front-end) وبسایتها، به منابع حساس دسترسی پیدا کنند. دو الگوی اصلی در این زمینه مشاهده شده است:
- جایگذاری مستقیم کلیدهای LLM: برخی از سایتها که توسط هوش مصنوعی ساخته شدهاند، کلیدهای API مربوط به مدلهای زبانی (مانند OpenAI) را مستقیماً در بستههای جاوااسکریپت خود قرار میدهند. این امر به مهاجم اجازه میدهد تا از اعتبار مالی و سهمیه (Quota) حساب صاحب سایت برای اجرای درخواستهای خود استفاده کند.
- الگوی کپی و افشا (Clone-and-leak): در این حالت، اپراتورها یک قالب (Template) آماده که حاوی کلیدهای حساس است را در دهها دامنه مختلف کپی میکنند. در نتیجه، یک کلید حساس (مانند Webhook مربوط به Slack یا کلید Stripe) در تمام این دامنه به صورت عمومی در دسترس قرار میگیرد.
انواع دادههای افشا شده و پیامدهای امنیتی
بررسیها نشان داد که انواع مختلفی از اعتبارنامهها در معرض خطر هستند:
- کلیدهای Stripe: افشای کلیدهای مخفی (Secret keys) در Stripe به مهاجم اجازه میدهد تا تراکنشها را مدیریت کرده، بازپرداختها (Refunds) انجام دهد و به دادههای مشتریان دسترسی پیدا کند.
- توکنهای Supabase: افشای توکنهای service-role JWT به مهاجم اجازه میدهد تا تمامی محدودیتهای امنیتی سطح ردیف (Row-level security) را دور زده و به پایگاه داده دسترسی کامل (خواندن و نوشتن) داشته باشد.
- وبهوکهای Slack: این کلیدها امکان ارسال پیامهای خودسرانه به کانالهای داخلی سازمان را فراهم میکنند که میتواند برای حملات فیشینگ داخلی (Internal Phishing) استفاده شود.
- کلیدهای AWS و GitHub: این موارد دسترسی به زیرساختهای ابری و مخازن کد منبع را برای مهاجم فراهم میکند.
توصیههای امنیتی برای توسعهدهندگان و تیمهای SOC
برای جلوگیری از این نوع افشا، رعایت نکات زیر ضروری است:
- استفاده از سمت سرور: تمامی کلیدهای حساس (مانند sk- برای OpenAI یا کلیدهای Stripe) باید حتماً در توابع سمت سرور (Server-side functions) یا جریانهای کاری بکاند (Backend workflows) نگهداری شوند و هرگز در فیلدهای قابل دسترس توسط کلاینت قرار نگیرند.
- استفاده از کلیدهای عمومی: در سمت فرانتاند تنها از نسخههای عمومی و محدود شده (مثل Publishable keys) استفاده کنید.
- چرخش کلیدها (Key Rotation): هر کلیدی که احتمال میرود در کدهای سمت کلاینت قرار گرفته باشد، باید بلافاصله باطل و کلید جدید جایگزین شود.
- مانیتورینگ: تیمهای امنیت باید کدهای عمومی و دامنههای جدید ثبت شده را برای یافتن کلیدهای حساس و Webhookهای سازمان مانیتور کنند.