ژرف تکنو
در بیشتر پروژه‌هایی که بعد از یک رخداد امنیتی بررسی می‌شوند، خبری از حملهٔ پیچیده نیست. مشکل معمولاً یک دسترسی محافظت‌نشده، یک وابستگی قدیمی یا یک اعتبارسنجی فراموش‌شده است. همین موضوع خبر خوبی هم دارد: بخش بزرگی از ریسک امنیتی با کارهای مشخص و تکرارشدنی کم می‌شود.
نخستین و شایع‌ترین خطا، کنترل دسترسی نادرست است. یعنی کاربر واردشده می‌تواند به داده یا عملیاتی برسد که نباید. این اتفاق وقتی می‌افتد که بررسی مجوز فقط در رابط کاربری انجام شود یا شناسهٔ رکورد از سمت کلاینت بدون بررسی مالکیت پذیرفته شود. قاعدهٔ ساده این است که هر درخواست در سمت سرور، هم هویت و هم مالکیت منبع را دوباره بررسی کند.
دوم، رمزنگاری ناکارآمد و مدیریت ضعیف داده‌های حساس است. ذخیرهٔ رمز عبور با هش سریع و بدون نمک، انتقال داده روی اتصال غیرامن، نگهداری کلید در مخزن کد و ثبت اطلاعات کارت یا کد ملی در لاگ، همه نمونه‌های رایج‌اند. رمز عبور باید با الگوریتم کند و استاندارد هش شود، ارتباط‌ها TLS داشته باشند و داده‌های حساس تا حد امکان ذخیره نشوند.
سوم، تزریق؛ از SQL و NoSQL تا اجرای دستور سیستمی و ارزیابی عبارت. راه‌حل همچنان همان است: پرس‌وجوی پارامتری، اعتبارسنجی ورودی بر اساس نوع و دامنهٔ مجاز و پرهیز از ساختن دستور با ترکیب رشته. اعتبارسنجی سمت کلاینت برای تجربهٔ کاربری خوب است، اما سد امنیتی نیست و باید در سرور تکرار شود.
چهارم، طراحی ناامن. یعنی حتی وقتی کد باگ ندارد، خود طراحی مسیر سوءاستفاده باز می‌کند؛ مثلاً فرآیند بازیابی رمز با پرسش امنیتی حدس‌زدنی یا اجازهٔ دانلود فایل با حدس نام. پیش از پیاده‌سازی قابلیت‌های حساس، چند پرسش بپرسید: چه کسی می‌تواند این کار را انجام دهد، اگر این مرحله تکرار شود چه می‌شود و اگر ورودی دستکاری شود چه اتفاقی می‌افتد.
پنجم، پیکربندی نادرست. حالت اشکال‌زدایی فعال در محیط عملیاتی، رمز پیش‌فرض، دسترسی عمومی به فهرست فایل‌ها، هدرهای امنیتی ناقص و مجوزهای بیش از حد گسترده در سرویس ابری، همه در این دسته‌اند. یک فهرست بررسی برای محیط انتشار و مقایسهٔ خودکار پیکربندی، از این خطاها پیشگیری می‌کند.
ششم، استفاده از اجزای آسیب‌پذیر یا قدیمی. کتابخانه‌ای که دو سال به‌روز نشده، به‌اندازهٔ کدی که خودتان نوشته‌اید بخشی از محصول است. اسکن خودکار وابستگی‌ها، حذف بسته‌های بی‌استفاده و سیاست مشخص برای به‌روزرسانی، این ریسک را کنترل می‌کند. به‌روزرسانی را به یک رویداد سالانه تبدیل نکنید؛ آن را بخشی از چرخهٔ انتشار کنید.
هفتم، خطا در احراز هویت و مدیریت نشست. نبود محدودیت تلاش، نشست‌های طولانی و بدون ابطال، توکن‌های قابل حدس و نبود محافظت در برابر درخواست جعل‌شده، از مشکلات پرتکرارند. امروز احراز هویت دومرحله‌ای برای پنل‌های مدیریتی یک انتخاب نیست، یک ضرورت است. همچنین خروج از حساب باید نشست را واقعاً باطل کند، نه فقط کوکی مرورگر را پاک کند.
هشتم، خطا در یکپارچگی نرم‌افزار و داده. اگر خط لولهٔ انتشار شما قابل دستکاری باشد، بقیهٔ کنترل‌ها بی‌فایده‌اند. محدودکردن دسترسی به مخزن و خط لوله، امضای مصنوعات انتشار، بررسی تغییرات ناخواسته در وابستگی‌ها و پشتیبان‌گیری قابل بازیابی، ستون‌های این بخش‌اند. پشتیبان بدون آزمون بازیابی، پشتیبان نیست.
نهم، ضعف در ثبت رویداد و پایش. بسیاری از سازمان‌ها نمی‌فهمند نفوذ رخ داده، چون رویداد مهمی ثبت نمی‌شود. ورودهای ناموفق، تغییر سطح دسترسی، خطاهای سرور و درخواست‌های غیرعادی باید ثبت شوند و برای الگوهای مشکوک هشدار وجود داشته باشد. البته لاگ‌ها نباید خودشان به منبع دادهٔ حساس تبدیل شوند.
دهم، جعل درخواست سمت سرور. اگر آدرس ورودی کاربر بدون محدودیت روی سرور بازیابی شود، مهاجم می‌تواند به سرویس‌های داخلی دسترسی بگیرد. محدودکردن مقاصد مجاز، اعتبارسنجی آدرس و جداسازی شبکه، جلوی این مسیر را می‌گیرد. این خطا در پروژه‌هایی که قابلیت دریافت لینک یا تصویر دارند بیشتر دیده می‌شود.
برای اقدام، لازم نیست همه‌چیز را هم‌زمان درست کنید. با یک فهرست بررسی شروع کنید، دسترسی‌ها را بازبینی کنید، احراز هویت دومرحله‌ای را فعال کنید، وابستگی‌ها را اسکن کنید و برای دادهٔ حساس سیاست روشن بگذارید. سپس یک آزمون نفوذ هدفمند انجام دهید و یافته‌ها را به وظایف قابل پیگیری تبدیل کنید. امنیت یک وضعیت نیست، یک فرآیند است.