لینک عمومی نباید دستیار هوش مصنوعی را به شبکه داخلی ببرد

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

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

اول معلوم کنید قرار است چه چیزی خوانده شود

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

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

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

یک تغییر مسیر، تصمیم را از نو باز می‌کند

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

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

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

پذیرفته‌شدن نشانی، حکم امنیتی نیست

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

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

یکسان‌سازی نام میزبان فقط یک تعریف داشته باشد. مقایسه با نام دقیق یا زیردامنه دارای مرز درست انجام شود؛ شباهت انتهای رشته کافی نیست. نام‌های بین‌المللی هم از همان تبدیل نامی عبور کنند که لایه اتصال استفاده می‌کند. آشنابودن ظاهر نام برای بازبین، امتیاز دسترسی نمی‌سازد.

در ادامه، همان درخواست ساختاریافته و تأییدشده را به لایه بعد بدهید. نشانی را دوباره از رشته خام مدل نسازید. اگر کتابخانه HTTP، پراکسی یا بخش هدایت، رشته را به شکل دیگری تفسیر کند، بررسی اول شاید مربوط به درخواست دیگری باشد. طرح‌های پشتیبانی‌نشده رد شوند؛ ابزار خواندن گزارش نباید نشانی را به فایل محلی یا فرمان یک پروتکل دلخواه تبدیل کند.

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

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

فهرست نشانی‌های ویژه IPv4 در IANA و فهرست IPv6، نوع و ویژگی دامنه‌های نشانی را ثبت می‌کنند. این دو، داده مرجع‌اند نه فهرست مجوزهای سازمان شما. دسترس‌پذیری جهانی یک نشانی، مجوز تماس نیست؛ خدمت خصوصی نیز گاهی در فضای شماره‌گذاری عمومی قرار دارد.

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

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

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

هدایت خودکار و اعتبارنامه را بی‌صدا همراه نکنید

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

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

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

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

نداشتن کلید در محیط، برای جداسازی کافی نیست

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

مستندات IMDSv2 آمازون، دسترسی نشست‌محور با توکن و امکان اجباری‌کردن نسخه دوم را شرح می‌دهد. مستندات فراداده ماشین مجازی Azure وجود سرآیند فراداده را لازم می‌داند و درخواست دارای سرآیند X-Forwarded-For را نمی‌پذیرد؛ در عین حال، خود API را بدون احراز هویت و در دسترس پردازه‌های ماشین معرفی می‌کند. این دو سازوکار یکسان نیستند. سرآیند لازم، مجوز مختص یک کاربر نیست.

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

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

فایل دریافت‌شده هنوز حق دستور دادن ندارد

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

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

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

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

در آزمون، تلاش برای اتصال را بشمارید

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

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

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

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

رد اتصال را ثبت کنید، نه رازهای همراه نشانی را

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

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

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

قاعده کار کوتاه است: مدل منبع را پیشنهاد می‌دهد، سیاست مسیر دسترسی را انتخاب می‌کند و مجری شبکه مقصد را محدود می‌کند. این مسئولیت‌ها حتی برای درخواست ساده «این لینک را بخوان» باید جدا بمانند.

یادداشت منابع — بررسی‌شده در ۲۱ سپتامبر ۲۰۲۶

• OWASP، راهنمای پیشگیری از SSRF؛ راهنمای جاری بدون تاریخ مشخص، مراجعه در روز بررسی.
• WHATWG، استاندارد نشانی وب؛ استاندارد زنده با تاریخ به‌روزرسانی نمایانِ ۱۰ سپتامبر ۲۰۲۶.
• IANA، فهرست نشانی‌های ویژه IPv4؛ به‌روزرسانی ۹ اکتبر ۲۰۲۵.
• IANA، فهرست نشانی‌های ویژه IPv6؛ به‌روزرسانی ۹ اکتبر ۲۰۲۵. این دو فهرست، سیاست مجوز اختصاصی سازمان نیستند.
• IETF، سند RFC 9110؛ معنای HTTP، ژوئن ۲۰۲۲؛ به‌ویژه بخش ۱۵٫۴ درباره هدایت.
• آمازون، تنظیم خدمت فراداده نمونه؛ مستندات جاری محصول، بدون تاریخ مشخص.
• مایکروسافت، خدمت فراداده Azure؛ به‌روزرسانی ۲۹ ژوئیه ۲۰۲۵. تفکیک ابزارها، جدول‌ها، مسیر فرضی و پیشنهادهای سنجش، تحلیل ژرف‌اند؛ نه گواهی فروشنده یا نتیجه اندازه‌گیری مشتری.