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

به منظور پوشش یکی از مهم‌ترین ریسک‌های امنیتی (رتبه اول OWASP Top 10)، کنترل‌های دسترسی در تمام سطوح سیستم – از جمله رابط کاربری، APIها، و منابع پس‌زمینه – به صورت دقیق و مبتنی بر نقش کاربر پیاده‌سازی شده است. هر درخواست دسترسی به یک عملکرد حساس یا داده، مستقل از درخواست‌های قبلی، در سمت سرور بررسی می‌شود. از مکانیزم‌های دسترسی مبتنی بر ویژگی (Attribute-Based Access Control – ABAC) استفاده شده است که امکان تعریف سیاست‌های پیچیده را فراهم می‌کند. همچنین، به طور پیش‌فرض تمام دسترسی‌ها رد (Deny by Default) شده و تنها دسترسی‌های صریح مجاز تعریف گردیده‌اند. این مکانیزم از دسترسی غیرمجاز به منابع و عملکردهای حساس جلوگیری می‌کند.

برای آنکه مهاجم نتواند با تزریق کدهای CSS مخرب (مانند expression در IE قدیم یا url() برای بارگذاری منابع خارجی) ظاهر صفحه را تغییر دهد یا اطلاعات کاربر را بدزدد، ورودی‌هایی که به صورت داینامیک به ویژگی‌های CSS تزریق می‌شوند به شدت کنترل می‌گردند. از هرگونه درج مستقیم داده کاربر در بلوک‌های

برای جلوگیری از اجرای ناخواسته کد جاوااسکریپت مخرب (از طریق تزریق به رویدادهای DOM یا توابعی مانند eval، setTimeout با رشته، و Function)، در کدهای سمت کلاینت از حالت 'use strict' استفاده شده و بررسی‌های ایستا (Static Analysis) برای شناسایی الگوهای خطرناک اعمال گردیده است. همچنین، تمام داده‌های ورودی به توابع اجرایی با لیست سفید پاک‌سازی می‌شوند. علاوه بر این، سیاست unsafe-eval در CSP غیرفعال شده است تا هرگونه استفاده از eval حتی در کدهای مجاز نیز مسدود گردد. این کار ریسک حملات سمت کلاینت را به حداقل می‌رساند.

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

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

برای جلوگیری از حملات شرط رقابتی (Race Condition) که در آن مهاجم با ارسال همزمان چندین درخواست، سعی در دور زدن محدودیت‌ها یا ایجاد تناقض در وضعیت سیستم دارد، مکانیزم‌های قفل‌گذاری سطح پایگاه داده و قفل‌های توزیع‌شده (مانند Redis-based locks) به کار گرفته شده است. همچنین، برای عملیات حساس (مانند برداشت از حساب بانکی) از تراکنش‌های اتمیک و سریال‌شدنی (Serializable Isolation Level) استفاده شده است. علاوه بر این، محدودیت نرخ درخواست (Rate Limiting) بر اساس IP و شناسه کاربر اعمال گردیده تا تعداد درخواست‌های همزمان کنترل شود. این اقدامات حملات Race Condition را به طور مؤثری خنثی می‌کند.

با توجه به اینکه آسیب‌پذیری‌های XSS مبتنی بر DOM در سمت کلاینت و با دستکاری مستقیم DOM توسط کدهای جاوااسکریپت رخ می‌دهند، کدهای سمت کلاینت به گونه‌ای بازنویسی شده‌اند که از توابع ایمن مانند textContent، setAttribute و createElement به جای innerHTML، document.write و eval استفاده شود. همچنین، تمام داده‌های دریافتی از منابع ناشناس (مانند window.location.hash یا document.referrer) قبل از استفاده در DOM، اعتبارسنجی و رمزگذاری می‌شوند. استفاده از سیاست امنیت محتوا (CSP) با دستورالعمل script-src 'self' نیز اجرای اسکریپت‌های تزریقی را مسدود می‌کند.

به منظور جلوگیری از حملات تفکیک و قاچاق درخواست HTTP (که می‌توانند کنترل کش، دور زدن فایروال‌ها و آلوده کردن پاسخ‌ها را باعث شوند)، ساختار درخواست‌ها و پاسخ‌ها به طور کامل اعتبارسنجی می‌گردد. به ویژه، کاراکترهای جداساز مانند CRLF (\r\n) در هدرها و بدنه درخواست‌ها بررسی و رد می‌شوند. وب‌سرور به گونه‌ای پیکربندی شده است که درخواست‌های مبهم یا با هدرهای تکراری را به درستی مدیریت کرده و از تفسیر نادرست جلوگیری نماید. همچنین، از پروتکل HTTP/2 استفاده می‌شود که ذاتاً در برابر این حملات مقاومت بیشتری دارد.

برای آنکه مهاجم نتواند از پیام‌های خطا برای کسب اطلاعات فنی مانند مسیرهای فایل، نام کلاس‌ها، نسخه کتابخانه‌ها یا ساختار پایگاه داده استفاده کند، مدیریت خطاها به گونه‌ای پیاده‌سازی شده است که در محیط تولید (Production) هرگز ردیابی پشته (Stack Trace) به کاربر نمایش داده نمی‌شود. به جای آن، یک پیام عمومی و یکسان مانند «خطای داخلی سرور رخ داده است. لطفاً بعداً تلاش کنید.» نمایش داده می‌شود. تمام جزئیات فنی خطاها به طور امن در لاگ‌های سمت سرور ثبت می‌گردند و فقط در اختیار تیم پشتیبانی قرار می‌گیرند. این کار از افشای نقاط ضعف داخلی سیستم جلوگیری می‌کند.

با توجه به اینکه استفاده از الگوریتم‌های رمزنگاری ضعیف یا منسوخ (مانند DES، MD5، SHA-1، SSLv3) می‌تواند به راحتی توسط مهاجمان شکسته شود، تمام عملیات رمزنگاری مطابق با استانداردهای به‌روز NIST و OWASP پیاده‌سازی شده است. برای رمزگذاری داده‌ها از AES-256 در حالت GCM، برای درهم‌سازی از خانواده SHA-256 و بالاتر (با استفاده از salt برای رمزهای عبور مانند bcrypt)، و برای ارتباطات از TLS 1.3 استفاده می‌گردد. طول کلیدها حداقل ۲۰۴۸ بیت برای RSA و ۲۵۶ بیت برای ECC است. همچنین، از کتابخانه‌های رمزنگاری معتبر و به‌روز (مانند OpenSSL 3.x) بهره گرفته می‌شود.

برای آنکه مهاجم نتواند با تزریق دستورات SQL مخرب (مانند ' OR '1'='1) به پایگاه داده دسترسی غیرمجاز پیدا کند، به طور کامل از پرسوجوهای پارامترایز (Parameterized Queries) یا عبارات آماده (Prepared Statements) در تمام لایه‌های دسترسی به داده استفاده شده است. این روش، داده‌های ورودی کاربر را کاملاً از ساختار دستور SQL جدا می‌سازد و عملاً هرگونه تزریق را غیرممکن می‌کند. علاوه بر این، از ذخیره‌شده‌های رویه (Stored Procedures) با مجوزهای محدود استفاده گردیده و همچنین حساب کاربری پایگاه داده با اصل کمترین امتیاز (Least Privilege) پیکربندی شده است. این اقدام یکی از حیاتی‌ترین کنترل‌های امنیت برنامه محسوب می‌شود.

برای جلوگیری از این که مهاجم بتواند دستورات سیستمی مخرب (مانند ; rm -rf / یا | cat /etc/passwd) را از طریق ورودی‌های برنامه اجرا کند، تا حد امکان از فراخوانی مستقیم دستورات سیستمی خودداری شده و به جای آن از توابع کتابخانه‌ای امن استفاده گردیده است. در موارد نادر که نیاز به فراخوانی دستورات سیستمی اجتناب‌ناپذیر بوده، ورودی‌ها با لیست سفید (whitelist) از کاراکترهای مجاز اعتبارسنجی شده و از توابعی که شل را فراخوانی می‌کنند (مانند system() یا exec با شل) پرهیز شده است. همچنین، دستورات به صورت مطلق (با مسیر کامل) صدا زده شده و محیط اجرا با کمترین مجوز ممکن پیکربندی گردیده است.

با توجه به خطرناک‌تر بودن XSS ذخیره‌شده (چون کد مخرب در پایگاه داده ذخیره شده و برای همه کاربران نمایش داده می‌شود)، افزون بر اعتبارسنجی و رمزگذاری خروجی، از سیاست‌های اضافی مانند حذف تگ‌های HTML در ورودی‌های متنی (با استفاده از کتابخانه‌های امن مانند OWASP Java HTML Sanitizer) و همچنین اعمال سیاست sandbox برای محتوای کاربران استفاده شده است. تمام داده‌هایی که از پایگاه داده خوانده می‌شوند، قبل از نمایش دوباره رمزگذاری می‌گردند (حتی اگر قبلاً رمزگذاری شده باشند) تا از هرگونه امکان تزریق مجدد جلوگیری شود. این رویکرد از انتشار حملات گسترده به سایر کاربران جلوگیری می‌کند.

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

برای جلوگیری از اجرای اسکریپت‌های مخرب که از طریق پارامترهای بازتابی در URL یا فرم‌ها به مرورگر قربانی تزریق می‌شوند، ورودی‌های کاربر در دو مرحله کنترل می‌گردند: اول، اعتبارسنجی سخت‌گیرانه (Validation) از نظر نوع، طول و قالب داده (مثلاً بررسی می‌شود که یک فیلد ایمیل واقعاً حاوی کاراکتر @ باشد). دوم، در هنگام خروج (خروجی‌دهی)، تمام داده‌های کاربر با رمزگذاری متناسب با بافت (context-sensitive encoding) یعنی تبدیل کاراکترهای خطرناک مثل < به="">< و غیره، ایمن می‌شوند. همچنین از سیاست امنیت محتوا (csp) برای محدود کردن منابع اجرای اسکریپت استفاده شده است. این لایه‌های دفاعی باعث می‌شود حتی اگر ورودی مخرب به سرور برسد، در مرورگر اجرا نشود. و="" غیره،="" ایمن="" می‌شوند.="" همچنین="" از="" سیاست="" امنیت="" محتوا="" (csp)="" برای="" محدود="" کردن="" منابع="" اجرای="" اسکریپت="" استفاده="" شده="" است.="" این="" لایه‌های="" دفاعی="" باعث="" می‌شود="" حتی="" اگر="" ورودی="" مخرب="" به="" سرور="" برسد،="" در="" مرورگر="" اجرا="">

به منظور جلوگیری از دسترسی غیرمجاز در سیستم‌هایی که کاربر آنها را رها کرده است (مثلاً در کتابخانه یا کافی‌نت)، دو نوع زمان‌خوردگی برای نشست‌ها تعریف شده است: زمان‌خوردگی بی‌فعالیتی (idle timeout) به مدت ۱۵ دقیقه و زمان‌خوردگی مطلق (absolute timeout) به مدت ۸ ساعت. پس از هر بار عدم فعالیت به مدت ۱۵ دقیقه، نشست خودکار پایان یافته و کاربر باید دوباره وارد شود. همچنین، پس از ۸ ساعت صرف نظر از فعالیت، نشست باطل می‌گردد. این سیاست هم امنیت و هم تجربه کاربری را متعادل می‌کند.

برای آنکه اطلاعات حساس مرتبط با نشست (مانند نقش کاربر، مجوزها، یا داده‌های احراز هویت) در معرض دید کاربر یا کدهای سمت کلاینت قرار نگیرند، تمام متغیرهای نشست به صورت امن در سمت سرور نگهداری شده و هرگز به صورت آشکار در پاسخ‌های HTML، جاوااسکریپت یا هدرهای سفارشی قرار داده نمی‌شوند. حتی در هنگام ذخیره‌سازی موقت در سمت کلاینت (مانند کوکی‌های غیرحساس)، از رمزگذاری و امضای دیجیتال استفاده می‌گردد تا از دستکاری یا افشا جلوگیری شود. این کار ریسک سرقت نشست از طریق XSS یا sniffing شبکه را به شدت کاهش می‌دهد.

با توجه به اینکه شناسه نشست (Session ID) کلید دسترسی به حساب کاربری است، مدیریت نشست با بالاترین استانداردهای امنیتی پیاده‌سازی شده است. شناسه نشست با طول حداقل ۱۲۸ بیت و با استفاده از یک مولد اعداد تصادفی رمزنگاری قوی (CSPRNG) تولید می‌شود تا از پیش‌بینی‌پذیری جلوگیری گردد. همچنین، شناسه نشست تنها از طریق کوکی با پرچم‌های HttpOnly، Secure و SameSite=Strict منتقل شده و هرگز در URL، لاگ‌ها یا هدرهای سفارشی ظاهر نمی‌شود. این ساختار، جعل یا حدس Session ID توسط مهاجم را عملاً غیرممکن می‌سازد.

برای آنکه فرآیند بازیابی رمز عبور به عنوان یک دریچه ورود برای مهاجمان تبدیل نشود، سؤالات امنیتی با دقت بسیار بالا انتخاب شده‌اند. به جای سؤالات متداول و قابل حدس (مانند نام مادر یا شهر تولد که اغلب از طریق شبکه‌های اجتماعی قابل کشف هستند)، از سؤالات شخصی با پاسخ‌های غیرقطعی و چندگانه استفاده گردیده است. همچنین، پاسخ‌ها به صورت حساس به حروف کوچک/بزرگ و با هش کردن یکطرفه ذخیره شده‌اند. در ضمن، تعداد تلاش‌های مجاز برای پاسخ به سؤالات امنیتی محدود شده و در صورت شکست مکرر، روش بازیابی به کانال دیگری (مانند ایمیل یا پیامک) هدایت می‌گردد. بهترین رویکرد، جایگزینی کامل سؤالات امنیتی با احراز هویت دو مرحله‌ای (2FA) است که آن نیز پیاده‌سازی شده است.

برای آنکه کاربر نتواند با تغییر مستقیم یک پارامتر در URL یا درخواست (مانند ?id=1001 به ?id=1002) به اطلاعات کاربران دیگر دسترسی پیدا کند، کنترل دسترسی به طور کامل مبتنی بر سطح دسترسی کاربر و با استفاده از مراجع غیرمستقیم (Indirect References) پیاده‌سازی شده است. به جای استفاده از شناسه‌های ترتیبی یا قابل حدس، از توکن‌های تصادفی و یکبارمصرف به عنوان مرجع اشیاء استفاده می‌شود. همچنین، هر درخواست دسترسی به یک منبع، مستقل از درخواست‌های قبلی، در سمت سرور از نظر مجوز کاربر بررسی می‌گردد. این کار از جمله مهمترین کنترل‌ها برای جلوگیری از نقض کنترل دسترسی سطح شیء (IDOR) است.