امنیت نرمافزار مدرسه: اشتباههایی که در پروژهی خودم پیدا کردم
وقتی میخواستم دموی عمومی ClassBan را منتشر کنم، کل پروژه را از دید امنیتی بازبینی کردم. چیزهایی پیدا کردم که اگر منتشر میشدند، دردسر واقعی بودند. این فهرست برای کسی است که نرمافزار مدرسهای میسازد؛ مثالها همه از پروژهی خودم است.
اشتباههایی که پیدا کردم
۱. فایل .env با کلیدهای واقعی داخل بسته. فایل تنظیمات (کلید پیامک، رمز JWT و غیره) کنار سورس بود. هر کسی که بسته را میگرفت کلیدها را داشت. راه درست: .env هیچوقت داخل بسته یا مخزن نباشد، فقط .env.example، و کلیدی که یک بار در جایی افتاد باید عوض شود.
۲. دادهی واقعی دانشآموزان کنار سورس. فایلهای CSV لیست دانشآموزان داخل پوشهی پروژه بودند. برای دمو و هر انتشار عمومی، فقط دادهی ساختگی.
۳. شمارهی تلفن و ایمیل واقعی هاردکدشده در صفحهها. صفحهی «فراموشی رمز» شمارههای تماس را داخل کد داشت. اطلاعات تماس باید از یک تنظیم بیاید و عمداً انتخاب شود.
۴. رمز پیشفرض ثابت. هنگام بازنشانی دادهها، اگر متغیر محیطی تنظیم نشده باشد، کاربر مالک با یک رمز پیشفرض ثابت دوباره ساخته میشود. رمز پیشفرض باید تصادفی باشد یا حتماً از کاربر گرفته شود.
۵. فرم تماس با کلید عمومی در صفحه. فرم سایت از یک سرویس فرمساز استفاده میکرد که شناسهی ایمیل مقصد در HTML دیده میشد؛ هر ربات میتوانست ایمیل را پیدا کند و اسپم بفرستد. جایگزین: یک تابع سمت سرور با honeypot و محدودیت تعداد.
۶. چتبات ساختگی. صفحهی اصلی یک چتبات داشت که با پاسخهای از پیش نوشته جواب میداد و قیمت و قولهایی میداد که واقعی نبودند. این هم یک ریسک است، نه فقط ظاهر؛ حذفش کردم.
چیزهایی که درست بود
- رمزها با bcrypt هش میشوند، نه ذخیرهی ساده.
- ورود با JWT و نقشهای جدا (مدیر/معاون) و بررسی نقش در سرور، نه فقط در رابط.
- محدودیت تعداد تلاش ورود (۱۰ بار در ۱۵ دقیقه).
- هدرهای امنیتی با helmet.
- خروج خودکار بعد از بیفعالیتی.
قاعدهی کلی
نرمافزار مدرسه اطلاعات کودکان را نگه میدارد. حداقلها: هیچ راز در سورس یا بسته نباشد، دسترسیها مبتنی بر نقش باشند و در سرور بررسی شوند، دادهی واقعی هرگز در دمو و توسعه نباشد، و ورودیها در سرور اعتبارسنجی شوند.
یک پیشنهاد هم برای خودم: بازبینی امنیتی را قبل از انتشار انجام دهم، نه بعد از آن. اگر اینها را از ابتدا رعایت کنید، بازبینی نهایی کوتاه میشود.