خطرات پنهان هوش مصنوعی در تولید کد؛ از آسیب‌پذیری‌ها تا سوءاستفاده

خطرات پنهان هوش مصنوعی در تولید کد؛ از آسیب‌پذیری‌ها تا سوءاستفاده

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

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

کدنویسی شهودی (Vibe Coding) و آسیب‌پذیری‌های امنیتی

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

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

گزارشگر وضعیت MQTT: مثالی از آسیب‌پذیری‌های ساده

برای شروع، از ChatGPT خواستم برنامه‌ای به زبان C++ بنویسد که وضعیت سیستم (CPU، RAM، حافظه) را هر ۳۰ ثانیه یک بار جمع‌آوری کرده و به یک موضوع MQTT ارسال کند. این یک درخواست ساده بود، اما نتایج نگران‌کننده بود.

مشکلات امنیتی در کد MQTT

این برنامه، چندین آسیب‌پذیری جدی امنیتی داشت:

• عدم اجبار به استفاده از SSL: اطلاعات حساس مانند رمزهای عبور، به صورت متنی و بدون رمزنگاری ارسال می‌شدند.
• وجود پرچم `–password`: استفاده از این پرچم، رمز عبور را در تاریخچه دستورات یا فایل‌های لاگ آشکار می‌کرد.
• عدم اعتبارسنجی ورودی: تنظیم بازه زمانی ارسال اطلاعات به ۰ یا کمتر، باعث سیل پیام به بروکر MQTT می‌شد که منجر به حملات انکار سرویس (DoS) می‌گردید.
• عدم اعتبارسنجی ورودی کاربر برای ‘–topic’: کنترل کامل کاربر بر نام موضوع و محتوای پیام MQTT، امکان حملات جدی مانند ارسال داده‌های مخرب را فراهم می‌کرد.

حملات احتمالی از طریق MQTT:

عدم اعتبارسنجی دقیق، امکان حملات زیر را فراهم می‌کرد:

• انتشار در موضوعات سیستمی یا رزرو شده.
• انتشار داده‌های مخرب برای بازخوانی توسط کلاینت‌های دیگر.
• ایجاد سرریز منابع با ارسال موضوعات یا محتواهای طولانی.
• تزریق کدهای فرار و کاراکترهای جدید به لاگ‌ها.
• حمله Path Traversal: در صورت ذخیره موضوعات MQTT در سیستم فایل، امکان انتشار به فایل‌های سیستمی مانند /etc/passwd وجود داشت.

نمایش فایل‌ها در یک دایرکتوری با پایتون: آسیب‌پذیری تزریق دستور

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

آسیب‌پذیری در نسخه ویندوز:

در سیستم‌عامل ویندوز، استفاده از دستور dir به همراه cmd /c امکان تزریق دستور را فراهم می‌کرد. به عنوان مثال، کاربر می‌توانست ورودی "C: & calc.exe" را وارد کند که باعث اجرای ماشین حساب می‌شد.

این نشان می‌دهد که حتی با وجود ادعای هوش مصنوعی مبنی بر “ایمنی”، باید کدهای تولیدی را به دقت بررسی کرد.

تجزیه یک فایل CSV در C: خطاهای فاحش

در آزمایشی دیگر، از ChatGPT خواستم برنامه‌ای به زبان C بنویسد که یک فایل CSV را خط به خط بخواند و هر فیلد را چاپ کند. هدف، بررسی مشکلات مربوط به مدیریت حافظه در C بود.

مشکلات اصلی در کد C:

• بافر با اندازه ثابت (MAX_LINE_LEN): خطوط طولانی‌تر از بافر، به خط بعد سرریز می‌کردند که منجر به نقص منطقی می‌شد.
• استفاده از تابع strtok: این تابع، فیلدهای خالی و فیلدهای نقل‌قول‌شده را نادیده می‌گرفت.
• آسیب‌پذیری Path Traversal: مشابه موارد قبلی، این کد نیز در برابر حملات Path Traversal آسیب‌پذیر بود.

سرور وب C با قابلیت آپلود فایل: نکات مثبت و منفی

سپس از ChatGPT خواستم یک سرور وب ساده به زبان C بنویسد که امکان آپلود فایل را فراهم کند. این کد، هرچند به نسبت بهتر بود، اما باز هم مشکلات جدی داشت.

نقاط ضعف امنیتی:

• اندازه نامحدود سربرگ و بدنه: عدم محدودیت بر اندازه سربرگ و محتوای درخواست، امکان بروز حملات Denial of Service (DoS) را فراهم می‌کرد.
• عدم بررسی اتصال کلاینت: حتی پس از قطع اتصال کلاینت، سرور همچنان به خواندن و ذخیره حافظه مقداردهی نشده ادامه می‌داد.
• دستورات فایل ناامن: فایل‌های آپلود شده با مجوز ۰۷۵۵ ذخیره می‌شدند که به معنای قابل خواندن بودن برای همه کاربران بود.
• آسیب‌پذیری سرریز بافر: خط hdrs[hdr_len] = ''; در صورت عدم تخصیص یک بایت اضافی، می‌توانست منجر به سرریز بافر و امکان کنترل از راه دور سرور شود.

نتیجه‌گیری: کد تولیدی هوش مصنوعی نیازمند هوشیاری است

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

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

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