گاهی شبکه از بیرون مرتب به نظر میرسد: فایروال داریم، VPN کنترل شده، سرورها آپدیتاند و لاگها هم جمع میشوند. اما یک فرم لاگین ضعیف، یک آپلود فایل بدون کنترل یا یک API بدون احراز هویت درست، میتواند همه این نظم را دور بزند.
مبنای این مطلب: SANS Critical Security Control 18: Application Software Security، یعنی «امنیت نرمافزارهای کاربردی» در فهرست ۲۰ کنترل امنیتی SANS/CIS. متن زیر ترجمه خشک کنترل نیست؛ برداشت عملی از همان کنترل برای شبکه و زیرساخت سازمانی است.
کنترل شماره ۱۸ درباره امنیت نرمافزارهای کاربردی است. یعنی برنامهای که روی این زیرساخت اجرا میشود، خودش نباید مسیر ساده ورود مهاجم باشد.
امنیت از آخر پروژه شروع نمیشود
اگر امنیت فقط قبل از انتشار بررسی شود، معمولا یا دیر است یا گران. بهتر است از طراحی شروع شود: چه دادهای ذخیره میشود، چه کاربری چه دسترسی دارد، ورودیها از کجا میآیند، خطاها چطور نمایش داده میشوند و secretها کجا نگهداری میشوند.
خطاهای رایج هنوز رایجاند
با وجود همه ابزارها، خطاهای ساده هنوز زیاد دیده میشوند: SQL Injection، XSS، آپلود فایل خطرناک، Session ضعیف، نبود محدودیت روی درخواستها، دسترسی مستقیم به آبجکتها، API بدون کنترل درست و نمایش خطای فنی به کاربر.
برای همین استفاده از راهنماهایی مثل OWASP Top 10 هنوز کاربردی است، به شرطی که فقط به چکلیست تبدیل نشود و واقعا در کد و معماری دیده شود.
وابستگیها و secretها
بخش زیادی از نرمافزار امروز از کتابخانهها و پکیجها ساخته شده است. اگر وابستگیها بررسی نشوند، یک آسیبپذیری در پکیج قدیمی میتواند برنامه را آسیبپذیر کند. همینطور secretهایی مثل token، password، private key و connection string نباید داخل کد یا repository بمانند.
- وابستگیها دورهای اسکن و بهروزرسانی شوند.
- secret داخل Git و فایلهای قابل دانلود قرار نگیرد.
- دسترسی دیتابیس برای برنامه حداقلی باشد.
- خطاهای برنامه اطلاعات داخلی لو ندهند.
WAF کمک میکند، جای اصلاح کد نیست
ابزاری مثل FortiWeb یا هر WAF دیگر میتواند لایه دفاعی خوبی باشد، مخصوصا برای کاهش ریسک حملات شناختهشده و دیدن رفتار مشکوک. اما WAF نباید بهانهای برای اصلاح نکردن کد باشد. اگر برنامه دسترسی را اشتباه کنترل کند، WAF همیشه متوجه نیت تجاری برنامه نمیشود.
برای همین امنیت نرمافزار باید کنار پیکربندی درست WAF دیده شود، نه به جای آن.
چکلیست ذهنی برای کنترل امنیت شماره ۱۸
امنیت نرمافزار یعنی ورودیها کنترل شوند، دسترسیها درست طراحی شوند، وابستگیها رها نشوند، secretها امن بمانند و تست امنیتی بخشی از چرخه انتشار باشد. اگر برنامه ناامن باشد، زیرساخت امن فقط بخشی از مشکل را حل میکند.
در بازبینی امنیت نرمافزار دنبال چه خروجی باشیم؟
خروجی قابل استفاده فقط یک لیست آسیبپذیری نیست. برای یک تیم زیرساخت یا امنیت شبکه، گزارش خوب باید مشخص کند کدام ضعف واقعاً مسیر نفوذ میسازد، کدام مورد با تنظیم WAF یا محدودسازی دسترسی موقتاً قابل مهار است و کدام مورد حتماً باید در کد اصلاح شود. اگر برنامه پشت FortiWeb، F5 ASM یا هر WAF دیگری قرار دارد، نتیجه تست باید به زبان policy هم ترجمه شود: کدام مسیر API حساس است، کدام پارامتر نباید آزاد بماند و کجا rate limit یا اعتبارسنجی ورودی لازم است.
در پروژههای جدی، بهتر است معیار بررسی از منابع اصلی بیاید؛ برای نمونه OWASP ASVS برای کنترلهای قابل آزمون برنامه، OWASP Top 10 برای خطاهای رایج وب و CIS Controls v8 برای اتصال امنیت نرمافزار به چرخه کلی دفاع سازمانی. این منابع جای قضاوت فنی را نمیگیرند، اما کمک میکنند بررسی از حالت سلیقهای خارج شود.
ارتباط این کنترل با WAF و لاگ
وقتی ضعف برنامه پیدا شد، نباید فقط به توسعهدهنده واگذار شود و از دید شبکه خارج شود. تا زمان اصلاح کد، ممکن است لازم باشد rule موقت WAF، محدودسازی مسیر مدیریتی، مانیتورینگ لاگ یا alert جدا تعریف شود. این کار باید موقت، مستند و قابل بازگشت باشد؛ چون rule اضطراری اگر بعداً فراموش شود، خودش به بدهی عملیاتی تبدیل میشود.
برای طراحی این مسیر، مطالعه حفاظت API با FortiWeb و مدیریت لاگ و مانیتورینگ کنار این کنترل تصویر کاملتری میدهد.
