تصویر داخل پاسخ هوش مصنوعی هم اجازه ارسال می‌خواهد

کارمند پشتیبانی پاسخ دستیار را باز می‌کند. هنوز روی هیچ پیوندی نزده، اما مرورگر برای نمایش تصویرِ داخل پاسخ به یک سرور خارجی درخواست فرستاده است. اگر نشانی تصویر شناسه اختصاصی داشته باشد، صاحب آن سرور می‌تواند دریافت درخواست را به همان شناسه ربط دهد. اگر اطلاعات محرمانه در مسیر یا پارامترهای نشانی جا گرفته باشد، همان درخواست آن اطلاعات را هم می‌فرستد.

این موقعیت فرضی است، نه گزارش رخداد در ژرف. مسئله برای سازنده دستیار روشن است: کدام بخش پاسخ فقط نمایش داده شود و کدام بخش حق ایجاد ارتباط بیرونی داشته باشد؟ تصویر همیشه تزئین نیست؛ گاهی نمایش آن، یک عمل شبکه‌ای است.

سه تصمیم را پشت یک دکمه نمایش پنهان نکنید

متن معمولی، پیوند قابل کلیک و تصویر خارجی رفتار یکسانی ندارند. متن را می‌توان بدون تماس با مقصد تازه نشان داد. پیوند ساده معمولاً تا اقدام کاربر به مقصد مراجعه نمی‌کند؛ البته اگر محصول پیش‌نمایش یا پیش‌دریافت خودکار داشته باشد، این فرض دیگر درست نیست. تصویر خارجی برای نمایش به دریافت محتوا وابسته است، مگر اینکه پیش‌تر از حافظه نهان یا مسیر دیگری تأمین شده باشد.

به‌جای مجوز کلی «نمایش Markdown»، برای هر رفتار تصمیم جدا بگیرید. Markdown همان قالب متنی رایج برای عنوان، فهرست و پیوند است؛ پذیرفتن این قالب نباید به معنای پذیرفتن همه مقصدهای نوشته‌شده در آن باشد. مدل پیشنهاد می‌دهد چه چیزی نمایش داده شود؛ برنامه مسئول اجازه تماس است.

راهنمای جلوگیری از تزریق پرامپت OWASP به خطر تصویرهای جاسازی‌شده در خروجی HTML و Markdown و مسائل نمایش تدریجی اشاره می‌کند. این هشدار، نرخ وقوع حمله در محصول شما را تعیین نمی‌کند. همچنین معنایش این نیست که هر تصویر خارجی، متن کامل گفت‌وگو را دریافت می‌کند؛ باید دید دقیقاً چه نشانی و چه اطلاعاتی ارسال شده است.

مقصد درخواست با نشانی صفحه مبدأ فرق دارد

دو مسیر افشا را جدا بررسی کنید. نخست، اطلاعات همراه درخواست، مانند سرآیند ارجاع یا ویژگی‌های قابل مشاهده اتصال. دوم، اطلاعاتی که خودِ نشانی مقصد حمل می‌کند. پنهان کردن مسیر اول، محتوای مسیر دوم را حذف نمی‌کند.

طبق مرجع Referrer-Policy در MDN، مقدار no-referrer سرآیند Referer را حذف می‌کند. این تنظیم مفید است، ولی نشانی تصویر همچنان باید به سرور مقصد برسد. اگر یک شناسه خصوصی در مسیر یا بخش پرس‌وجوی آن باشد، حذف سرآیند ارجاع آن را پاک نمی‌کند. نباید از عبارت «ارجاع نمی‌فرستیم» نتیجه بگیریم «هیچ داده‌ای خارج نمی‌شود».

در بازبینی، از تیم بخواهید دو سؤال را جدا جواب دهد: دریافت‌کننده از خودِ درخواست چه می‌فهمد، و برنامه چه محتوایی را در نشانی گذاشته است؟ پاسخ دوم حتی پشت پراکسی هم اهمیت دارد. نشانی پذیرفته‌شده باید به یک دارایی مشخص و مجاز اشاره کند، نه به متنی که مدل آزادانه از گفت‌وگو ساخته است.

کتابخانه امن، مقصد تجاری را برای شما انتخاب نمی‌کند

حذف اسکریپت و جلوگیری از اجرای کد، لازم است. بااین‌حال، یک نشانی معمولی HTTPS می‌تواند برای این گفت‌وگو نامجاز باشد. امنیت نحوی خروجی و اجازه انتشار اطلاعات دو مسئله‌اند.

مستندات react-markdown توضیح می‌دهد که تبدیل پیش‌فرض نشانی، پروتکل‌هایی از جمله HTTPS را می‌پذیرد و برنامه می‌تواند عناصر و اجزای نمایش را محدود کند. همان مرجع درباره تغییر ناامن تبدیل نشانی و افزونه‌ها هشدار می‌دهد. نتیجه تحلیلی ما این است: پذیرش HTTPS را نباید تأیید گیرنده یا محتوای درخواست دانست.

این مرز شبیه مسئله تبدیل متن خروجی به فرمول صفحه‌گسترده است: رشته‌ای که در یک مرحله داده بود، در مرحله بعد رفتار تازه‌ای پیدا می‌کند. اینجا آن رفتار الزاماً اجرای اسکریپت نیست؛ ممکن است فقط دریافت تصویر باشد. بنابراین آزمون «هیچ اسکریپتی اجرا نشد» پاسخ کاملی به پرسش محرمانگی نمی‌دهد.

از تیم رابط کاربری فهرست مفسرها و افزونه‌ها را بخواهید: نمایشگر متن، سازنده کارت پیوند، بارگذار تصویر و صادرکننده گزارش. اگر یکی از آن‌ها نشانی را دوباره تفسیر کند، سیاست مرحله قبلی ممکن است دیگر کافی نباشد. تصمیم باید در آخرین نقطه پیش از ایجاد درخواست هم برقرار بماند.

برای تصویر مجاز، شناسه دارایی بدهید نه اختیار ساخت نشانی

پیشنهاد ژرف برای دستیار سازمانیِ دارای اطلاعات حساس این است که مدل از میان شناسه‌های داراییِ ازپیش‌مجاز انتخاب کند. سرور، شناسه را برای کاربر و گفت‌وگوی فعلی بررسی و به نسخه قابل نمایش تبدیل کند. شناسه حدس‌ناپذیر به‌تنهایی مجوز نیست؛ مالکیت و حق دیدن نیز باید بررسی شوند.

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

حتی دامنه مجاز نیز به‌تنهایی کافی نیست. یک میزبان ممکن است هم تصاویر سازمان را داشته باشد و هم محتوای بارگذاری‌شده توسط دیگران یا مسیرهای هدایت. اگر برنامه فقط شناسه دارایی معتبر را به مسیر ثابت تبدیل کند، اختیار مدل محدودتر از زمانی است که کل نشانی را می‌پذیرد. پارامترهای دلخواه را به مسیر مجاز نچسبانید.

پراکسی تصویر، مجوز انتشار نمی‌سازد

پراکسی می‌تواند تماس مستقیم مرورگر با میزبان تصویر را حذف کند. برای نمونه، مستندات گیت‌هاب درباره Camo پنهان کردن جزئیات مرورگر را توضیح می‌دهد، اما هشدار می‌دهد دریافت‌کننده نشانی ناشناس‌شده ممکن است تصویر را ببیند. ناشناس کردن نشانی با احراز هویت بیننده یکی نیست.

اگر نشانی خارجی خودش حامل داده محرمانه باشد، پراکسی هنگام دریافت همان نشانی آن را به مقصد می‌فرستد. پس بررسی انتشار باید قبل از تماس پراکسی انجام شود، نه پس از دانلود. یک نسخه کم‌حجم یا پاک‌سازی‌شده از تصویر، درخواست قبلی را پس نمی‌گیرد.

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

نسخه ذخیره‌شده تصویر نیز باید همان سطح محرمانگی منبع را حفظ کند. نشانی عمومیِ طولانی را جای کنترل دسترسی ننشانید. درباره مدت نگهداری، حذف، کاربران مجاز و رفتار حافظه نهان تصمیم بگیرید. اگر مجوز کاربر لغو شد، نسخه ذخیره‌شده نباید راه میان‌بری به محتوای قبلی باز کند.

تا پیش از اجازه، تصویر باید بی‌اثر بماند

اصل اجرایی ساده است: گره تصویرِ تأییدنشده نباید حتی برای یک لحظه نشانی قابل دریافت داشته باشد. ابتدا خروجی را تجزیه و درخواست‌های احتمالی را جدا کنید؛ سپس سیاست را اعمال کنید و تنها اجزای مجاز را بسازید. نمایش تصویر و پاک کردن آن چند لحظه بعد، ممکن است دیر باشد.

برای پاسخِ در حال تولید، متن بی‌اثر را نشان دهید یا نمایش اجزای دارای اثر را تا کامل شدن و بررسی نگه دارید. بررسی فقط نسخه نهایی کافی نیست. ممکن است نسخه میانی، نشانی‌ای داشته باشد که در پاسخ نهایی حذف می‌شود؛ مسئولیت محصول شامل همان فاصله کوتاه هم هست.

در کنار این کنترل، سیاست امنیت محتوا یا CSP محدودیت مستقل مرورگر می‌دهد. مرجع img-src در MDN مشخص می‌کند این دستور منابع مجاز تصویر را تعیین می‌کند و در نبود آن، default-src مبنا قرار می‌گیرد. این محدودیت، سیاست دریافت‌کننده سمت سرور نیست و جای بررسی حق دسترسی به تصویر را نمی‌گیرد.

مسیر خروجی‌های دیگر را هم بررسی کنید. شاید صفحه گفت‌وگو امن باشد، ولی سازنده PDF، ایمیل یا پیش‌نمایش دوباره تصاویر خارجی را دریافت کند. برای هر مسیر، مالک کنترل و زمان اجرای آن را مشخص کنید. راهنمای مجوز خروجی همین تصمیم درباره محتوای نهایی و گیرنده را در سطح گسترده‌تر توضیح می‌دهد.

یک پاسخ چهارقسمتی را دنبال کنید

فرض کنید پاسخ پشتیبانی چهار جزء دارد: توضیح متنی، تصویر محصول از مخزن شرکت، پیوند دفترچه عمومی سازنده و تصویر نموداری با نشانی تازه که مدل پیشنهاد داده است. این مثال ساختگی است و ادعای آزمون یک سامانه واقعی ندارد.

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

اگر کاربر نمودار را لازم بداند، برنامه نباید صرفاً یک پرسش مبهم «ادامه می‌دهید؟» نشان دهد. مقصد، نوع تماس و داده‌ای که قرار است خارج شود باید روشن باشد. در محیطی که ارسال آن داده ممنوع است، تأیید کاربر ممنوعیت را برنمی‌دارد. راه جایگزین می‌تواند رسم نمودار از داده مجاز در داخل برنامه باشد.

در این مثال، موفقیت به معنی خالی ماندن جای همه تصاویر نیست. تصویر مجاز کار می‌کند، متن خواناست و پیوند منبع حفظ شده است. تنها اختیار ساخت درخواست دلخواه از پاسخ مدل گرفته شده. هزینه این انتخاب، کاهش راحتی و گاهی نیاز به مسیر ورود تصویر است؛ فایده‌اش روشن شدن گیرنده پیش از ارسال است.

چیزی را بسنجید که واقعاً از مرز عبور می‌کند

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

تعداد تلاش‌های ردشده، دلیل رد، نسخه سیاست و شناسه داخلی رویداد را ثبت کنید. نشانی کاملِ حامل اطلاعات را برای عیب‌یابی در گزارش عمومی کپی نکنید. خودِ سامانه ثبت وقایع می‌تواند به گیرنده تازه داده حساس تبدیل شود. برای رفع اشکال، دسترسی محدود و نگهداری متناسب در نظر بگیرید.

با تغییر کتابخانه نمایش، افزونه، حافظه نهان، دامنه میزبان یا سازنده پیش‌نمایش، این آزمون‌ها را دوباره اجرا کنید. نرخ استفاده از مسیر مجاز و شکایت از تصویرهای مسدودشده را هم ببینید؛ کنترلِ مزاحمی که همه آن را دور می‌زنند پایدار نیست. راه حل، ورود روشنِ تصویر لازم است، نه باز کردن دریافت دلخواه. پرسش نهایی همیشه قبل از نمایش مطرح می‌شود: این تصویر قرار است چه درخواستی را، به کدام گیرنده و با کدام اجازه بفرستد؟

منابع و یادداشت بررسی — ۳ اکتبر ۲۰۲۶

این راهنمای معمول بلاگ است. معماری، جدول‌ها، مثال پشتیبانی و معیار آزمون، پیشنهاد تحلیلی ژرف هستند؛ نه گزارش مشتری، نه ممیزی این وب‌سایت و نه تضمین امنیت یک پیاده‌سازی. منابع از OWASP، پروژه remark، موزیلا و گیت‌هاب‌اند. برای مستندات زنده بدون تاریخ انتشار روشن، تاریخ بررسی را ملاک قرار داده‌ایم.

• OWASP — جلوگیری از تزریق پرامپت: مستند زنده؛ بخش تزریق HTML و Markdown در تاریخ بالا بررسی شد.
• remark — مستندات react-markdown: مستند زنده شاخه اصلی؛ تبدیل نشانی، محدودیت عناصر و ملاحظات امنیتی بررسی شد.
• MDN — Referrer-Policy: آخرین تغییر نمایش‌داده‌شده ۴ سپتامبر ۲۰۲۶؛ محدوده اثر سرآیند ارجاع.
• MDN — دستور img-src: آخرین تغییر نمایش‌داده‌شده ۴ ژوئیه ۲۰۲۵؛ محدودیت منابع تصویر در مرورگر.
• GitHub — نشانی‌های ناشناس‌شده: مستند زنده؛ رفتار Camo و محدودیت محرمانگی نشانی بررسی شد.