امنیت در NodeJs از صفر تا صد! 10 آسیب پذیری NodeJs که نباید نادیده بگیرید!

10 آسیب پذیری NodeJs که هر توسعه دهنده باید بشناسد!
نود جی اس طی سالیان اخیر به یکی از مهم ترین فناوری های توسعه سمت سرور تبدیل شده است و بخاطر سرعت بالا و و مدل پردازشی غیر همزمان و مصرف بهینه ای که دارد مورد توجه خیلی از توسعه دهندگان قرار گرفته است.
اکوسیستم بسیار گسترده NPM باعث شده است بسیاری از شرکت ها و توسعه دهندگان از Nodejs برای ساخت API ها و سرویس های مبتنی بر میکروسرویس و برنامه های Real-Time و حتی سامانه های سازمانی بزرگ استفاده کنند! در واقع شرکت های بزرگ برای بخش های مختلفی از پروژه خود که نیازمند پاسخ سریع به درخواست ها داشتند از نود جی اس استفاده کردند و هزینه های سخت افزاری خود را هم به شدت کاهش دادند!
یک موضوع مهم که همیشه در سرویس هایی که رشد چشم گیری دارند به شکل یکسان وجود دارد این است که هر فناوری که به سرعت رشد می کند و در دسترس عموم قرار می گیرد باعث می شود توجه مهاجمان سایبری را به خود جلب کند!
در واقع هرچه بیشتر یک فناوری مورد استفاده قرار بگیرد و توسعه دهندگان زیادی از آن استفاده کنند به هدف های جذاب تری برای حملات تبدیل می شوند به همین دلیل دیگر نمی توان امنیت در پروژه های نود جی اس را یک موضوع ساده و سهل انگاری شده دانست بلکه در فرآیند توسعه آن را باید به عنوان یک اصل و هدف جدی در نظر گرفت!
شاید دانستن این موضوع بد نباشد که بسیاری از مشکلات امنیتی که در Nodejs رخ می دهد بخاطر ضعف خود این فناوری و پلتفرم نیست! یعنی نود جی اس در ذات سیستم امنی محسوب می شود و بسیاری از این آسیب پذیری ها ناشی از تصمیمات اشتباه در کدنویسی و پیاده سازی نادرست منطق برنامه، مدیریت نامناسب دسترسی ها، استفاده از وابستگی های ناامن و عدم رعایت اصول امنیتی در فرآیند توسعه هستند.
بسیاری از پروژه های نود جی اس به ده ها یا حتی صد ها کتابخانه npm وابسته هستند و هرکدام در زمان نصب می توانند پیش نیاز های خود را دانلود و دریافت کنند و تنها یک کتابخانه یا پیش نیاز کتابخانه ای که آسیب پذیر باشد می تواند امنیت کل سیستم را تحت تاثیر قرار دهد! علاوه بر این، ماهیت JavaScript و ویژگی هایی مانند Prototype ها نیز برخی چالش های امنیتی منحصر به فرد را به وجود آورده اند که در سایر زبان های برنامه نویسی کمتر مشاهده می شوند.
یک موضوع دیگر که عموما در این بحث باید به آن اشاره کرد این است که توسعه سریع محصولات نرم افزاری باعث شده در بسیاری از تیم ها امنیت به یک مقوله ثانویه تبدیل شود و تمرکز اصلی تیم توسعه دهنده صرفا برای قابلیت ها و ویژگی های نرم افزار و پروژه باشد و مسائل امنیتی به پایان پروژه موکول شود یا به شکل حساس و مهم به آن پرداخت نشود! در حال که اگر تیم توسعه دهنده بخواهد پس از پایان انتشار محصول به سراغ رفع عیب و فیکس کردن باگ های امنیتی سیستم برود هزینه و پیچیدگی های بسیار بیشتری نسبت به مراحل اولیه توسعه دارد!
دیگر امروزه نمی توان گفت امنیت تنها وظیفه تیم های امنیت سایبری یا مدیران زیرساخت ها می باشد بلکه هر توسعه دهنده Nodejs باید درک مناسبی از انواع تهدید ها و شیوه نفوذ و رخنه های امنیتی مهاجمان برای نفوذ به سیستم داشته باشد تا با آگاهی از این موارد نه تنها باعث محافظت از داده ها و زیرساخت سازمان شود بلکه از خسارت های مالی، افشای اطلاعات کاربران، اختلال در سرویس ها و آسیب به اعتبار کسب و کار نیز جلوگیری کند.
در این مقاله، مهم ترین آسیب پذیری های رایج در پروژه های Nodejs را بررسی می کنیم، نحوه عملکرد هر کدام را توضیح می دهیم و راهکار هایی عملی برای کاهش ریسک آن ها ارائه خواهیم کرد تا بتوان از همان ابتدای توسعه، امنیت را به عنوان بخشی جدایی ناپذیر از معماری نرم افزار در نظر گرفت.
چرا آگاهی از آسیب پذیری های امنیتی در Nodejs اهمیت دارد؟
همانطور که در ابتدا گفته شد بسیاری از توسعه دهندگان و تیم های نرم افزاری در ابتدای راه اندازی پروژه و حتی در مسیر یادگیری این پلتفرم تمام تمرکز اصلی خود را روی پیاده سازی قابلیت ها و افزایش سرعت پروژه خود قرار می دهند و به مقوله امنیت آن طور که باید و شاید اهمیت و بها نمی دهند! در چنین شرایطی که امنیت به یک موضوع ثانویه تبدیل می شود و بررسی آن عموما در مراحل پایانی پروژه موکول می شود نمی توان تمرکز صد در صدی روی آن قرار داد یا با وسواس آن را بررسی و پیاده سازی کرد!
نباید فراموش کنید که امروزه امنیت یکی از مهم ترین بخش های چرخه توسعه نرم افزار محسوب می شود به این خاطر که در صورت بروز رخنه امنیتی پیامدهای سنگینی می تواند به همراه داشته باشد و می تواند اعتبار یک برند و یک پروژه را یک شبه نابود کند!
عموما پروژه های مبتنی بر Nodejs معمولا وظیفه پردازش و مدیریت حجم زیادی از اطلاعات حساس را بر عهده دارند. اطلاعاتی مانند داده های کاربران، توکن های احراز هویت، اطلاعات مالی، فایل ها، داده های سازمانی و ارتباطات بین سرویس ها دائما در حال تبادل هستند. هرگونه ضعف امنیتی در این چرخه می تواند به نقطه ای برای نفوذ مهاجمان تبدیل شود.
همانطور که پیش تر به آن اشاره شد اکوسیستم بزرگ و گسترده npm در کنار تمام مزایایی فراوانی که دارد چالش های امنیتی متعددی نیز ایجاد کرده است! امروزه وابستگی بالایی که پروژه ها به تعداد زیادی از کتابخانه ها دارند باعث شده است که توسعه دهنده عموما بدون بررسی دقیق آن ها را به پروژه اضافه کند و در چنین شرایطی یک آسیب پذیری می تواند کل امنیت سامانه را به خطر بیندازد!
وقتی توسعه دهنده نسبت به آسیب پذیری های رایج آگاهی داشته باشد در همان ابتدای مسیر توسعه پروژه می تواند تصمیمات خود را مبتنی بر امنیت اتخاذ کند که در بسیاری از موارد رفع یک مشکل امنیتی در مرحله اولیه توسعه تنها چند دقیقه زمان نیاز دارد اما اگر همان مشکل پس از انتشار محصول بخواهد رفع شود ممکن است ساعت ها و یا حتی روز ها زمان و نیاز داشته باشد و هزینه ای که صرف فیکس کردن آن می شود خیلی بیشتر از مراحل ابتدایی هست.
بی توجهی به امنیت می تواند پیامد های متعددی ایجاد کند، از جمله:
افشای اطلاعات حساس کاربران
سرقت حساب های کاربری و سشن های فعال
دسترسی غیرمجاز به داده ها و سرویس ها
از دسترس خارج شدن سامانه در اثر حملات مخرب
سواستفاده از زیرساخت سازمان
آسیب به اعتبار و اعتماد کاربران
ایجاد خسارت های مالی و حقوقی برای کسب و کار
همیشه این نکته را مدنظر داشته باشید که امنیت یک فرآیند مقطعی نیست! بسیاری از توسعه دهندگان فکر می کنند با انجام چند تنظیم امنیتی سیستم را امن می کنند و کار به پایان می رسد! در حالی که امنیت یک فرآیند مداوم و همیشگی می باشد که باید در تمام مراحل طراحی، توسعه، استقرار، نگهداری و بروزرسانی نرم افزار مورد توجه قرار گیرد.
در واقع هدف از آشنایی با آسیب پذیری های امنیتی این نیست که شما به یک متخصص امنیت سایبری تبدیل شوید بلکه ایجاد این طرز فکر است که امنیت در فرآیند توسعه نرم افزار یک امر مهم و بدیهی محسوب می شود و توسعه دهنده ای که تهدیدات رایج را بشناسد می تواند قبل از اینکه مهاجمان نقاط ضعف برنامه را پیدا کنند آن ها را شناسایی و برطرف کند.
به همین دلیل، شناخت آسیب پذیری های رایج Nodejs را باید بخشی از مهارت های ضروری هر توسعه دهنده دانست نه یک موضوع جانبی و کم اهمیت!
آشنایی با رایج ترین آسیب پذیری های امنیتی در Nodejs:
تا بحث آسیب پذیری های امنیتی به میان می آید خیلی ها فکر می کنند حملات سایبری و هک شدن پروژه از تکنیک های پیچیده و ناشناخته استفاده می شود در حالیکه اکثر مهاجمان اغلب از ضعف هایی سواستفاده می کنند که سال هاست شناخته شده اند و در بسیاری از پروژه ها وجود دارند!
اعتبارسنجی نامناسب ورودی ها، مدیریت نادرست دسترسی ها، استفاده از کتابخانه های قدیمی و افشای اطلاعات حساس، تنها بخشی از این مشکلات هستند.
نکته مهم این است که بسیاری از این آسیب پذیری ها محدود به Nodejs نیستند و در سایر فناوری های توسعه وب نیز مشاهده می شوند. با این حال، برخی ویژگی های اکوسیستم Nodejs مانند وابستگی گسترده به پکیج های npm، استفاده فراگیر از JavaScript در سمت سرور و معماری پردازش غیرهمزمان، باعث شدند بعضی تهدیدات اهمیت بیشتری پیدا کنند.
شناخت این آسیب پذیری ها به توسعه دهندگان کمک می کند تا علاوه بر درک نحوه عملکرد مهاجمان، از همان ابتدای طراحی نرم افزار، تصمیمات امنیتی صحیح تری اتخاذ کنند. در ادامه، مهم ترین آسیب پذیری های رایج در پروژه های Nodejs، نحوه سواستفاده از آن ها و راهکار های مقابله با هرکدام را بررسی می کنیم.
1- تزریق کد یا همان Injection Attacks:
حملات تزریق کد یا همان Injection Attacks یکی از قدیمی ترین و در عین حال خطرناک ترین آسیب پذیری های امنیتی در توسعه نرم افزار محسوب می شود این حمله زمانی رخ می دهد که برنامه داده های ورودی کاربران را بدون اعتبار سنجی پاک سازی یا کنترل مناسب پردازش کند و آن ها را مستقیما در Query های پایگاه داده یا دستورات سیستم عامل یا سایر بخش های حساس سیستم مورد استفاده قرار دهد.
در چنین شرایطی وقتی این باگ در سیستم وجود داشته باشد مهاجم می تواند به جای ارسال داده های عادی! دستورات مخرب خود را به سیستم تزریق کند و رفتار برنامه را تغییر دهد و در واقع برنامه به جای اینکه ورودی کاربر را صرفا به عنوان یک داده در نظر بگیرد یک بخشی از دستورات اجرایی تفسیر می کند و آن را اجرا می کند.
در نود جی اس این حملات معمولا در سه دسته اصلی دیده می شوند:
SQL Injection:
این حمله زمانی انجام می شود که داده های کاربر مستقیما در Query های SQL قرار بگیرد! برای مثال اگر برنامه شناسه کاربر یا نام کاربری را بدون اعتبار سنجی در Query قرار دهد مهاجم می تواند ساختار آن را تغییر دهد و به اطلاعات مهم دسترسی پیدا کند و از آن برای ضربه زدن به سیستم استفاده کند.
پیامدهای این حمله می تواند شامل موارد زیر باشد:
مشاهده اطلاعات محرمانه کاربران
تغییر یا حذف داده های پایگاه داده
دور زدن مکانیزم احراز هویت
دسترسی غیرمجاز به بخش های مختلف سیستم
بنابراین این مورد اگر به درستی هندل نشود به شدت می تواند امنیت سیستم را مختل کند و مهاجم خیلی ساده به سیستم ضربه وارد کند.
NoSQL Injection:
بسیاری از پروژه های نود جی اس از پایگاه داده ی MongoDB استفاده می کنند که برخلاف تصور رایج استفاده از پایگاه داده های NoSQL به معنای امن بودن در برابر حملات تزریق نیست!
اگر ورودی های کاربر مستقیما در Query های MongoDB قرار گیرند، مهاجم می تواند از عملگرهایی مانند $ne ،$gt و $regex برای دور زدن محدودیت ها و استخراج اطلاعات استفاده کند.
این نوع حمله معمولا در سیستم های ورود کاربران، جستجو ها و API هایی که فیلترهای پویا دریافت می کنند، مشاهده می شود.
Command Injection:
یکی از خطرناک ترین انواع حملات تزریق، Command Injection است. این آسیب پذیری زمانی رخ می دهد که برنامه، داده های ورودی کاربر را مستقیما در دستورات سیستم عامل قرار دهد.
در Nodejs این مشکل اغلب هنگام استفاده نادرست از ماژول هایی مانند child_process ایجاد می شود.
در صورت موفقیت حمله، مهاجم ممکن است بتواند:
فایل های سرور را مشاهده کند!
فایل های مهم را حذف کند!
بدافزار اجرا کند!
کنترل بخشی از سرور را در اختیار بگیرد!
حملات تزریق عموما جزو آسیب پذیری هایی با ریسک بالا دسته بندی می شوند زیرا مستقیما با داده ها و زیرساخت اصلی سیستم در ارتباط می باشند و بسیاری از نفوذ های بزرگ از یک تزریق کد ساده شروع می شوند و به سادگی به کل سیستم دسترسی پیدا می کنند.
مهمتر از همه اینکه در بسیاری از موارد، این آسیب پذیری ناشی از چند خط کدنویسی نادرست است و با رعایت چند اصل ساده قابل پیشگیری خواهد بود.
راهکار های مقابله با Injection Attacks:
برخلاف اینکه این آسیب پذیری به شدت خطرناک هست و می تواند آسیب های جبران ناپذیری به سیستم وارد کند نحوه جلوگیری از آن خیلی دشوار نیست!
برای کاهش ریسک این نوع حملات، رعایت موارد زیر ضروری است:
تمام ورودی های کاربران را اعتبارسنجی یا Validation کنید.
داده های ورودی را قبل از استفاده، پاک سازی یا Sanitize کنید.
از Query های پارامتری Parameterized Queries استفاده کنید.
از اتصال مستقیم رشته ها برای ساخت Query ها خودداری کنید.
دسترسی حساب های پایگاه داده را بر اساس اصل حداقل دسترسی یا Least Privilege محدود کنید.
از کتابخانه ها و ORM های معتبر استفاده کنید.
از قرار دادن مستقیم ورودی کاربر در دستورات سیستم عامل خودداری کنید.
لاگ برداری و مانیتورینگ فعالیت های مشکوک را فعال کنید.
همیشه این نکته را در نظر داشته باشید که هیچ ورودی قابل اعتماد فرض نمی شود! حتی اگر داده از سمت فرانت اند می آید باید اعتبار سنجی شده باشد و همچنان باید در سرور مجددا بررسی شود.
با رعایت این موارد می توان جلوی یکی از بزرگترین آسیب پذیری هایی که ممکن است برای سیستم شما رخ دهد را بگیرید.
2- آسیب پذیری XSS:
حملات XSS یا Cross-Site Scripting یکی دیگر از رایج ترین آسیب پذیری های امنیتی در برنامه های تحت وب هستند که به مهاجم اجازه می دهند کد JavaScript مخرب خود را در مرورگر کاربران اجرا کند.
این آسیب پذیری زمانی رخ می دهد که برنامه داده های دریافت شده از کاربران را بدون پردازش و ایمن سازی مناسب در صفحات HTML نمایش می دهد! در چنین شرایطی مرورگر کاربر به جای اینکه محتوای ورودی را صرفا به عنوان داده در نظر بگیرد آن را به عنوان کد اجرایی تفسیر می کند!
اگر چه خود Nodejs مستقیما باعث ایجاد XSS نمی شود اما بسیاری از پروژه هایی مبتنی بر نود جی اس به دلیل تعامل بالایی که با فرانت اند و API ها و همچنین قابلیت ها Html دارند در معرض این نوع حملات قرار دارند.
حملات XSS معمولا در سه دسته اصلی قرار می گیرند که به هر کدام اشاره خواهیم کرد:
Stored XSS:
در این حمله کد مخرب در پایگاه داده ذخیره می شود و هر بار که سایر کاربران صفحه سایت را مشاهده می کنند آن کد در مرورگر آن ها اجرا می شود.
این نوع حملع در بخش هایی مانند :
سیستم نظرات کاربران
انجمن ها و فروم ها
پروفایل کاربران
بخش ثبت بازخورد
سیستم های گفتوگو
دیده می شود که می تواند تاثیرات منفی زیادی را ایجاد کند و مشکلات عدیده ای رخ دهد.
Reflected XSS:
در این حالت، کد مخرب در درخواست کاربر قرار می گیرد و بلافاصله در پاسخ سرور به او بازگردانده می شود.
مهاجم معمولا یک لینک مخرب ایجاد می کند و قربانی را ترغیب می کند تا روی آن کلیک کند.
این حمله اغلب در موارد زیر مشاهده میشود:
صفحات جستجو
فرم های دریافت اطلاعات
صفحات خطا
پارامترهای URL
DOM-Based XSS:
در این نوع حمله، مشکل در سمت مرورگر و کدهای JavaScript فرانت اند ایجاد می شود.
در این روش، JavaScript موجود در صفحه بدون اعتبارسنجی مناسب، داده های دریافتی را مستقیما در DOM قرار می دهد و همین موضوع باعث اجرای کد های مخرب می شود.
اثرات مخرب این حملات:
خیلی از توسعه دهندگان شدت این آسیب پذیری را دست کم میگیرند و تصور می کنند قرار نیست مشکل جدی برای پروژه رخ دهد این در حالی است که XSS می تواند پیامد های بسیار خطرناکی برای پروژه ایجاد کند.
از جمله:
سرقت کوکی های کاربران
سرقت سشن های فعال
دسترسی غیرمجاز به حساب های کاربری
تغییر محتوای صفحات وب
هدایت کاربران به صفحات فیشینگ
سرقت توکن های احراز هویت
اجرای درخواست های ناخواسته از طرف کاربر
دسترسی به اطلاعات حساس موجود در مرورگر
خطر اصلی در واقع این است که مهاجم سرور را مستقیم هدف قرار نمی دهد بلکه از اعتماد مرورگر کاربر سواستفاده می کند و به مواردی که نیاز دارد دست پیدا می کند.
از دید مرورگرر در واقع کد مخرب از طرف وب سایت و پروژه معتبری که در آن قرار دارد اجرا شده است و به همین دلیل ممکن است به بخش های حساسی دسترسی پیدا کند! هرچه تعداد کاربران یک سامانه بیشتر باشد طبیعی هست که این حملات هم باید بیشتر جدی گرفته شود و شدت و اثرگذاری این حملات افزایش پیدا می کند.
راهکارهای مقابله با XSS:
برای جلوگیری از بروز این آسیب پذیری، رعایت موارد زیر ضروری است:
تمام داده های خروجی HTML را Escape کنید.
هرگز داده های کاربر را مستقیما در HTML قرار ندهید.
از Template Engine های امن استفاده کنید.
از کتابخانههای Sanitization برای پاک سازی داده ها استفاده کنید.
از استفاده مستقیم از innerHTML خودداری کنید.
تا حد امکان از textContent یا innerText استفاده کنید.
سیاست امنیت محتوا Content Security Policy یا CSP را پیاده سازی کنید.
ورودی های کاربران را در سمت سرور اعتبار سنجی کنید.
کوکی های حساس را با ویژگی های HttpOnly و Secure محافظت کنید.
نکته مهم این است که مقابله با XSS تنها به اعتبارسنجی ورودی ها محدود نمی شود. بخش مهمی از این موضوع به نحوه نمایش داده ها در خروجی مربوط است. به همین دلیل، باید تمام داده های کاربران را تا زمانی که ایمن بودن آن ها اثبات نشده است، غیرقابل اعتماد در نظر گرفت.
تنها با این شیوه می توان تا حد بسیار خوبی جلوی این حملات گرفته شود و از مشکلات احتمالی جلوگیری شود.
3- حملات CSRF:
حملات CSRF یا Cross-Site Request Forgery یکی از آسیب پذیری های رایج در برنامه ها و پروژه های تحت وب می باشد که در آن مهاجم کاربر احراز هویت شده را فریب می دهد تا بدون آگاهی و بدون اطلاع خود درخواست ناخواسته ای را به سمت سرور ارسال کند!
در این حمله هدف مهاجم این نیست که به حساب کاربری دسترسی پیدا کند بلکه می خواهد از اعتماد سیستم به کاربری که قبلا وارد آن شده سواستفاده کند تا درخواست ناخواسته ای را به سرور ارسال کند.
با یک مثال ساده برای درک بهتر موضوع می توان گفت فرض کنید شخصی وارد حساب بانکی خود شده است و هنوز سشن کاربر فعال می باشد اگر این کاربر وارد یک وب سایت مخرب شود مهاجم می تواند بدون اطلاع کاربر درخواست هایی مانند انتقال وجه و تغییر رمز عبور و حتی تغییر ایمیل حساب کاربری را انجام دهد!
از آنجایی که مرورگر به صورت خودکار کوکی ها و اطلاعات احراز هویت را همراه درخواست ارسال می کند، سرور تصور می کند که این درخواست توسط خود کاربر انجام شده است.
CSRF چگونه اتفاق می افتد؟
این حمله زمانی اتفاق می افتد که سه شرط همزمان برقرار باشد!
کاربر در سامانه احراز هویت شده باشد.
سشن کاربر همچنان فعال باشد.
برنامه هیچ مکانیزمی برای تشخیص درخواست های معتبر از درخواست های جعلی نداشته باشد!
هرچه عملیات حساس بیشتری از طریق درخواست های HTTP انجام شوند اهمیت مقابله با این آسیب پذیری ها نیز بیشتر می شود.
برخلاف بسیاری از حملات رایج دیگر در این حمله مهاجم مستقیم به سیستم نفوذ نمی کند بلکه از اعتبارسنجی و دسترسی هایی که خود کاربر دارد سواستفاده می کند.
به همین دلیل تشخیص این حملات در برخی موارد ممکن است دشوار و زمانبر باشد زیرا درخواست از دید سرور کاملا معتبر به نظر می رسد!
در صورت موفقیت حمله، مهاجم می تواند اقداماتی را از طرف کاربر انجام دهد که منجر به خسارت های مالی، تغییر اطلاعات مهم یا از دست رفتن کنترل حساب کاربری شود.
راهکارهای مقابله با حملات CSRF:
برای جلوگیری از این آسیب پذیری، رعایت موارد زیر ضروری است:
از CSRF Token برای تمام عملیات حساس استفاده کنید.
ویژگی SameSite را برای کوکی ها فعال کنید.
هدرهای Origin و Referer را بررسی کنید.
برای عملیات حساس از درخواست های POST، PUT و DELETE استفاده کنید و از انجام آن ها از طریق GET خودداری کنید.
برای عملیات مهم، احراز هویت مجدد یا تایید چندمرحله ای در نظر بگیرید.
زمان اعتبار سشن های کاربران را مدیریت کنید و از قرار دادن تایم های طولانی اجتناب کنید!
از فریم ورک ها و Middleware های امنیتی معتبر استفاده کنید.
نکته مهم این است که امروزه بسیاری از برنامه ها از JWT به جای Session های سنتی استفاده می کنند. با این حال، اگر JWT داخل کوکیه ا ذخیره شود، همچنان احتمال وقوع حملات CSRF وجود دارد. بنابراین نوع ذخیره سازی اطلاعات احراز هویت نیز در امنیت برنامه نقش بسیار مهمی ایفا می کند.
4- نقص در احراز هویت و مدیریت سشن:
احراز هویت و مدیریت سشن یکی دیگر از موارد مهمی هست که در برنامه ای باید آن را به درستی مدیریت کند چون این دو مکانیزم مشخص می کند چه کسی به سیستم دسترسی دارد و هر کاربر تا چه مدت زمانی مجاز به استفاده از سرویس هست!
اگر این دو مورد به درستی مدیریت نشوند تبدیل به یک معضل اصلی می شوند که امکان نفوذ به سامانه را فراهم می کنند و مهاجمان برای سواستفاده از این آسیب پذیری نیاز به اقدامات و موارد پیچیده ندارند! و تنها با استفاده از ضعف های موجود در ورود کاربران به حساب کاربری دسترسی پیدا می کنند.
در سیستم های نود جی اس بسیاری از پروژه ها از JWT، Session ها و کوکی ها برای مدیریت احراز هویت استفاده می کنند. هرگونه پیکربندی نادرست در این بخش ها میتواند امنیت کل سامانه را تحت تاثیر قرار دهد.
این مشکل معمولاً به شکلهای مختلفی ظاهر میشود.
استفاده از JWT بدون زمان انقضا:
برخی از توسعه دهندگان توکن های JWT را بدون زمان انقضا ایجاد می کنند یا زمان اعتبار بسیار طولانی برای آن ها در نظر میگیرند در چنین شرایطی اگر مهاجم به توکن دسترسی پیدا کند ممکن است برای مدت زمان طولانی از آن سواستفاده کند.
استفاده از رمز های عبور ضعیف:
رمز عبور های ضعیف و کوتاه همیشه یکی از معضلاتی هست که در بحث امنیتی رخ می دهد و اگر به درستی از رمز های پیچیده با کاراکتر های خاص استفاده نشود احتمال موفقیت حملاتی مانند Brute Force افزایش پیدا می کند.
همیشه در انتخاب پسورد باید پیچیدگی را در نظر گرفت و از یادداشت کردن پسورد به طور کامل هم خودداری کنید.
ذخیره سازی ناامن Session ها:
ذخیره Session ها در حافظه داخلی سرور یا نگهداری اطلاعات حساس بدون رمزنگاری مناسب می تواند ریسک نفوذ را افزایش دهد.
همچنین ذخیره سازی نامناسب توکن ها در سمت کاربر نیز خطرات امنیتی متعددی ایجاد می کند.
نبود محدودیت در تعداد تلاش های ورود:
اگر محدودیتی برای تعداد دفعات ورود ناموفق وجود نداشته باشد، مهاجم میتواند هزاران ترکیب مختلف از نام کاربری و رمز عبور را امتحان کند.
استفاده از Secrets های ضعیف:
استفاده از Secret های قابل حدس یا قراردادن آن ها داخل مخزن کد یکی دیگر از اشتباهات رایج است.
احراز هویت دقیقا همان بخشی هست که می توان به سیستم وارد شد اگر این بخش به درستی پیاده سازی نشود، بسیاری از مکانیزم های امنیتی دیگر نیز بی اثر خواهند شد.
حتی اگر برنامه در برابر حملاتی مانند SQL Injection یا XSS ایمن باشد، ضعف در سیستم ورود کاربران همچنان می تواند مهاجم را به اهداف خود برساند.
راهکارهای مقابله با نقص در احراز هویت و مدیریت سشن:
برای افزایش امنیت این بخش، رعایت موارد زیر ضروری است:
از الگوریتم های قدرتمندی مانند bcrypt یا Argon2 برای هش کردن رمزهای عبور استفاده کنید.
احراز هویت چند مرحله ای را فعال کنید.
برای JWT زمان انقضای مناسب تعیین کنید.
از Refresh Token ها به صورت ایمن استفاده کنید.
برای فرم های ورود، مکانیزم Rate Limiting پیاده سازی کنید.
رمزهای عبور ضعیف را نپذیرید و حداقل استاندارد های امنیتی را اعمال کنید.
Session ها را در محل امنی مانند Redis ذخیره کنید.
از ویژگیهای HttpOnly ،Secure و SameSite برای کوکی ها استفاده کنید.
کلیدهای محرمانه را در Environment Variables نگهداری کنید.
سشن های غیرفعال را به صورت خودکار منقضی کنید.
امکان خروج از تمام دستگاه ها را فراهم کنید.
نکته مهم این است که امنیت احراز هویت فقط به انتخاب بین Session و JWT محدود نمی شود. هیچکدام ذاتا امن تر از دیگری نیستند و امنیت نهایی به نحوه پیاده سازی، نگهداری و مدیریت آن ها بستگی دارد.
5- Broken Access Control یا نقص در کنترل دسترسی:
کنترل دستی مجموعه از قوانین هست که تعیین می کند که هر کابر تا چه اندازه به بخش های مختلف سیستم دسترسی دارد! طبیعی هست که دسترسی که یک مدیر دارد با یک کارمند تفاوت دارد و کاربرهای عادی هم باید حداقل دسترسی ها را داشته باشند!
آسیب پذیری در این بخش زمانی رخ می دهد که محدودیت هایی که برای دسترسی ها باید اعمال شود به درستی انجام نشود و کاربران بتوانند به منابع و اطلاعاتی دسترسی پیدا کنند که مجاز به استفاده از آن در حالت عادی نیستند!
این باگ امنیتی یکی از مواردی که هست باعث افشای اطلاعات کاربران محسوب می شود و در پروژه های نود جی اس این مشکل معمولا در API ها، پنل مدیریتی و سرویس هایی که با داده های کاربران سر و کار دارند دیده می شود.
خیلی از توسعه دهندگان در سمت فرانت اند دسترسی ها را محدود می کنند و تصور می کنند مخفی کردن دکمه ها یا صفحات برای جلوگیری از دسترسی غیرمجاز کافی هست و در حالی که مهاجمان مستقیم با API ارتباط برقرار می کنند و هیچ اعتماد به محدودیت های سمت کاربر وجود ندارد!
برای مثال، فرض کنید کاربری درخواست زیر را ارسال می کند:
/api/users/125
اگر کاربر بتواند با تغییر شناسه به مقدار دیگری مانند:
/api/users/126
به اطلاعات سایر کاربران دسترسی پیدا کند، سیستم دچار نقص کنترل دسترسی شده است.
نمونه های رایج Broken Access Control:
این آسیب پذیری می تواند به شکل های مختلفی ظاهر شود! کاربران می توانند با تغییر شناسه ها در URL یا درخواست های API به داده دیگران دسترسی پیدا کنند!
برخی کاربران عادی می توانند به صفحات مخصوص مدیران سیستم دسترسی پیدا کنند!
کاربران قادر خواهند بود مقادیر مربوط به نقش Roles را دستکاری کنند و مجوز بیشتری به دست بیاورند.
فایل هایی که باید محدود باشند، بدون کنترل مناسب در دسترس قرار می گیرند.
برنامه برای تصمیم گیری درباره مجوزها به داده هایی که از مرورگر دریافت می کند اعتماد می کند.
چرا این آسیب پذیری خطرناک است؟
خطر اصلی این باگ امنیتی این است که مهاجم لزومی ندارد که وقت بگذارد و سیستم را هک کند! او با دسترسی های قانونی خود محدودیت هایی که به درستی پیاده سازی نشدند را دور می زند!
بسیاری از این حملات ممکن است برای مدت طولانی شناسایی نشود زیرا تمام درخواست ها از حساب کاربری معتبر ارسال می شوند.
برای جلوگیری از این آسیب پذیری، رعایت موارد زیر ضروری است:
تمام مجوزها را در سمت سرور بررسی کنید.
هرگز به داده های ارسال شده از سمت کاربر اعتماد نکنید.
از پیادهسازی Role-Based Access Control (RBAC) استفاده کنید.
در صورت نیاز، از Attribute-Based Access Control (ABAC) بهره ببرید.
برای هر درخواست، هویت کاربر و سطح دسترسی او را مجددا بررسی کنید.
از شناسه های غیرقابل حدس مانند UUID استفاده کنید.
پنل های مدیریتی را با لایه های امنیتی بیشتری محافظت کنید.
تمام عملیات حساس را ثبت و مانیتور کنید.
اصل حداقل دسترسی Least Privilege را در کل سیستم رعایت کنید.
این نکته را فراموش نکنید که کنترل دسترسی یک قابلیت در فرانت اند نیست بلکه یک مسئولیت کاملا سمت سرور می باشد! حتی اگر شما یک صفحه یا دکمه را در رابط کاربری نشان ندهید همچنان باید از سمت سرور بررسی شود که آیا کاربر مجاز به انجام عملیات هست یا خیر!
6- Prototype Pollution:
یک آسیب پذیری که کمتر در میان توسعه دهندگان شناخته شده هست و به طور خاص برای جاوا اسکریپت هست آسیب پذیری Prototype Pollution می باشد!
در این آسیب پذیری مهاجم می تواند با دستکاری Prototype اشیا رفتار بخش های مختلف برنامه را تغییر دهد!
در جاوا اسکریپت تقریبا تمام اشیا از یک Prototype به ارث می برند و اگر برنامه بدون اعتبار سنجی مناسب داده های دریافت کاربران را با اشیای داخلی ترکیب کند مهاجم ممکن است بتواند مقادیر مخربی را به Prototype سراسری برنامه تزریق کند و رفتار کلی سیستم را تغییر دهد.
Prototype Pollution یکی از آسیبپذیریهای خاص اکوسیستم JavaScript است که در آن مهاجم میتواند با دستکاری Prototype اشیا، رفتار بخشهای مختلف برنامه را تغییر دهد.
این آسیب پذیری در بسیاری از پروژه های Nodejs مشاهده شده و در گذشته نیز برخی از کتابخانه های پرکاربرد npm به دلیل وجود چنین مشکلاتی آسیبپذیر بودند.
این آسیب پذیری چگونه اتفاق می افتد؟
این مشکل عموما زمانی ایجاد می شود که برنامه داده های ناشناس را بدون بررسی با اشیای موجود ادغام می کند! برای مثال اگر برنامه به کاربران اجازه دهد یک شی JSON ارسال کند و همان داده مستقیما با تنظیمات داخلی برنامه ترکیب شود مهاجم می تواند خصوصیات ويژه جاوا اسکریپت را دستکاری کند!
از جمله:
__proto__
prototype
constructor
این آسیب پذیری معمولا در شرایط زیر دیده می شود:
ادغام مستقیم اشیا با استفاده از توابع Merge
استفاده از کتابخانه های قدیمی و آسیب پذیر
پردازش دادههای JSON بدون اعتبارسنجی مناسب
استفاده نادرست از Object Assignment
پیاده سازی های سفارشی برای ادغام اشیا
شدت و تاثیر این حمله به ساختار برنامه بستگی دارد و برای هر پروژه ای یکسان نیست اما به طور کلی این آسیب پذیری می تواند پیامد های خطرناکی مانند:
تغییر رفتار بخش های مختلف برنامه
دور زدن برخی مکانیزم های امنیتی
افزایش سطح دسترسی کاربران
ایجاد خطا های غیرمنتظره در سیستم
اختلال در عملکرد برنامه
فراهم شدن زمینه برای حملات زنجیره ای دیگر
در برخی موارد، اجرای کد از راه دور
چرا این آسیب پذیری خطرناک است؟
علت این که این آسیب پذیری خیلی خطرناک می باشد این است که در واقع تشخیص آن بسیار دشوارد هست!
در بسیاری از موارد برنامه ظاهرا به درستی کار می کند اما برخی اشیا در پشت صحنه تغییر کردند و همین موضوع باعث می شود یافتن منبع مشکل زمان بر و پیچیده شود!
از طرف دیگر این آسیب پذیری می تواند روی تمام بخش های برنامه اثر بگذارد چون Prototype یک ساختار مشترک در جاوا اسکریپت محسوب می شود!
راهکارهای مقابله با Prototype Pollution:
برای جلوگیری از این آسیب پذیری، رعایت موارد زیر ضروری است:
هرگز داده های ناشناس را مستقیما با اشیای داخلی برنامه ادغام نکنید.
ورودیهای کاربران را به دقت اعتبارسنجی کنید.
دسترسی به کلید های __proto__ ،prototype و constructor را مسدود کنید.
کتابخانه های npm را به صورت مداوم بروزرسانی کنید.
از کتابخانه های معتبر برای پردازش اشیا استفاده کنید.
در بخشهای حساس از Object.create(null) استفاده کنید.
از ایجاد توابع Merge سفارشی غیرضروری خودداری کنید.
وابستگی های پروژه را به صورت مداوم بررسی و پایش کنید.
با انجام موارد گفته شده تا حد زیادی جلوی این مشکل ار می توانید بگیرید تا پروژه بدون مشکل به کار خود ادامه دهد.
7- آسیب پذیری های وابستگی ها:
همانطور که قبلا هم به آن اشاره شد یکی از مهمترین ویژگی های مثبت نود جی اس وجود اکوسیستم گسترده npm و دسترسی به میلیون ها کتابخانه آماده می باشد این موضوع باعث افزایش سرعت توسعه و کاهش زمان پیاده سازی می شود و نیاز نیست برای هر ویژگی مجدد از صفر کدنویسی کرد!
همین مزیت که بسیار هم مزیت خوب و فوق العاده ای هست می تواند به یک چالش بزرگ امنیتی هم بدل شود!
بسیاری از پروژه های نود جی اس به صد ها و گاهی هزاران وابستگی مستقیم و غیرمستقیم نیاز دارند که در چنین شرایطی وجود تنها یک کتابخانه آسیب پذیر می تواند امنیت کل سامانه را به خطر بیندازد!
این نکته را هم فراموش نکنید که یک توسعه دهنده معمولا فقط چند کتابخانه اصلی را به پروژه اضافه می کند اما هر کدام از این کتابخانه ها ممکن است ده ها وابستگی را نیز پروژه وارد کنند! در نتیجه حجم کدهایی که وارد برنامه می شوند بسیار بیشتر از چیزی هست که در ابتدا تصور می شود!
مشکلات مربوط به وابستگی ها معمولا به دلایل زیر رخ می دهند:
استفاده از نسخه های قدیمی کتابخانه ها
استفاده از پکیج های رهاشده و بدون پشتیبانی
نصب کتابخانه های غیرضروری
استفاده از پکیج های ناشناس و غیرقابل اعتماد
بروزرسانی نکردن وابستگی ها
استفاده از پکیج هایی که دارای آسیب پذیری شناخته شده هستند!
حملات Supply Chain Attacks:
یکی از حملات خطرناکی که در نود جی اس دیده می شود حملات زنجیره تامین می باشد! در این حمله مهاجم مستقیم برنامه شما را مورد هدف قرار نمی دهد بلکه یک کتابخانه یا یکی از وابستگی های آن را آلوده می کند!
از آنجایی که توسعه دهنده عموما به کتابخانه هایی که استفاده می کند اعتماد دارد کد مخرب می تواند بدون هیچ مشکلی و حتی متوجه شدن توسعه دهنده وارد پروژه شود این حملات در سال های اخیر به یکی از بزرگترین تهدیدات تبدیل شده است!
وجود وابستگی های ناامن می تواند مشکلات متعددی ایجاد کند، از جمله:
افشای اطلاعات حساس
اجرای کد مخرب روی سرور
سرقت اطلاعات کاربران
ایجاد در های پشتی Backdoor
اختلال در عملکرد سامانه
افزایش سطح دسترسی مهاجمان
آلوده شدن زیرساخت سازمان
خطر اصلی این مشکل زمانی ایجاد می شود که یک توسعه دهنده به کدهایی که توسط افراد دیگر نوشته شده است بیش از حد اعتماد می کند! در بسیاری از موارد توسعه دهنده از کتابخانه هایی استفاده می کند بدون آن که بداند در پشت صحنه چه اتفاق هایی در حال رخ دادن می باشد و چه تعداد وابستگی دیگر هم به کتابخانه اضافه شده است!
همچنین برخی از آسیب پذیری ها ممکن است برای مدت طولانی بدون شناسایی در پروژه باقی بمانند و تنها پس از انتشار عمومی مورد سواستفاده قرار گیرند.
برای کاهش ریسک این تهدیدات، رعایت موارد زیر ضروری است:
به صورت منظم دستور npm audit را اجرا کنید.
وابستگی ها را بروزرسانی کنید.
پکیج های غیرضروری را حذف کنید.
قبل از استفاده، اعتبار و سابقه توسعه دهندگان کتابخانه را بررسی کنید.
فقط از کتابخانه های شناخته شده و فعال استفاده کنید.
تعداد وابستگی های پروژه را تا حد امکان کاهش دهید.
فایلهای package-lock.json را مدیریت و نگهداری کنید.
از ابزارهای خودکار پایش امنیت وابستگی ها استفاده کنید.
نسخه های قدیمی و بدون پشتیبانی را کنار بگذارید.
وابستگی های مستقیم و غیر مستقیم را به صورت دوره ای بررسی کنید.
این نکته را هیچ وقت فراموش نکنید که استفاده بیش از حد از کتابخانه ها لزوما به این معنا نیست که توسعه بهتر و قدرتمند تری انجام شده است!
هر کتابخانه می تواند امکان حمله را افزایش دهد به همین دلیل یکی از اصول پایه در توسعه نرم افزار این است که تا حد امکان وابستگی های کمتری پروژه داشته باشد!
8- حملات DoS و مصرف بیش از حد منابع:
حملات Dos با هدف از دسترس خارج کردن سرویس انجام می شود! یعنی برای ضربه زدن به پروژه اصلا نفوذی صورت نمی گیرد بلکه مهاجم تلاش می کند منابع سیستم را به گونه ای اشغال کند که سرور دیگر قادر به پاسخ گویی به درخواست های واقعی کاربران نباشد!
این نوع حمله در تمام پلتفرم های سمت سرور وجود دارد اما معماری خاص نود جی اس باعث می شود در برخی موارد این حملات Dos اهمیت بیشتری پیدا کند!
نود جی اس بر پایه یک Event Loop و معماری تک ریسمانی برای اجرای کد های JavaScript کار می کند. این معماری برای پردازش همزمان تعداد زیادی درخواست بسیار بهینه است، اما اگر یک عملیات پردازشی سنگین یا مسدود کننده وارد چرخه اجرا شود، میتواند کل فرآیند پاسخگویی را مختل کند.
به همین دلیل، تنها یک درخواست مخرب یا تعداد زیادی درخواست همزمان ممکن است باعث کاهش شدید عملکرد یا از دسترس خارج شدن سرویس شود.
مهاجمان از روش های مختلفی برای مصرف بیش از حد منابع استفاده میکنند.
برخی از رایج ترین سناریو ها عبارتند از:
مهاجم با ارسال حجم زیادی از درخواست ها، منابع سرور را اشغال می کند.
بارگذاری فایل های بزرگ می تواند حافظه سرور را تحت فشار قرار دهد.
انجام عملیات پیچیده روی داده ها، فشرده سازی فایل ها، پردازش تصاویر یا محاسبات سنگین داخل Thread اصلی می تواند Event Loop را مسدود کند.
کوئری های سنگین پایگاه داده نیز می توانند زمان پاسخگویی سیستم را به شدت افزایش دهند.
پیامدهای این آسیب پذیری:
حملات DoS می توانند مشکلات متعددی ایجاد کنند، از جمله:
کند شدن شدید سیستم
افزایش مصرف CPU و حافظه
از دسترس خارج شدن سرویس
اختلال در تجربه کاربران
افزایش هزینه های زیرساخت
ناپایداری سامانه
در Nodejs بسیاری از عملیات از یک Event Loop مشترک استفاده می کنند. بنابراین مسدود شدن یک بخش می تواند روی کل برنامه تاثیر بگذارد.
به همین دلیل، حتی حملاتی که حجم ترافیک بسیار زیادی ندارند نیز ممکن است در صورت سواستفاده از نقاط ضعف برنامه، باعث اختلال جدی شوند.
راهکارهای مقابله با حملات DoS:
برای کاهش ریسک این حملات، رعایت موارد زیر ضروری است:
برای API ها مکانیزم Rate Limiting پیاده سازی کنید.
حجم درخواست های ورودی را محدود کنید.
برای تمام درخواست ها Timeout تعیین کنید.
از Queue برای پردازش وظایف سنگین استفاده کنید.
پردازش های سنگین را از Event Loop اصلی خارج کنید.
از Worker Threads یا سرویس های جداگانه برای محاسبات سنگین استفاده کنید.
محدودیت مناسبی برای بارگذاری فایل ها تعیین کنید.
از سیستم های کش استفاده کنید.
مصرف CPU، حافظه و زمان پاسخگویی سیستم را به صورت مداوم مانیتور کنید.
نکته مهم این است که معماری تک ریسمانی بود نود جی اس به معنای ضعیف بودن آن در فشار بالا نیست.
مشکل زمانی ایجاد می شود که توسعه دهندگان عملیات مسدود کننده و پردازش های سنگین را مستقیما داخل Event Loop اجرا کنند. طراحی صحیح معماری برنامه نقش بسیار مهمی در جلوگیری از این نوع حملات دارد.
9- آسیب پذیری Path Traversal:
Path Traversal که با نام Directory Traversal نیز شناخته می شود، یکی از آسیب پذیری های مهمی هست که به مهاجم اضافه می دهد به فایل ها و دایرکتوری های خارج از محدوده مجاز برنامه دسترسی پیدا کند!
این آسیب پذیری معمولا زمانی رخ می دهد که برنامه مسیر فایل را مستقیما از ورودی کاربر دریافت می کند و بدون اعتبار سنجی مناسب از آن برای خواندن یا نوشتن و حتی دانلود فایل استفاده می کند!
در چنین شرایطی مهاجم می تواند با دستکاری مسیر ها از پوشه های مجاز خارج شده و به فایل های حساس سیستم عامل یا فایل های داخلی برنامه دسترسی پیدا کند!
در پروژه های نود جی اس این مشکل بیشتر در بخش هایی مشاهده می شود که با آپلود و دانلود فایل و مدیریت اسناد و نمایش تصاویر سر و کار دارند!
این آسیب پذیری چگونه اتفاق می افتد؟
بسیاری از برنامه ها نام فایل را از کاربر دریافت می کنند و سپس آن را مستقیما به توابع مربوط به سیستم فایل ارسال می کنند.
مهاجم میتواند با استفاده از الگوهای پیمایش دایرکتوری، از مسیر تعیین شده خارج شود.
برای مثال، از کاراکترهایی مانند موارد زیر سواستفاده می شود:
../
..\\
نسخههای URL Encode شده این مقادیر
هدف اصلی، حرکت به پوشه های بالاتر و دسترسی به فایل هایی است که نباید در اختیار کاربران قرار بگیرند.
این آسیب پذیری معمولا در بخش های زیر مشاهده می شود:
سیستم دانلود فایل ها
سیستم آپلود فایل ها
سرویس دهی فایل های استاتیک
نمایش تصاویر و اسناد
سیستم های تولید گزارش
API های مدیریت فایل
خطر اصلی Path Traversal این است که مهاجم بدون نیاز به دسترسی مستقیم به سرور، می تواند به اطلاعات بسیار حساسی دست پیدا کند.
در بسیاری از موارد، فایلهای کانفیگ شامل اطلاعات مهمی مانند رمز های عبور پایگاه داده، توکن ها، کلید های API و اطلاعات سرویس های داخلی هستند.
همین اطلاعات برای سواستفاده کامل از پروژه کافی می باشد و می تواند زمینه ساز حملات گسترده تری شود!
راهکار های مقابله با Path Traversal:
برای جلوگیری از این آسیب پذیری، رعایت موارد زیر ضروری است:
نام فایل های دریافتی از کاربران را اعتبارسنجی کنید.
از مسیرهای ثابت و محدود استفاده کنید.
هرگز ورودی کاربر را مستقیما در توابع فایل به کار نبرید.
از توابع استانداردی مانند path.normalize() و path.resolve() با دقت استفاده کنید.
دسترسی فایل ها را به یک دایرکتوری مشخص محدود کنید.
کاراکترها و الگوهای خطرناک مانند ../ را مسدود کنید.
سطح دسترسی فرآیند نود جی اس را محدود کنید.
فایل های حساس را خارج از دایرکتوری قابل دسترس برنامه نگهداری کنید.
برای فایل های قابل دانلود از شناسه های داخلی استفاده کنید، نه مسیر واقعی فایل ها.
با انجام این موارد تا حد بسیار خوبی می توان جلوی این آسیب پذیری را گرفت و امکان استفاده از آن را به حداقل ترین حالت ممکن رساند!
10- افشای اطلاعات حساس:
افشای اطلاعات حساس هم یکی دیگر از مشکلات امنیتی رایجی هست که توسعه دهندگان می توانند با آن رو به رو شوند!
این مشکل زمانی رخ می دهد که داده های محرمانه به صورت ناخواسته در اختیار کاربران و مهاجمان قرار می گیرد و زمینه سواستفاده را فراهم می کند!
در پروژه های نود جی اس این مشکل معمولا به دلیل مدیریت نادرست داده های حساس، پیکربندی اشتباه، لاگ برداری بیش از حد یا نمایش جزئیات فنی در پاسخ های API ایجاد می شود.
بسیاری از توسعه دهندگان در محیط های توسعه برای رفع خطا ها و دیباگ کردن اطلاعات زیادی را نمایش می دهند اما فراموش می کنند این تنظیمات را در محیط های پروداکشن غیرفعال کنند و همین موضوع اطلاعات حساسی را در اختیار مهاجمان قرار می دهد!
اطلاعات حساسی که نباید در معرض دید قرار بگیرند عبارتند از:
رمزهای عبور کاربران
توکن های احراز هویت
کلید های API
اطلاعات اتصال به پایگاه داده
کلید های رمزنگاری
اطلاعات شخصی کاربران
متغیر های محیطی
Stack Trace ها و جزئیات خطاهای داخلی
برای بررسی این که چرا این مشکل رخ می دهد باید دلایل زیر را بررسی کرد:
برخی API ها اطلاعاتی بیشتر از نیاز کاربر باز میگردانند و بخشی از داده های داخلی سیستم را افشا می کنند.
نمایش Stack Trace ها و پیام های خطای داخلی می تواند اطلاعات ارزشمندی درباره ساختار برنامه در اختیار مهاجمان قرار دهد.
ثبت رمز های عبور، توکن ها و داده های حساس در فایل های لاگ یکی از اشتباهات رایج است.
بسیاری از توسعه دهندگان به اشتباه کلیدهای API و اطلاعات محرمانه را مستقیما داخل کد یا مخازن Git ذخیره می کنند.
ارسال اطلاعات حساس از طریق ارتباطات ناامن نیز می تواند منجر به افشای اطلاعات شود.
افشای اطلاعات حساس می تواند مشکلات جدی ایجاد کند، از جمله:
گاهی اوقات مهاجمان برای نفوذ مستقیم تلاش نمی کنند، بلکه ابتدا اطلاعات لازم را جمع آوری می کنند.
حتی افشای یک کلید API، یک Stack Trace یا بخشی از اطلاعات پیکربندی می تواند به مهاجم کمک کند تا برای یک حمله بزرگ از آن استفاده کند!
راهکار های مقابله با افشای اطلاعات حساس:
برای کاهش ریسک این آسیب پذیری، رعایت موارد زیر ضروری است:
اطلاعات محرمانه را در Environment Variables نگهداری کنید.
از Secret Manager ها برای مدیریت اطلاعات حساس استفاده کنید.
جزئیات خطا ها را به کاربران نمایش ندهید.
داده های حساس را قبل از ذخیره سازی رمزنگاری کنید.
از پروتکل HTTPS برای تمام ارتباطات استفاده کنید.
از ذخیره رمزهای عبور به صورت متن ساده خودداری کنید.
اطلاعات حساس را از فایل های لاگ حذف کنید.
کلید های محرمانه را داخل مخزن کد قرار ندهید.
دسترسی به فایل های پیکربندی را محدود کنید.
به صورت دوره ای اطلاعات محرمانه موجود در پروژه را بازبینی کنید.
فراموش نکنید که هر اطلاعاتی که برای مهاجم مفید باشد یک داده حساس محسوب می شود و حتی اگر در نگاه اول محرمانه به نظر نرسد بعدا شاید از سمت یک مهاجم مورد استفاده قرار بگیرد! بنابراین توسعه دهنده همیشه باید فرض کند که تمام خروجی برنامه توسط افراد غیرمجاز ممکن است مشاهده شود!
نتیجه گیری:
همانطور که قبلا گفته شد امنیت در نود جی اس یک قابلیت جانبی نیست که بتوانید در مراحل پایانی آن را هندل کنید بلکه باید در ابتدای شروع کار با رعایت موارد و چارچوب های امنیتی کامل پروژه را به پیش ببرید!
هرچه برنامه بزرگتر باشد و کاربران بیشتری داشته باشد باعث می شود زیرساخت هم پیچیده تر شود و اهمیت به موارد امنیتی نیز دوچندان مهم می شود!
این نکته را فراموش نکنید که در بسیاری از حملات سایبری موفق لزوما تکنیک های پیچیده و پیشرفته استفاده نمی شود و بلکه در مهاجمان از اشتباهات کوچک و پیکربندی های نادرست و مواردی که مدت ها نادیده گرفته می شده برای نفوذ استفاده می کنند به همین دلیل دانش امنیتی پایه برای هر توسعه دهنده ای امروزه یک ضرورت مهم می باشد!
این مورد را هم به خاطر داشته باشید که امنیت به این شکل نیست که یکبار آن را پیاده سازی کنید و برای همین از آن استفاده کنید و انتظار داشته باشید چون یکبار به طور کامل سیستم را امن کردید هیچ وقت دچار مشکل نخواهید شد! فناوری ها به صورت مرتب تغییر می کنند و تکامل پیدا می کنند به همین دلیل امنیت باید به عنوان یک فرآیند مستمر و بخشی از فرهنگ توسعه نرم افزار در نظر گرفته شود!
در نهایت، ساخت یک نرم افزار امن تنها به ابزارها، فریم ورک ها یا کتابخانه ها وابسته نیست، بلکه تا حد زیادی به تصمیمات و رویکرد توسعه دهندگان بستگی دارد.
توسعه دهندگانی که از همان ابتدای پروژه، اصول امنیتی را در معماری و کدنویسی خود لحاظ می کنند، نه تنها ریسک های امنیتی را کاهش میدهند، بلکه نرم افزار هایی پایدارتر، قابل اعتماد تر و مقاوم تر در برابر تهدیدات آینده ایجاد خواهند کرد.











