الزامات امنیتی پیاده سازی شده در ایزی‌پورتال

به منظور جلوگیری از سوءاستفاده از نشست‌های ذخیره‌شده در مرورگر (به ویژه در دستگاه‌های اشتراکی یا عمومی)، طبق توصیه صریح OWASP، هدرهای کنترل کش مناسب به تمام پاسخ‌های حاوی اطلاعات احراز هویت اضافه شده است. این هدرها شامل Cache-Control: no-store, no-cache, must-revalidate و Pragma: no-cache و همچنین Expires: 0 می‌باشند. با این کار، مرورگرها اجازه ذخیره‌سازی هیچ داده‌ای (حتی به صورت موقت) از صفحات احراز هویت شده را ندارند. در نتیجه، پس از بستن مرورگر یا خروج کاربر، هیچ اثری از نشست یا رمز عبور به خاطر سپرده شده در سیستم باقی نمی‌ماند.

برای آن که اطلاعات حساس مانند محتوای صفحات خصوصی، توکن‌های احراز هویت یا داده‌های شخصی کاربر پس از خروج از سیستم در کش مرورگر باقی نمانند و از دسترسی غیرمجاز در سیستم‌های اشتراکی جلوگیری شود، افزون بر هدرهای کنترل کش، مکانیزم‌های دیگری مانند تنظیم هدر Vary و استفاده از روش‌های سمت کلاینت برای پاک‌سازی حافظه نیز به کار گرفته شده است. همچنین، برای صفحاتی که حاوی اطلاعات حساس هستند، از ذخیره‌سازی سمت کلاینت مانند localStorage یا sessionStorage اجتناب گردیده است. این اقدام، یکی از الزامات کلیدی در رعایت استانداردهای امنیتی مانند PCI-DSS و HIPAA است.

با توجه به اینکه رمزهای عبور ضعیف و قابل حدس، دروازه اصلی ورود حملات Brute-force و دیکشنری هستند، سیاست رمز عبور به طور قابل توجهی تقویت شده است. این سیاست شامل حداقل طول ۱۲ کاراکتر، نیاز به ترکیب حروف بزرگ و کوچک، اعداد و نمادها، و همچنین ممنوعیت استفاده از رمزهای رایج (مانند "123456" یا "password") و رمزهای تکراری در پنج ورود اخیر می‌باشد. علاوه بر این، مکانیزمی برای بررسی رمزهای عبور در برابر لیست رمزهای افشاشده (مانند HaveIBeenPwned) پیاده‌سازی شده است. کاربران همچنین ملزم به تغییر رمز عبور هر ۹۰ روز یکبار هستند.

با توجه به اینکه نام‌های کاربری قابل حدس (مانند admin, test, user1) یا تکراری، سطح حمله را افزایش می‌دهند، سیاست‌های سخت‌گیرانه‌ای برای انتخاب نام کاربری اعمال شده است. این سیاست‌ها شامل جلوگیری از استفاده از نام‌های رایج، الگوهای شمارشی، و همچنین اجباری کردن حداقل طول و استفاده از ترکیب حروف و اعداد می‌گردد. علاوه بر این، در فرآیند ثبت‌نام، نام‌های تکراری یا مشابه با الگوهای از پیش تعریف‌شده رد می‌شوند. این کار احتمال موفقیت حملات مبتنی بر حدس هویت کاربران را به شدت کاهش می‌دهد.

برای آن که مهاجم نتواند با ارسال درخواست‌های مکرر به صفحات ورود یا ثبت‌نام، وجود یا عدم وجود یک حساب کاربری خاص را تشخیص دهد، پیام‌های خطا و پاسخ‌های سیستم به‌صورت کاملاً یکسان و عمومی طراحی شده است. یعنی چه نام کاربری موجود نباشد و چه رمز عبور اشتباه باشد، پیام خطایی مانند «نام کاربری یا رمز عبور نامعتبر است» نمایش داده می‌شود. همچنین، تفاوت در زمان پاسخ‌گویی (که ممکن است سرنخی از وجود کاربر بدهد) با افزودن تأخیرهای تصادفی یا یکسان‌سازی پردازش برطرف گردیده است. این اقدام حملات شمارش حساب و هدفمند کردن کاربران معتبر را به طور مؤثری خنثی می‌کند.

از آنجا که مهاجمان برای انجام حملات هدفمند مانند تزریق SQL یا حملات مسیر (Path Traversal) نیاز به درک درستی از معماری برنامه، نقاط پایانی و ساختار داخلی آن دارند، سیستم به گونه‌ای طراحی و ایمن‌سازی شده است که این اطلاعات به راحتی قابل شناسایی نباشند. برای این منظور، از مسیرهای غیرقابل حدس، عدم نمایش ردیابی پشته در خطاها، و عدم افشای فایل‌های پیکربندی یا مستندات خودکار مانند Swagger عمومی استفاده گردیده است. این کار مهندسی معکوس و حملات تخصصی را با دشواری زیادی مواجه می‌سازد.

به منظور جلوگیری از آپلود و اجرای فایل‌های مخرب (مانند وب‌شل‌ها یا اسکریپت‌های سمت سرور)، سیستم به گونه‌ای پیکربندی شده است که تنها پسوندهای مجاز و از پیش تعریف‌شده (مانند jpg.، png.، pdf.) پردازش شوند و هرگونه فایل با پسوند اجرایی (مانند php.، aspx.، exe.) یا بدون پسوند قویاً رد گردد. همچنین، با بررسی محتوای فایل (نه فقط پسوند) و ذخیره فایل‌ها با نام‌های تصادفی در خارج از دایرکتوری وب، ریسک اجرای کد دلخواه مهاجم به حداقل رسیده است. این کنترل، یکی از مهمترین اقدامات در برابر حملات آپلود فایل مخرب محسوب می‌شود.

برای آنکه امکان شناسایی نسخه و ساختار داخلی سیستم حتی در سطوح عمیق‌تر برنامه از بین برود، کلیه خروجی‌های قابل شناسایی در سطح اپلیکیشن حذف یا کنترل شده‌اند. این اقدام شامل حذف شماره نسخه در فایل‌های CSS و جاوااسکریپت، پنهان‌سازی مسیرهای منحصربه‌فرد در APIها، و عدم نمایش جزئیات مربوط به کتابخانه‌های ثالث در پاسخ‌ها می‌گردد. این رویکرد باعث می‌شود حتی در صورت دسترسی مهاجم به برخی از منابع، معماری داخلی و نسخه دقیق کامپوننت‌ها قابل استنتاج نباشد.

با توجه به این که مهاجمان اغلب با شناسایی فریم‌ورک مورد استفاده (مانند ASP.NET، Django، Spring) و نسخه آن، به دنبال بهره‌برداری از آسیب‌پذیری‌های اختصاصی آن فریم‌ورک هستند، دسترسی به هرگونه اطلاعات مربوط به فریم‌ورک و تکنولوژی‌های به‌کاررفته در برنامه محدود و محافظت شده است. این کار با حذف کوکی‌های اختصاصی، الگوهای URL مشخص، و کامنت‌های باقیمانده در کدهای سمت کلاینت انجام گرفته است. در نتیجه، مهاجم قادر به تشخیص آسان نوع فریم‌ورک نبوده و عملاً تحلیل دقیق ساختار برنامه برای وی غیرممکن می‌شود.

به منظور شناسایی گواهی‌های باطل‌شده، سیستم قابلیت بررسی وضعیت ابطال گواهی‌ها از طریق OCSP (Online Certificate Status Protocol) را دارد. در صورت غیرقابل دسترس بودن OCSP، از CRL (Certificate Revocation List) که حداقل هر ۲۴ ساعت یکبار بروز می‌شود، استفاده می‌گردد. هرگونه گواهی ابطال‌شده بلافاصله در حافظه سیاه قرار گرفته و اتصالات بعدی مسدود می‌شوند.

به منظور یکسان‌سازی فرآیند اعتبارسنجی، قوانین اعتبارسنجی گواهی شامل موارد زیر است: گواهی باید توسط یک CA معتبر امضا شده باشد، زنجیره اعتماد کامل و بدون وقفه باشد، فیلد زمان اعتبار (notBefore/notAfter) معتبر باشد، و نام دامنه (Common Name یا SAN) با درخواست مطابقت داشته باشد. نقض هر یک از این قوانین منجر به رد اتصال می‌شود.

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

به منظور جلوگیری از افشای نوع و نسخه وب‌سرور در هدرهای HTTP و پاسخ‌های خطا، مکانیزم‌های مؤثر مخفی‌سازی اطلاعات سرور در لایه وب پیاده‌سازی شده است. این اقدام شامل حذف یا تغییر هدرهای Server، X-Powered-By و موارد مشابه، همچنین یکسان‌سازی پیام‌های خطا در شرایط مختلف می‌گردد. با انجام این کار، ریسک شناسایی آسیب‌پذیری‌های شناخته‌شده مرتبط با نسخه خاص وب‌سرور توسط مهاجمان به‌طور چشمگیری کاهش یافته و سطح حمله (Attack Surface) سیستم به حداقل ممکن رسیده است.

به منظور افزایش کارایی و امنیت، سرور از مکانیزم‌های زیر استفاده می‌کند: احراز هویت دوطرفه (در صورت نیاز)، استفاده از OCSP Stapling برای کاهش ترافیک و بهبود کارایی، و فعال‌سازی ویژگی early_data (0-RTT) با محدودیت‌های امنیتی (فقط برای درخواست‌های غیرحساس). حداکثر اندازه ضبط (record size) به ۱۶ کیلوبایت محدود شده است.

به منظور استانداردسازی مدیریت گواهی‌ها، سیستم از گواهی‌های X.509 نسخه ۳ با فیلدهای کلیدی زیر استفاده می‌کند: Subject Alternative Name (SAN) برای تعریف دامنه‌ها، Key Usage و Extended Key Usage برای محدود کردن کاربرد گواهی، و Basic Constraints برای تعیین گواهی CA. طول کلید RSA حداقل ۳۰۷۲ بیت و الگوریتم امضای SHA-512 است.

به منظور اطمینان از اعتبار گواهی‌ها، سیستم اعتبار گواهی‌ها را با استفاده از زنجیره اعتماد تا ریشه معتبر، بررسی تاریخ انقضا، وضعیت ابطال (از طریق CRL یا OCSP) و تأیید عدم وجود نشانه‌های دستکاری در فیلدهای گواهی انجام می‌دهد. گواهی‌های خودامضا (Self-signed) در محیط تولید مجاز نیستند.

به منظور خودکارسازی چرخه حیات گواهی‌ها، مدیریت چرخه حیات گواهی‌ها به صورت خودکار انجام می‌شود: صدور، تمدید (قبل از انقضا)، ابطال در صورت افشای کلید خصوصی، و حذف امن گواهی‌های منقضی. تمام عملیات مدیریت گواهی در لاگ امنیتی ثبت می‌شود. گواهی‌ها حداقل هر ۱۳ ماه یکبار تمدید می‌شوند.

به منظور ارائه امن‌ترین پیکربندی ممکن، وب‌سرور به گونه‌ای پیکربندی شده است که تنها از TLS 1.3 پشتیبانی کرده و از رمزنگاری‌های ضعیف یا حالت‌های CBC خودداری می‌کند. قابلیت بازگشت (Fallback) به TLS 1.2 در صورت درخواست کلاینت مجاز نیست. همچنین، ویژگی‌های ناامن مانند SSL Compression، Renegotiation و Session Tickets غیرفعال شده‌اند.

به منظور انتخاب قوی‌ترین رمزنگاری‌ها، لیست رمزنگاری‌های فعال در سمت سرور به ترتیب اولویت: TLS_AES_256_GCM_SHA384، TLS_AES_128_GCM_SHA256. تمام رمزنگاری‌های مبتنی بر RSA بدون PFS (Perfect Forward Secrecy) و همچنین رمزنگاری‌های مبتنی بر CBC غیرفعال شده‌اند. طول کلیدهای تبادل حداقل ۳۰۷۲ بیت است.

به منظور تأمین محرمانگی کامل رو به جلو (Perfect Forward Secrecy)، لیست رمزنگاری‌های مجاز در سمت کلاینت محدود به TLS_AES_256_GCM_SHA384 و TLS_AES_128_GCM_SHA256 است. از تبادل کلید با استفاده از الگوریتم‌های ECDHE با منحنی‌های استاندارد (secp256r1، secp384r1) استفاده می‌شود. همچنین، پارامترهای DH به صورت اپیمیرال (Ephemeral) تولید می‌شوند.