بررسی امنیت کد با هوش مصنوعی: لایهی اول، نه آخر
مدل کدام آسیبپذیریها را واقعاً پیدا میکند، کدام دسته را هرگز نمیبیند، چرا فهرست بلند هشدار تیم را بیحس میکند، و چرا این کار جای تست نفوذ را نمیگیرد.
یک تیم سهنفره پنل فروشگاه اینترنتیشان را بالا آورده و همهچیز کار میکند. تا صبحی که مشتری زنگ میزند: نشانی صفحهی گزارش فروش را جایی اشتباهی فرستاده و حالا یک نفر دیگر هم فهرست سفارشها و شمارهی خریدارها را دیده است. کسی هک نکرده بود؛ آن صفحه از اول ورود نمیخواست.
این جنس ایراد در بازبینی معمولی گم میشود، چون کد «کار میکند». تستها سبزند و بازبین به نام متغیر نگاه میکند، نه به اینکه چه کسی حق دیدن این خروجی را دارد.
مدلهای زبانی دقیقاً در همین شکاف مفیدند، با یک شرط: این کار لایهی اول است، نه آخر.
فرقش با بازبینی معمولی کد
در بازبینی کد با هوش مصنوعی سؤال خوانایی و نگهداری کد است. اینجا سؤال فقط یکی است: اگر کسی بدخواه باشد، از کجا وارد میشود.
کدی که از نظر مهندسی تمیز است میتواند حفرهی بزرگی داشته باشد. اگر این زاویه را در پرامپت روشن نکنید، مدل به عادتش برمیگردد و دربارهی نامگذاری نظر میدهد.
پنج دستهای که مدل واقعاً پیدا میکند
ورودی اعتبارسنجینشده. پارامتری که مستقیم از درخواست خوانده و بدون بررسی نوع و بازه وارد منطق میشود. مدل این الگو را خوب میشناسد؛ شکل نوشتاریاش تکرارشونده است.
کوئری ناامن. هر جا رشتهی کوئری با الحاق ساخته شده باشد. قدیمیترین و هنوز پرتکرارترین اشتباه؛ مدل تقریباً همیشه پیدایش میکند و جایگزین پارامتریشده میدهد. پیشینهاش در مدخل SQL injection و مبانیاش در نوشتن کوئری SQL آمده.
افشای اطلاعات در پیام خطا. صفحهای که هنگام خطا نام جدول، مسیر فایل یا بخشی از رشتهی اتصال را چاپ میکند؛ برای مهاجم یعنی نقشهی رایگان.
رمز و کلید داخل کد. توکن درگاه پرداخت، کلید پنل پیامکی، رمز پایگاه داده. مدل اینها را از روی شکل رشته و نام متغیر تشخیص میدهد و معمولاً درست میگوید.
کنترل دسترسی ناکافی. همان چیزی که سر تیم اول آمد: مسیری که فقط با ندانستن نشانیاش محافظت میشود. مدل وقتی میبیندش که بگویید چه کسی باید به آن دسترسی داشته باشد.
کدام هشدار ارزش وقت دارد
همهی هشدارها هموزن نیستند؛ این جدول تجربهی عملی است، نه رتبهبندی رسمی:
| دسته | نشانه در کد | اتکا به هشدار |
|---|---|---|
| کوئری ناامن | ساخت رشته با الحاق ورودی | زیاد |
| کلید داخل کد | رشتهی ثابت کنار نام کلید | زیاد |
| افشای خطا | چاپ مستقیم استثنا به کاربر | زیاد |
| ورودی کنترلنشده | خواندن مستقیم از درخواست | متوسط |
| کنترل دسترسی | نبود بررسی مالکیت رکورد | کم، بدون زمینه |
سه چیزی که پیدا نمیکند
ایراد معماری. اینکه سرویس گزارشگیری اصلاً نباید به پایگاه دادهی کاربران دسترسی مستقیم داشته باشد، تصمیمی در سطح نقشه است. مدل فایل را میبیند، نه نقشه را.
منطق کسبوکار. فرض کنید کد تخفیف دو بار روی یک سفارش مینشیند، مبلغ نهایی منفی میشود و به کیف پول کاربر برمیگردد. هیچ خطی اینجا «ناامن» نیست؛ قاعدهی کسبوکار غلط است و مدل قاعدهی شما را نمیداند.
آسیبپذیری زنجیرهای. خطرناکترین رخنهها از یک حفرهی بزرگ نمیآیند، از سه چیز کوچک میآیند که کنار هم معنا پیدا میکنند: آپلودی که پسوند را سست بررسی میکند، مسیری که فایلها را سرو میکند، و صفحهی خطایی که مسیر ذخیره را لو میدهد. هر سه جداگانه بیخطرند و مدل هم جداگانه نگاهشان میکند.
مثبت کاذب و بیحس شدن تیم
فایلی را بدون زمینه بدهید، فهرستی بلند برمیگردد که بخشی درست است و بخشی نه. مدل نمیداند ورودی دو لایه بالاتر پاکسازی شده یا مسیر پشت میانافزار احراز هویت است.
خطر واقعی خودِ اشتباه نیست، عادت است. تیمی که سه بار هشدارها را بررسی کند و هر بار ببیند بیشترشان بیمورد بودهاند، بار چهارم فهرست را نمیخواند. همان بار چهارم است که یک مورد درست گم میشود.
اگر خروجی بیش از پنج، شش مورد بود، پرامپت را تنگتر کنید و فهرست را همانطور به تیم ندهید. فقط مواردی را بخواهید که سناریوی سوءاستفادهی مشخص دارند.
کدی که خود هوش مصنوعی نوشته
سرعت تولید که بالا میرود، الگوهای ناامن هم سریعتر تکثیر میشوند. سه مورد مکرر: نمونهی کاریِ بیاعتبارسنجی که همانطور به تولید میرود؛ بررسی توکن به شکل مقایسهی سادهی رشتهای؛ و تنظیمات دسترسی باز برای اینکه «فعلاً کار کند».
چنین کدی تمیز و منظم بهنظر میرسد و همین اعتماد کاذب میسازد. اگر بخش زیادی از پروژه با کمک مدل نوشته شده، دلیل بیشتری برای بازبینی امنیتی جداگانه دارید، نه کمتر؛ مثل مهاجرت کد و ارتقای نسخه که فرضهای قدیمی بیسروصدا منتقل میشوند.
پکیجی که وجود ندارد
مدلها گاهی نام کتابخانهای میسازند که هرگز منتشر نشده؛ همان توهم هوش مصنوعی. در حالت بیخطر، دستور نصب خطا میدهد. در حالت بد، کسی همان نام حدسزدنی را زودتر ثبت کرده و کد مخربش با اولین نصب وارد پروژه میشود.
قاعده ساده است: هر نام پکیجی که از مدل میگیرید پیش از نصب در مخزن رسمی همان زبان جستوجو شود. پکیج سهروزهی بیمخزن، نصب نمیشود.
پرامپتی که خروجی قابل استفاده میدهد
تفاوت «این کد را امنیتی بررسی کن» با الگوی زیر، تفاوت بیست هشدار مبهم و چهار هشدار قابل اقدام است:
نقش: بازبین امنیتی کد
زبان و چارچوب: [PHP و لاراول]
مسیر ورود داده: [فرم عمومی سایت، بدون ورود کاربر]
دسترسی موردانتظار: [فقط مدیر فروشگاه]
لایههای قبلی: [اعتبارسنجی فرم در لایهی بالاتر]
فقط این دستهها را بررسی کن:
ورودی اعتبارسنجینشده، کوئری ناامن، افشای اطلاعات در خطا،
کلید و رمز داخل کد، کنترل دسترسی ناکافی
برای هر مورد بنویس: شمارهی خط، سناریوی سوءاستفاده در یک جمله،
اصلاح پیشنهادی بهصورت کد
اگر مطمئن نیستی بنویس نامطمئن؛ حدس نزن
دربارهی سبک کد و نامگذاری چیزی ننویس«سناریوی سوءاستفاده در یک جمله» بیشترین اثر را دارد: مدل باید برای هر هشدار روایتی واقعی بسازد و هشدارهای بیپشتوانه همانجا میریزند. ساختن چنین قالبهایی در پرامپتنویسی فارسی باز شده و در نارنگی میشود امتحانش کرد.
کجای روند کار بگذاریمش
بهترین جا پیش از ارسال درخواست ادغام است، روی همان چند فایل تغییرکرده: کد را با یک توضیح یکخطی دربارهی مسیر ورود داده بدهید، خروجی را خودتان فیلتر کنید و فقط موارد تأییدشده را به تیم ببرید.
هر هشدار پذیرفتهشده باید یک تست داشته باشد، وگرنه سه ماه بعد کسی همان خط را برمیگرداند. جای دومش کنار بررسی وابستگیها در خط لوله است؛ زاویهی لاگ و اسکریپت در هوش مصنوعی برای دواپس آمده.
جایی که این کار جواب نمیدهد
مدل سامانه را در حال اجرا نمیبیند. تنظیمات وبسرور، قواعد فایروال، مجوز فایلها و رفتار واقعی درگاه پرداخت بیرون از دید اوست. بالا بردن سطح دسترسی هم کار انسان است.
برای هر چیزی که پول یا دادهی هویتی جابهجا میکند، آزمون نفوذ توسط متخصص جایگزین ندارد و این متن هم توصیهی امنیتی اختصاصی برای سامانهی شما نیست؛ فهرست مرجع دستهها را OWASP Top Ten نگه میدارد. و کد محرمانهی کارفرما را بیاجازه داخل ابزار نریزید — چراییاش در امنیت اطلاعات در هوش مصنوعی آمده.
جمعبندی
بررسی امنیت کد با مدل زبانی یک کار را خوب انجام میدهد: الگوهای خطرناکِ محلی و تکرارشونده را ارزان و بیخستگی زودتر از انسان میبیند. همان پنج دستهی اول، بخش بزرگی از اشتباهات روزمره را پوشش میدهند.
و یک کار را اصلاً نمیکند: نگاه کردن به کل سامانه از چشم مهاجم. معماری، منطق کسبوکار و زنجیرهی حفرههای کوچک بیرون از توان اوست.
پس اینطور استفاده کنید: پرامپت تنگ، دستههای مشخص، سناریوی سوءاستفاده برای هر هشدار، تست برای هر اصلاح، و برنامهی جداگانه برای آزمون نفوذ. لایهی اول باشد، نه آخر.
برای ادامه:
