تصور کنید ردیفی از داده‌های به‌ظاهر بی‌خطر در CRM شما، در واقع یک نقطه ورود مرگبار برای یک مهاجم باشد. در ۲۴ سپتامبر ۲۰۲۶، Zenity Labs از آسیب‌پذیری SalesBleed در سامانه Agentforce متعلق به Salesforce پرده برداشت تا ثابت کند تزریق پرامپت (Prompt Injection) برای اثرگذاری، لزوماً به یک پنجره چت نیاز ندارد. این کشف فاش می‌کند که مورد اعتمادترین منبع داده‌های عامل هوش مصنوعی شما، احتمالاً بزرگ‌ترین حفره امنیتی آن است.
بسیاری از تیم‌های امنیتی با تزریق پرامپت مانند یک دوئل لحظه‌ای بین کاربر و چت‌بات برخورد می‌کنند. آن‌ها فیلترهایی را در پنجره ورودی می‌سازند و تصور می‌کنند تهدید خنثی شده است. اما SalesBleed میدان نبرد را از گفتگو به پایگاه‌داده منتقل می‌کند؛ جایی که دستورات مخرب می‌توانند روزها به‌صورت خاموش منتظر فعال شدن بمانند. در این سناریو، حامل حمله دیگر یک پیام یا گفتگو نیست، بلکه خودِ CRM است. این رویکرد تهاجمی یادآور روش‌های پنهان‌سازی دستورات است، مشابه آنچه در حمله از طریق متن‌های نامرئی در ایمیل‌ها برای نشت داده‌های مشتریان مشاهده شد.
این اتفاق در حالی رخ می‌دهد که سازمان‌ها با عجله در حال متصل کردن مدل‌های زبانی بزرگ (LLM) به سوابق تجاری اصلی خود هستند. صنعت تا حد زیادی مشکل «نایب سردرگم» (Confused Deputy) در لایه‌ی ذخیره‌سازی را نادیده گرفته است؛ یعنی این فرض غلط که داده‌های بازیابی‌شده از یک CRM مورد اعتماد، ذاتاً برای پردازش به عنوان دستورالعمل ایمن هستند. یک مدل زبانی به‌طور پیش‌فرض مرزی بین «داده» و «دستور» نمی‌شناسد.
مکانیسم عملکرد SalesBleed
به نقل از گزارش Zenity Labs، این حمله با قابلیتی آغاز می‌شود که تقریباً تمام مشتریان Salesforce از آن استفاده می‌کنند: Web-to-Lead. این ویژگی به افراد خارجی اجازه می‌دهد داده‌ها را از طریق فرم‌های عمومی ارسال کنند که مستقیماً وارد سوابق CRM می‌شود. در واقع هدف فرم‌های جذب مشتری دقیقاً همین است: پذیرش ورودی از غریبه‌ها.
مهاجم به‌سادگی یک فرم را با یک محموله (Payload) مخرب تزریق پرامپت پر می‌کند. در این فرآیند، هیچ کارمندی روی لینکی کلیک نمی‌کند و هیچ‌کس با عامل تعامل ندارد. این محموله در یک ردیف از پایگاه‌داده می‌ماند و مانند یک متن معمولی به نظر می‌رسد تا زمانی که یک عامل Agentforce مورد اعتماد، در حین انجام وظیفه‌ای روتین (مثلاً «غنی‌سازی این لید» یا enrich this lead)، آن را بخواند.
Zenity سه نقص مشخص را در ۲۴ سپتامبر ۲۰۲۶ افشا کرد. شایان ذکر است که Salesforce در ۱ ژوئن ۲۰۲۶ به‌طور خصوصی مطلع شده و نقص‌های گزارش‌شده را ظرف حدود دو هفته برطرف کرده است. این روند نشان‌دهنده عملکرد درست فرآیند افشای مسئولانه است: یک پژوهشگر نقص را می‌یابد، آن را به‌طور خصوصی گزارش می‌کند و فروشنده آن را اصلاح می‌کند.
- استخراج داده بدون کلیک (Zero-Click Exfiltration): دو مورد از این سه آسیب‌پذیری اجازه می‌دادند داده‌های حساس CRM بدون هیچ‌گونه تایید یا کلیک انسانی، به زیرساخت‌های تحت کنترل مهاجم ارسال شوند.
- سلاح‌سازی از هویت (Identity Weaponization): نقص سوم به مهاجم اجازه می‌داد از هویت مورد اعتماد یک عامل متصل به Slack استفاده کند تا پیام‌های فیشینگ داخلی را از درون سازمان برای کارمندان ارسال نماید.
شکست در «درِ خروجی»
اگر تزریق پرامپت نقطه ورود است، استخراج داده جایی است که دفاع واقعاً فروپاشید. Agentforce از مکانیزم «URLهای مورد اعتماد» (Trusted URLs) استفاده می‌کند؛ یک لیست سفید (Allowlist) که برای محدود کردن مقاصد ارسال داده توسط عامل‌ها طراحی شده است.
Zenity کشف کرد که این لایه تجزیه (Parsing) به‌طور بنیادی معیوب است. این مکانیزم نمی‌توانست دامنه‌های سطح بالا (TLD) را به‌درستی شناسایی کند و در برابر توالی‌های خاصی از کاراکترها که باعث دستکاری در تجزیه URL می‌شد، آسیب‌پذیر بود. این نقص اجازه داد داده‌ها از لیست سفید عبور کرده و به مقاصدی که مهاجم کنترل می‌کرد، برسند.
تجزیه در برابر سیاست
مدل دقیقاً طبق طراحی عمل کرد؛ متن را خواند و دستورات را اجرا نمود. اما سیستم نتوانست بین داده و فرمان تمایز قائل شود. نقص اصلی این فرض بود که متن فرم‌های لید، «داده» است نه «دستور».
این یک تمایز حیاتی است: شکست در لیست سفید، یک شکست در «تجزیه» (Parsing) بود، نه شکست در «سیاست» (Policy). سیاست درست بود و می‌گفت داده‌ها فقط به سایت‌های مورد اعتماد بروند، اما کدی که آن را اجرا می‌کرد نمی‌توانست evil-example.com را از آنچه فکر می‌کرد مجاز است، تشخیص دهد. لایه‌های تجزیه جایی هستند که دفاع‌ها به‌آرامی می‌میرند.
مثلث مرگبار
پژوهشگران امنیتی با استناد به چارچوبی که Simon Willison در ۱۶ ژوئن ۲۰۲۵ معرفی کرد، این وضعیت را «مثلث مرگبار» می‌نامند. یک عامل زمانی به‌طور ساختاری آسیب‌پذیر می‌شود که سه ویژگی زیر را هم‌زمان داشته باشد:
۱. دسترسی به داده‌های خصوصی و حساس: عامل می‌تواند سوابق CRM را بخواند.
۲. در معرض محتوای غیرقابل اعتماد: عامل داده‌ها را از فرم‌های عمومی لید دریافت می‌کند.
۳. راهی برای ارتباط خارجی: عامل می‌تواند برای ارسال اعلان‌ها یا پیگیری‌ها به شبکه متصل شود.
حذف هر یک از این ضلع‌ها حمله را کند می‌کند. اما برای یک عامل «غنی‌سازی لید»، هر سه مورد ضروری هستند. بدون دسترسی به CRM، او فقط یک جعبه جست‌وجو است؛ بدون دسترسی خارجی، نمی‌تواند کارش را انجام دهد و بدون دریافت لیدها، اصلاً هدفی ندارد. ترکیب این سه، همان محصول است. هیچ‌کس برای راحتی بازبین‌های امنیتی، یکی از این ضلع‌ها را حذف نمی‌کند، بنابراین راهکار باید ایجاد مرزهای سخت در اطراف این ترکیب باشد، نه حذف یکی از قابلیت‌ها.
خط لوله حمله
برای درک خطر، باید حمله را به عنوان یک خط لوله دید که در آن محموله ابتدا می‌رسد و سپس منفجر می‌شود:
[فرم عمومی لید: هر کسی می‌تواند بنویسد] -> [سوابق CRM: متن مهاجم ساکت و معمولی می‌ماند] -> [عامل مورد اعتماد ردیف را می‌خواند: «این لید را غنی کن»] -> [لیست سفید URLها: تجزیه نادرست TLDها و دستکاری با توالی کاراکترها] -> [استخراج داده به زیرساخت مهاجم / فیشینگ در Slack با هویت مورد اعتماد]
سه نکته اینجا حیاتی است: اول، شکاف زمانی؛ مهاجم نیازی ندارد هنگام اجرای دستور توسط عامل حضور داشته باشد. دوم، شکست در لایه تجزیه است، نه شکست در سیاست. سوم، وقتی «نایب» سردرگم شود، تمام قابلیت‌های او — از جمله هویت مورد اعتماد در Slack — به قابلیت‌های مهاجم تبدیل می‌شود. این همان مشکل نایب سردرگم در لباسی جدید است؛ مهاجم هرگز به دسترسی شخصی نیاز نداشت، بلکه فقط به دستوراتی در برابر نایبی نیاز داشت که نمی‌توانست تشخیص دهد دستورات متعلق به کیست.
مهندسی یک دفاع پایدار
برای توقف این حملات، توسعه‌دهندگان باید دست از تکیه بر قضاوت مدل برای جداسازی داده از دستور بردارند. Zenity یک رویکرد فنی دوگانه پیشنهاد می‌کند:
۱. برچسب‌گذاری منشأ (Provenance Tagging)
هر فیلدی که عامل می‌خواند باید برچسبی داشته باشد که منشأ آن را مشخص کند. فیلدهای منابع خارجی باید به‌طور پیش‌فرض «غیرقابل اعتماد» علامت‌گذاری شوند. اعتماد با «بی‌گناه به نظر رسیدن» به دست نمی‌آید، بلکه از طریق یک کانال تأیید شده، مانند بررسی انسانی یا یک سیستم داخلی، حاصل می‌شود.
- اجرای مرزی: بررسی باید در مرز ابزار (Tool Boundary) باشد، نه داخل مدل. مدل هر چقدر می‌خواهد تاثیرپذیر باشد، اما «دروازه» تصمیم می‌گیرد چه چیزی دستور محسوب شود.
- گزارش به‌جای حذف: اگر فیلدی غیرقابل اعتماد حاوی متونی شبیه دستور (مانند "ignore previous"، "disregard"، "send to"، "http://"، "https://" یا "exfiltrate") بود، سیستم باید آن را برای بررسی علامت‌گذاری کند. حمله‌ای که مسدود شده اما هرگز گزارش نشده، یک منبع اطلاعاتی تهدید هدر رفته است.
- پیاده‌سازی: در حالی که بررسی‌های ساده کلمات کلیدی یک شروع است، سیستم‌های عملیاتی باید از طبقه‌بندها (Classifiers)، بررسی فاصله بردار معنایی (Embedding Distance) یا طرح‌های خروجی ساختاریافته (Structured-output schemas) استفاده کنند که متن آزاد را در جایی که دستورات قرار دارند، ممنوع می‌کند. هدف، برچسب‌گذاری منشأ به همراه مرزی است که اجازه نمی‌دهد داده‌ها به جایگاه دستور ارتقا یابند.
۲. تجزیه سخت‌گیرانه خروجی (Strict Egress Parsing)
لیست‌های سفید تنها به اندازه تجزیه‌کننده‌هایشان (Parsers) کارآمد هستند. تیم‌ها باید بررسی URLهای خروجی را با همان سخت‌گیریِ کدهای احراز هویت انجام دهند. یک شکست در تجزیه باید به معنای «رد کردن» (Deny) باشد، نه نادیده گرفتن.
- رد Userinfo: هر URLی که از ترفندهایی مثل
https://[email protected]/استفاده می‌کند (جایی که فیلد userinfo برای فریب تجزیه‌کننده به کار می‌رود)، باید رد شود. - یکسان‌سازی (Canonicalization): اجبار به حروف کوچک دقیق و رد نقاط انتهایی (مانند
ALLOWED.COM./) برای حذف کل دسته ناهماهنگی‌های نرمال‌سازی، به‌جای تلاش برای فهرست کردن تک‌تک آن‌ها. - بررسی IDNA/Punycode: اجبار دامنه‌های غیر ASCII به بررسی دستی به‌جای پذیرش خاموش، برای جلوگیری از دامنه‌های مشابه (Lookalike) مانند
xn--allowed-9nf.com. - تست خصمانه: یک لیست سفید بدون مجموعه تست از URLهای خصمانه، صرفاً یک «امید» است، نه یک دفاع. تست‌ها باید شامل طرح‌های اشتباه (http در برابر https)، زیردامنه‌های مهاجم (مانند
allowed.com.evil.com) و مشابه‌های Punycode باشند. Zenity در همان چرخه افشا، فیلترها را با محموله‌های مبهم شکست داد، که این سطح از سخت‌گیری را برای تست‌ها ضروری می‌کند.
محدودیت‌های راهکار
حتی با این دروازه‌ها، ریسک‌هایی باقی می‌ماند. برچسب‌گذاری منشأ نمی‌تواند جلوی یک شریک هک‌شده، یک کارمند بدخواه یا یک منبع داده آلوده را بگیرد که از قبل برچسب «مورد اعتماد» دارد. منشأ تنها به اندازه بهداشت منبع (Source Hygiene) کارآمد است.
علاوه بر این، مهاجمان مصمم همچنان می‌توانند از مقاصد مجاز برای نشت داده استفاده کنند. این کار می‌تواند از طریق کوئری‌های DNS به یک resolver تایید شده، پنهان کردن داده‌ها در پیام‌های خطا، استفاده از پیکسل‌های تصویر یا به‌کارگیری کانال‌های زمانی (Timing Channels) انجام شود. یک لیست سفید خروجی را تنگ‌تر می‌کند، اما آن را کاملاً نمی‌بندد.
در نهایت، بررسی IDNA ابزاری سخت‌گیرانه است. دامنه‌های بین‌المللی قانونی علامت‌گذاری شده و به بررسی دستی می‌روند که این خود باعث ایجاد تیکت‌های پشتیبانی می‌شود. شما باید این قانون را با ترافیک واقعی خود تنظیم کنید یا پذیرای این تیکت‌ها باشید.
تایید انسانی در اقدامات حساس، ویژگی «بدون کلیک» را از بین می‌برد، اما «خستگی از تایید» (Approval Fatigue) اغلب دکمه تایید را به یک واکنش رفلکسی تبدیل می‌کند. اگر تاییدکنندگان بدون بررسی کلیک کنند، شما فقط تأخیر ایجاد کرده‌اید، نه امنیت. تشخیص کلمات کلیدی در مرز ابزار یک سیم‌کشی هشدار است، نه یک دیوار؛ یک مهاجم صبور به‌سادگی متن را بازنویسی (Paraphrase) می‌کند.
چه زمانی پیاده کنیم و چه زمانی رها کنیم
این دفاعات را پیاده کنید اگر: عامل شما ردیف‌ها، تیکت‌ها، ایمیل‌ها یا اسنادی را می‌خواند که توسط افرادی خارج از مرز اعتماد شما نوشته شده‌اند و عامل شما دسترسی به شبکه دارد. این همان مثلث مرگبار است که لوگوی شرکت شما را بر تن کرده و SalesBleed رسیدِ این خطر است.
این موارد را نادیده بگیرید اگر: عامل شما فقط به سوالات بر اساس متنی که بازیابی شده پاسخ می‌دهد و هیچ ابزاری ندارد، دسترسی نوشتن ندارد و هیچ مسیر شبکه‌ای را در اختیار ندارد. در این صورت، مشکل شما کیفیت پاسخ است، نه استخراج داده، و این دروازه‌ها ماشین‌آلاتی بدون تهدید هستند.
نسخه حداقلی این راهکار در یک بعدازظهر قابل پیاده‌سازی است: یک تابع خروجی با لیست سفید دقیقِ نام میزبان (Exact-hostname)، یک فایل تست از URLهای خصمانه که در CI اجرا شود و یک خط لاگ برای هر تلاش مسدود شده. این لاگ‌ها را برای یک هفته بررسی کنید تا بفهمید عامل شما واقعاً سعی دارد به کجا متصل شود؛ این ارزان‌ترین مدل تهدیدی است که تا به حال ساخته‌اید. برچسب‌گذاری منشأ در مرحله دوم می‌آید، یعنی بعد از آنکه لاگ‌ها به شما گفتند کدام فیلدها ارزش برچسب‌گذاری دارند.
در نهایت، SalesBleed فقط داستان Salesforce نیست. این یک حالت شکست کلاسیک برای هر عاملی است که به داده‌های واقعی تجاری متصل شده است. خطر در شکاف بین سیاستی است که می‌گوید «فقط به سایت‌های مورد اعتماد ارسال کن» و تجزیه‌کننده‌ای است که نمی‌تواند یک سایت مورد اعتماد را از یک مشابه تشخیص دهد. دروازه خروجی را بسازید، آن را با URLهای خصمانه تغذیه کنید، فیلدها را هنگام ورود برچسب‌گذاری کنید و اجازه ندهید داده‌ها در مرز ابزار به دستور تبدیل شوند. سپس لاگ‌ها را بخوانید، آنچه عاملتان تلاش می‌کند را اندازه‌گیری کنید و بر اساس داده‌ها تصمیم بگیرید که آیا مشکل شما یک فیلتر است یا یک مشکل معماری. عجیب‌ترین مقصدی که عامل شما تا به حال سعی کرده به آن برسد چه بوده است، و آیا چیزی جلوی آن را گرفت؟
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو