Threat Signal

💻مشکلات زیادی شناسایی کردم و چند نکته به OWASP گزارش کردم :

من طی چند روز گذشته، مجموعه‌ای از تست‌ها را با تمرکز بر پرامپت اینجکشن روی مدل‌های زبانی پرکاربرد، از جمله Opus 5، انجام داده‌ام. مشاهده‌ی اصلی من این است که مدل‌ها با سرعت چشمگیری در برابر سناریوهای رایج و شناخته‌شده‌ی پرامپت اینجکشن مقاوم‌تر شده‌اند. با این حال، این به معنای از بین رفتن این آسیب‌پذیری نیست و در بسیاری از مدل‌ها و اپلیکیشن‌ها همچنان قابل بهره‌برداری است. نکته‌ی مهم‌تر این است که payloadها و سناریوهای مشخص عمر کوتاهی دارند. پرامپتی که امروز جواب می‌دهد، ممکن است با انتشار نسخه‌ی جدید مدل یا به‌روزرسانی لایه‌های محافظتی محصول دیگر کار نکند. علاوه بر این، به دلیل احتمالی بودن خروجی مدل‌ها، حتی یک پرامپت ثابت روی یک نسخه‌ی ثابت از مدل هم همیشه نتیجه‌ی یکسانی نمی‌دهد. در نتیجه، بازتولیدپذیری (Reproducibility) حمله‌ها تضمین‌شده نیست و نمی‌توان پیش‌بینی کرد که یک الگوی مشخص تا یک سال آینده همچنان مؤثر باقی بماند. این وضعیت با آسیب‌پذیری‌های سنتی تفاوت اساسی دارد. در SQL Injection می‌توان مرز میان کد و داده را به‌طور قطعی برقرار کرد (برای مثال با Parameterized Query)، و چون رفتار سیستم قطعی است، با بررسی سازوکار دفاعی می‌توان مشخص کرد که آیا قابل دور زدن است یا نه. در مدل‌های زبانی چنین مرز قطعی‌ای وجود ندارد. بنابراین موفق یا ناموفق بودن چند نمونه‌ی مشخص، مانند تلاش برای نشت System Prompt، درباره‌ی امنیت کل سیستم نتیجه‌ی قطعی به دست نمی‌دهد. پیشنهاد من این است که در LLM01، تأکید اصلی بر ریشه‌ی آسیب‌پذیری (نبودن مرز میان دستور و داده)، دسته‌بندی‌های کلی، سطوح حمله‌ی ممکن و روش ارزیابی باشد، و مثال‌ها صراحتاً به‌عنوان «الگو» معرفی شوند، نه payloadهای ماندگار. به نظر من تکیه بر سناریوهای مشخص ممکن است این برداشت نادرست را ایجاد کند که مقاوم بودن مدل در برابر همان سناریوها به معنای امن بودن سیستم است.

پ.ن:با چیزهایی که تا اینجای دوره یاد گرفته‌اید، به راحتی معنی این متن را متوجه می‌شوید. 💻@ThreatSignal