شکاف امنیتی در کدهای هوش مصنوعی؛ چرا تست‌های عملکردی کافی نیستند؟

تصور کنید کدی را به محیط عملیاتی می‌برید که تمام تست‌های شما را با موفقیت پشت سر داده است، اما در واقع یک درِ باز برای هکرهاست. این دقیقاً همان اتفاقی است که برای یک نقطه انتهایی (Endpoint) آپلود فایل رخ داد که توسط MonkeyCode تولید شده بود.

طبق گزارش منتشرشده در ۲۱ اوت ۲۰۲۶، این کد تمام سناریوهای پیش‌بینی‌شده در مجموعه تست‌های خود را به درستی اجرا می‌کرد؛ فایل‌های معتبر را می‌پذیرفت، حجم‌های غیرمجاز را رد می‌کرد و کدهای وضعیت (Status Codes) صحیحی برای هر سناریو برمی‌گرداند. اما یک بررسی امنیتی ساده و ۱۵ دقیقه‌ای با استفاده از یک چک‌لیست، یک آسیب‌پذیری «پیمایش مسیر» (Path Traversal) را افشا کرد. این نقص امنیتی به مهاجم اجازه می‌داد هر فایلی را در هر جای سرور بنویسد و به طور بالقوه حتی منطق اصلی برنامه را بازنویسی و جایگزین کند.

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

شکاف میان عملکرد و امنیت

در یک سناریوی رایج، برنامه‌نویس «مسیر خوش‌بینانه» (Happy Path) را تست می‌کند؛ مثلاً بررسی می‌کند که آیا عکس‌ها درست آپلود می‌شوند یا فایل‌های PDF حجیم رد می‌شوند. کد تولیدشده توسط هوش مصنوعی زاینده (Generative AI) — که شبیه نویسنده‌ای است که قواعد گرامری را عالی بلد است اما لزوماً حقیقت را نمی‌گوید — در این موارد بی‌نقص عمل می‌کند. اما برنامه‌نویس به‌ندرت نام فایلی مثل ../../etc/cron.d/evil را تست می‌کند. دلیل این امر آن است که تست‌های عملکردی می‌پرسند «آیا کد کار می‌کند؟»، اما بررسی‌های امنیتی می‌پرسند «آیا کد قابل سوءاستفاده است؟».

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

کالبدشکافی آسیب‌پذیری

این حفره امنیتی به این دلیل ایجاد شد که کد تولیدشده، نام فایل ارسالی توسط کاربر را مستقیماً در یک مسیر فایل به کار می‌برد. کد در ابتدا بسیار ساده، فشرده و بی‌خطر به نظر می‌رسید:

@app.post("/upload")
def upload_file(request):
    filename = request.form["filename"]
    content = request.files["file"].read()
    with open(f"/uploads/{filename}", "wb") as f:
        f.write(content)
    return {"status": "ok"}

این کد سه مرحله ساده را طی می‌کرد: اول نام فایل را از فرم درخواست می‌گرفت، سپس محتوای فایل را می‌خواند و در نهایت از یک رشته فرمت‌شده f"/uploads/{filename}" برای نوشتن فایل روی دیسک استفاده می‌کرد.

یک مهاجم می‌توانست با ارسال درخواستی با نام فایلی مانند ../../tmp/pwned از این کد سوءاستفاده کند. این کار باعث می‌شود برنامه از دایرکتوری مورد نظر یعنی /uploads/ خارج شود. بسته به سطح دسترسی‌های سرور، درخواستی مانند ../../app/main.py می‌توانست مستقیماً منطق هسته برنامه را بازنویسی کند. این نوع دسترسی‌های غیرمجاز به سیستم‌فایل، اهمیت پیاده‌سازی مکانیزم‌های نظارتی را دوچندان می‌کند؛ مشابه آنچه در بررسی فایل‌های تله برای سنجش امنیت محیط‌های ایزوله مورد بحث قرار گرفت.

چارچوب امنیتی ۱۵ دقیقه‌ای

برای مقابله با این مشکل، گزارش مذکور یک چک‌لیست سریع برای بررسی نقاط انتهایی تولیدشده توسط AI پیشنهاد می‌دهد. این فرآیند روی کلاس‌های رایج آسیب‌پذیری تمرکز دارد که مدل‌های AI معمولاً نادیده می‌گیرند. هر مورد در این لیست به یک الگوی کدنویسی مشخص اشاره دارد. برای مثال، بررسی مدیریت مسیر به طور خاص به دنبال فراخوانی‌های open()، os.path.join() یا Path() می‌گردد که شامل متغیرهای مشتق شده از داده‌های درخواست کاربر باشند.

• اعتبارسنجی ورودی: آیا هر مقدار ارسالی توسط کاربر با یک لیست مجاز (Allowlist) چک می‌شود؟
• مدیریت مسیر: آیا هر ورودی کاربر می‌تواند روی مسیر فایل اثر بگذارد؟
• پرس‌وجوهای SQL: آیا تمام کوئری‌ها پارامتریک هستند و هیچ اتصال رشته‌ای (String Concatenation) وجود ندارد؟
• اجرای دستورات: آیا هر ورودی کاربر می‌تواند به یک دستور شل (Shell Command) برسد؟
• احراز هویت و مجوزها: آیا نقطه انتهایی توسط یک بررسی احراز هویت محافظت شده است و آیا کد تایید می‌کند که کاربر مالک آن منبع است؟
• پیام‌های خطا: آیا شکست‌ها باعث نشت Stack Traceها یا مسیرهای داخلی سرور می‌شوند؟
• وابستگی‌ها و اسرار: آیا تمام پکیج‌ها به نسخه‌های مشخصی متصل (Pinned) شده‌اند و آیا اعتبارنامه‌ای در سورس کد به صورت سخت‌افزاری (Hardcoded) قرار دارد؟
• محدودیت نرخ (Rate Limiting): آیا یک مهاجم می‌تواند بدون هیچ پیامدی به طور مداوم به نقطه انتهایی حمله کند؟

پیاده‌سازی اصلاحیه

راه حل در پاک‌سازی نام فایل و اعتبارسنجی پسوندهاست. با استفاده از Path(request.form["filename"]).name در کتابخانه pathlib پایتون، هرگونه اجزای دایرکتوری از نام فایل حذف می‌شود. همچنین افزودن یک لیست مجاز برای پسوندهایی مثل .jpg یا .pdf تضمین می‌کند که فقط انواع فایل‌های تاییدشده ذخیره شوند.

from pathlib import Path
ALLOWED_EXTENSIONS = {".jpg", ".png", ".pdf"}

@app.post("/upload")
def upload_file(request):
    filename = Path(request.form["filename"]).name
    if Path(filename).suffix not in ALLOWED_EXTENSIONS:
        return {"error": "invalid extension"}, 400
    content = request.files["file"].read()
    with open(f"/uploads/{filename}", "wb") as f:
        f.write(content)
    return {"status": "ok"}

خودکارسازی غربالگری

برای تیم‌هایی که از خط لوله‌های CI/CD استفاده می‌کنند، یک اسکریپت ساده شل می‌تواند اولین خط دفاعی باشد. این اسکریپت با استفاده از grep الگوهای خطرناک را در ثانیه‌ها پیدا می‌کند:

• اتصال رشته در SQL: جست‌وجوی کلمه SELECT در ترکیب با علامت + یا f-strings در فایل‌های .py.
• دسترسی ناامن به فایل: شناسایی توابع open() که از متغیرهای مشتق شده از request ،form ،args یا داده‌های json استفاده می‌کنند.
• اجرای شل: جست‌وجوی فراخوانی‌های subprocess یا os.system که از اتصال رشته‌ها یا f-strings استفاده می‌کنند.
• اسرار سخت‌افزاری: شناسایی الگوهایی مثل password = '...' یا api_key = '...' در حالی که فراخوانی‌های os.environ یا getenv را نادیده می‌گیرد.

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

نقش ابزارهای رایگان

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

افشا: این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصولات MonkeyCode تهیه شده است. سرور رایگان این پلتفرم، اسکریپت غربالگری CI را برای پروژه‌های جانبی و تیم‌های کوچک کاربردی می‌کند. اسکنی که در چند ثانیه اجرا شود و هزینه‌ای نداشته باشد، اسکنی است که روی هر Pull Request اجرا خواهد شد.

محدودیت‌های چک‌لیست

این روش یک «کف» امنیتی ایجاد می‌کند، نه یک «سقف». این متد خطاهای پیچیده در منطق کسب‌وکار (Business Logic)، شرایط رقابتی (Race Conditions) یا مسائلی که نیاز به دانش عمیق دامنه دارند را پوشش نمی‌دهد. همچنین اسکریپت‌های خودکار مبتنی بر الگو هستند، به این معنی که هر چیزی را که با الگوهای شناخته‌شده مطابقت نداشته باشد از دست می‌دهند و ممکن است نتایج مثبت کاذب (False Positives) تولید کنند.

علاوه بر این، این رویکرد فرض می‌کند که بازبین کلاس‌های آسیب‌پذیری را می‌شناسد. کسی که نمی‌داند «پیمایش مسیر» چیست، نمی‌تواند قضاوت کند که آیا کد آسیب‌پذیر است یا خیر، زیرا یک چک‌لیست نمی‌تواند آن دانش را آموزش دهد. این چالش در استقرار ابزارهای مدرن نیز دیده می‌شود؛ برای مثال، بسیاری از استقرارهای پروتکل MCP به دلیل حفره‌های امنیتی شدید با ریسک‌های مشابهی روبرو هستند.

برای برنامه‌های با ریسک بالا — مانند سامانه‌های پرداخت یا پلتفرم‌های بهداشت و درمان — یک چک‌لیست کافی نیست. این سیستم‌ها همچنان به تست نفوذ (Penetration Testing) حرفه‌ای، مدل‌سازی رسمی تهدیدات و بازبینی امنیتی توسط متخصصان نیاز دارند.

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

گام بعدی شما

• تمام نقاط انتهایی (Endpoints) که توسط AI تولید شده‌اند را با چک‌لیست مسیر فایل‌ها و SQL بازبینی کنید.
• یک اسکریپت grep ساده برای شناسایی open() و subprocess در خط لوله CI/CD خود قرار دهید.
• برای کدهای حساس، از مدل‌های استدلالی با پرامپت‌های «تیم قرمز» (Red Teaming) برای یافتن حفره‌ها استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.