۵ حفرهٔ امنیتی رایج در اپلیکیشن‌های ساخته‌شده با هوش مصنوعی

اگر امروز از هوش مصنوعی برای ساخت سریع یک اپلیکیشن استفاده می‌کنید، احتمالاً در حال ارسال کدهایی هستید که هرگز آن‌ها را نخوانده‌اید. این فاصلهٔ خطرناک بین «کدی که اجرا می‌شود» و «کدی که امن است»، در حال تبدیل شدن به یک بحران سیستمی در توسعهٔ نرم‌افزار است. توسعهٔ بومیِ هوش مصنوعی (AI-native development) می‌تواند یک دمو را در لحظه به نتیجه برساند، اما اغلب نسبت به مسائل امنیتی بی‌تفاوت است.

کساتریا بینتینگ سامودرا (Ksatria Bintang Samudra)، مهندس فول‌استک و متخصص تست نفوذ، هشدار می‌دهد که برنامه‌نویسان اکنون کدهایی را منتشر می‌کنند که عملاً هرگز آن‌ها را مطالعه نکرده‌اند. او معتقد است ابزارهای هوش مصنوعی زاینده (Generative AI) — شبیه دستیاری که با سرعت زیاد می‌نویسد اما به محتوا دقت نمی‌کند — اصطکاک طبیعی توسعه را از بین برده‌اند.

زمینه و سرعت AI

این تغییر رویکرد در زمانی رخ می‌دهد که ابزارهای AI آن اصطکاک طبیعی را حذف می‌کنند؛ همان اصطکاکی که زمانی برنامه‌نویسان را مجبور می‌کرد سرعت خود را کاهش دهند و روی حالت‌های خاص (Edge Cases) فکر کنند. این روند باعث شده تا ارزش مهارت‌های برنامه‌نویسی از نوشتن صرفِ کد به سمت معماری سیستم و عیب‌یابی تغییر کند، جایی که نظارت انسانی بر ساختار کلی اهمیت بیشتری می‌یابد. سامودرا که سال‌ها پیش از تبدیل شدن به یک مهندس AI-native، در زمینه تست نفوذ و شکار باگ (Bug Hunting) فعالیت می‌کرد و یاد گرفته بود مانند یک مهاجم فکر کند، توضیح می‌دهد که سرعت بالای انتشار کد با کمک AI، برای کسانی که بدون تایید و بررسی به کدهای «تمیز» اعتماد می‌کنند، مانند یک «اسلحهٔ پُر» عمل می‌کند.

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

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

شکاف امنیتی هوش مصنوعی

• افشای اسرار در سمت کاربر (Client-Side Secrets): کلیدهای API و توکن‌ها اغلب مستقیماً در دسته‌بندی‌های فرانت‌اند یا فایل‌های .env قرار می‌گیرند و در مخزن کد ثبت می‌شوند. مدل برای اینکه برنامه سریعاً اجرا شود، با خوشحالی این کلیدها را وصل می‌کند و عملاً یک «کلید جامع» برای هر کسی که DevTools مرورگر را باز کند، فراهم می‌کند.
• اختلال در مجوز دسترسی (Broken Authorization): مدل‌ها معمولاً صفحهٔ ورود (Authentication یا «شما کی هستید؟») را عالی می‌سازند، اما سوال دوم یعنی «آیا اجازهٔ انجام این کار را دارید؟» (Authorization) را فراموش می‌کنند. این نقص اجازه می‌دهد کاربر A با تغییر یک ID ساده در URL، هر بار داده‌های کاربر B را بخواند.
• اعتماد به داده‌های کاربر (Client Trust): اپلیکیشن‌ها مکرراً قیمت‌ها را در مرورگر محاسبه می‌کنند یا به پرچم‌هایی مثل isAdmin که از سمت کلاینت ارسال می‌شود اعتماد می‌کنند. چون مرورگر زمین بازی مهاجم است، هیچ داده‌ای که از آن می‌آید نباید به عنوان یک حقیقت پذیرفته شود.
• فقدان محدودیت نرخ درخواست (Missing Rate Limits): نقاط حساس (Endpoints) از جمله ورود، بازنشانی رمز عبور و فراخوانی‌های گران‌قیمت API هوش مصنوعی که هزینه هر بار فراخوانی دارند، بدون محدودیت رها می‌شوند. یک دمو ممکن است با یک کاربر به خوبی کار کند، اما در برابر یک فرد بیکار که با یک اسکریپت ساده هزاران درخواست در ثانیه می‌فرستد، دوام نمی‌آورد.
• خطاهای بیش از حد مفصل (Verbose Errors): ردهای کامل پشته (Full stack traces)، پیام‌های دیتابیس و مسیرهای داخلی سیستم مستقیماً به کاربر نمایش داده می‌شود. این کار در واقع نقشه‌ای دقیق از ساختار سیستم را در اختیار مهاجم قرار می‌دهد.

خطر کدهای «تمیز»

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

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

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

در آینده باید منتظر ظهور ابزارهای ممیزی امنیتی مبتنی بر AI باشیم که بتوانند این ۵ الگوی خاص را به صورت خودکار پیش از استقرار (Deployment) شناسایی کنند.

گام بعدی شما

• قبل از انتشار هر برنامه، این سوال را بپرسید: «اگر یک مهاجم به اپلیکیشن دسترسی داشت، اولین چیزی که امتحان می‌کرد چه بود و آیا جواب می‌داد؟»
• تمام کلیدهای API را از کدهای فرانت‌اند حذف کرده و به محیط‌های امن سرور منتقل کنید.
• ابزارهای ممیزی امنیتی مبتنی بر AI را برای شناسایی خودکار این ۵ الگوی خطا در خط لوله (Pipeline) استقرار خود بگنجانید.

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