راهنمای پیشگیری و رفع آسیب پذیری پایگاه داده

در این مقاله با دو مجموعه اقدامات امنیتی برای محافظت از بانک‌های اطلاعاتی آشنا می‌شویم. بخش اول به مجموعه اقداماتی اشاره دارد که باید توسط سرپرستان بانک‌های اطلاعاتی و کارشناسان امنیتی انجام شود. بخش دوم به مجموعه اقداماتی اشاره دارد که باید توسط توسعه‌دهندگان نرم‌افزارها و به ویژه‌ توسعه‌دهندگان وب مورد توجه قرار گیرد تا هکرها به سواستفاده از آسیب‌پذیری‌ها یا پیکربندی‌های اشتباه نپردازند. با فالنیک همراه باشید.

• لزوم توجه به امنیت پایگاه داده
• امنیت پایگاه داده چیست؟
• تهدید چیست؟
• کنترل‌های مبتنی بر سامانه‌های هوشمند
• کنترل دسترسی چیست؟
• پشتیبان‌گیری و بازیابی
• ده مورد از آسیب پذیری پایگاه داده چیست؟
• راهنمای شناسایی آسیب پذیری های رایج پایگاه داده و نحوه برطرف کردن آنها
• تزریق کد
• چگونه از حمله sql پیشگیری کنیم؟
• چگونه مانع پیاده‌سازی موفقیت‌آمیز حمله xss شویم؟
• اعتبارسنجی تمام داده‌ها
• آسیب پذیری‌های شخص ثالث
• پیشگیری از بروز حمله شخص ثالثی

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

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

لزوم توجه به امنیت پایگاه داده

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

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

پایگاه داده‌ای که گیت‌هاب با توسعه‌دهندگان به اشتراک قرار داده یک مخزن باز و عمومی است که متشکل از مجموعه‌ای از آسیب‌پذیری‌های مرتبط با فناوری‌های مختلف است که تحت مجوز Creative Commons در دسترس آحاد مردم قرار گرفته است.

این پایگاه داده بزرگ‌ترین مخزن آسیب‌پذیری‌های مرتبط با وابستگی‌های (Dependencies) نرم‌افزاری در جهان است که توسط یک تیم اختصاصی متشکل از توسعه‌دهندگان گیت‌هاب به شکل تمام وقت نگهداری می‌شود. این پایگاه داده به نشانی https://github.com/github/advisory-database در اختیار متخصصان قرار دارد. 

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

به گفته آلکس رستاکر مدیر تیم امنیتی AppSec’s Team SHATTER تمامی بانک‌های اطلاعاتی مورد استفاده در سازمان‌های بزرگ و کوچک با مجموعه نسبتا مشخصی از آسیب‌پذیری‌ها روبرو هستند. به‌طوری که اگر سرپرستان بانک‌های اطلاعاتی، توسعه‌دهندگان یا کارشناسان امنیتی به دقت به این آسیب‌پذیری‌ها رسیدگی کنند بخش عمده‌ای از حمله‌های سایبری ناکام باقی می‌مانند.

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

حدود نیمی از آسیب‌پذیری‌هایی که روتاکر و تیمش شناسایی کرده‌اند، به‌طور مستقیم یا غیرمستقیم به شیوه‌های مدیریت وصله‌های ضعیف در محیط پایگاه داده مربوط می‌شوند. آمارها نشان می‌دهند، متاسفانه تنها 38 درصد مدیران پایگاه داده در سه ماهه اول انتشار وصله‌های امنیتی آن‌ها را نصب می‌کنند و تقریباً یک سوم یک سال یا بیشتر طول می‌کشد تا وصله را روی سامانه‌ها نصب کنند.

امنیت پایگاه داده چیست؟

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

1. سرقت و کلاهبرداری (Theft and fraudulent)
2. از دست دادن محرمانگی (Loss of confidentiality or secrecy)
3. از دست رفتن حریم خصوصی داده‌ها (Loss of data privacy)
4. از دست رفتن دسترس‌پذیری داده‌ها (Loss of availability of data)
5. از دست دادن یکپارچگی داده‌ها (Loss of data integrity)

تمامی مشکلات امنیتی که بانک‌های اطلاعاتی با آن‌ها روبرو هستند پیرامون این مباحث قرار دارد. از این‌رو، سازمان‌ها باید برای به حداقل رساندن مخاطرات امنیتی یا آسیب‌هایی که ممکن است به داده‌های یک پایگاه داده وارد شود به این مباحث دقت نظر ویژه‌ای داشته باشند. در بیشتر موارد این چالش‌ها به‌طور مستقیم با هم مرتبط هستند، به‌طوری که حمله‌ای که باعث از دست رفتن یکپارچگی داده‌ها می‌شود، دسترس‌پذیری و محرمانگی آن‌ها را نیز تحت‌الشعاع خود قرار می‌دهد.

تهدید چیست؟

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

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

کنترل‌های مبتنی بر سامانه‌های هوشمند

روش‌های مختلف مقابله با تهدیدات در سیستم‌های رایانه‌ای از کنترل‌های فیزیکی تا رویه‌های مدیریتی را شامل می‌شود. علیرغم طیف وسیعی از کنترل‌های نظارتی که طراحی شده‌اند، شایان ذکر است که امنیت DBMS‌ها در وضعیت خوبی قرار دارد، البته به شرطی که به‌درستی پیکربندی شوند. امروزه بانک‌های اطلاعاتی بزرگ تجاری و منبع باز کنترل‌های امنیتی زیر را ارائه می‌کنند:

1. مجوز دسترسی (Access authorization)
2. کنترل‌های دسترسی (Access controls)
3. بازدیدها (Views)
4. پشتیبان‌گیری و بازیابی اطلاعات (Backup and recovery of data)
5. یکپارچگی داده (Data integrity)
6. رمزگذاری داده‌ها (Encryption of data)
7. پشتیبانی از فناوری رید (RAID technology)

کنترل دسترسی چیست؟

به مجموعه اصول و مکانیزم‌هایی اشاره دارد که مجموعه مجوزها و امتیازهایی را به کاربران ارائه می‌دهد تا به بانک‌های اطلاعاتی دسترسی داشته باشند. هر یک از بانک‌های اطلاعاتی به روشی مختلف این‌کار را انجام می‌دهند. یک امتیاز به کاربر اجازه می‌دهد تا به برخی از اشیا پایگاه داده دسترسی داشته یا آن‌ها را ایجاد کند یا برخی از ابزارهای DBMS را اجرا کند. این مجوزها به‌منظور انجام وظایف خاص شغلی به کارمندان یک سازمان اعطا می‌شود. پایگاه‌های داده انواع مختلفی از کنترل‌های دسترسی را ارائه می‌دهند که از مهم‌ترین آن‌ها به موارد زیر باید اشاره کرد:

1. کنترل دسترسی اختیاری (DAC)

2. کنترل دسترسی اجباری (MAC)

پشتیبان‌گیری و بازیابی

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

ده آسیب پذیری پایگاه داده چیست؟

ده  آسیب پذیری که سرپرستان بانک‌های اطلاعاتی و کارشناسان امنیتی (و توسعه‌دهندگان نرم‌افزار) باید به آن دقت کنند را در ادامه بررسی می‌کنیم.

1. نام کاربری/رمز عبور پیش‌فرض، خالی و ضعیف

ممکن است برای سازمانی که باید صدها یا حتی هزاران پایگاه داده را ردیابی کند، بررسی این موضوع کار دلهره‌آوری باشد، اما حذف اعتبارنامه‌های لاگین پیش‌فرض، خالی و ضعیف اولین گام مهم برای پر کردن شکاف‌ها در لایه‌های دفاعی پایگاه داده است. هکرها حساب‌های پیش‌فرض را ارزیابی می‌کنند و اگر آسیب‌پذیری در آن‌ها شناسایی کنند به سوء استفاده از آن‌ها می‌پردازند.

2. تزریق SQL

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

3. امتیازات و مجوزهای بیش از حد به کاربران و گروه‌ها

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

4. ویژگی‌های غیر ضروری فعال روی پایگاه داده

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

5. مدیریت پیکربندی نصفه‌نیمه

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

6. سرریز بافر

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

7. افزایش امتیاز

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

8. حمله انکار سرویس

SQL Slammer یک تصویر بسیار روشن از این موضوع است که چگونه مهاجمان می‌توانند از آسیب‌پذیری‌های DBMS برای از بین بردن سرورهای پایگاه داده از طریق یک ترافیک سیل‌آسا استفاده کنند. حمله انکار سرویس (DoS) با هدف عدم خدمت‌رسانی یک سامانه یا سرویس خاص انجام می‌شود. دقت کنید که حمله انکار سرویس (DoS) و انکار سرویس توزیع شده (DDoS) در عمل تفاوت‌هایی با هم دارند، هرچند هر دو تا حدود زیادی به روش یکسانی پیاده‌سازی می‌شوند.

9. پایگاه داده وصله نشده

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

10. داده‌های حساس رمزگذاری نشده در حال استفاده یا در وضعیت سکون

به این نکته مهم دقت کنید که اطلاعاتی که قرار است در جداول پایگاه داده ذخیره شوند نباید به شکل متن ساده قرار گیرند. بهتر است همه چیز به شکل رمزنگاری شده در بانک‌های اطلاعاتی ثبت شود و از پروتکل‌های ارتباطی ایمن برای برقراری ارتباط با بانک‌های اطلاعاتی استفاده شود.

راهنمای شناسایی آسیب پذیری های رایج پایگاه داده و نحوه برطرف کردن آنها

در این مقاله، برخی از رایج‌ترین آسیب‌پذیری‌هایی که مستقیماً بر کار توسعه‌دهندگان تأثیر می‌گذارند و این‌که چگونه می‌توانید برای جلوگیری از بروز آن‌ها تغییرات ساده‌ای اعمال کنید را بررسی می‌کنیم. بدیهی است، موارد دیگری نیز وجود دارند که شاید در این مقاله به آن‌ها پرداخته نشده است، اما این مقاله یک نقطه شروع خوب برای غلبه بر آسیب‌پذیری‌های رایج است.

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

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

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

خوشبختانه، راهکارهای پیشگیرانه ساده و نه چندان طولانی برای مقابله با حمله‌های سایبری در دسترس توسعه‌دهندگان قرار دارد.

تزریق کد

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

1. تزریق سمت سرور

برای این‌که ببینید چقدر آسان است که از یک برنامه آسیب‌‌پذیر با تزریق کد سمت سرور بهره‌برداری کنید، باید نگاهی به تابع eval() زبان برنامه‌نویسی پی‌اچ‌پی داشته باشیم.

تابع eval() یک رشته را به عنوان یک کد زبان برنامه‌نویسی پی‌اچ‌پی ارزیابی می‌کند.

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

$userExpression = ‘5+3’;

echo eval(‘return ‘ . $userExpression . ‘;’);

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

$userExpression = 'phpInfo();5+3';

echo eval('return ' . $userExpression . ';');

از آن‌جایی که هیچ مکانیزم اعتبار ورودی وجود ندارد، کاربر می‌تواند هر چیزی را که می‌خواهد تایپ کند و به عنوان کد PHP ارزیابی شده و اجرا شود. اگر مهاجم بتواند هر کدی که مایل است را اجرا کند، می‌تواند برنامه شما را خراب کند یا می‌تواند اقدام به واکشی اطلاعات مختلف از بانک‌های اطلاعاتی کرده یا دستورات مخرب را روی بانک‌های اطلاعاتی مورد استفاده برنامه اجرا کند.

2.      تزریق SQL injection

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

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

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

تصور کنید وب‌سایتی دارید که به کاربران امکان می‌دهد با وارد کردن شماره سفارش و آدرس ایمیل خود در یک فرم، اطلاعات سفارش خود را بررسی کنند.

پرس‌و‌جو برای دریافت اطلاعات سفارش بر اساس ورودی‌های فرم چیزی شبیه به حالت زیر است:

SELECT * FROM orders WHERE $email=$_POST['email'] AND $id=$_POST['order_number'];

کاربر شماره سفارش و ایمیل خود را وارد می‌کند و سپس پرس‌و‌جو با آن ورودی‌ها اجرا می‌شود تا داده‌ها را از پایگاه داده واکشی کند.

اکنون هکری این فرم را مشاهده می‌کند و تصمیم می‌گیرد دستوراتی را اجرا کند. در این حالت به جای این‌که ایمیل خود را تایپ کند، این مقادیر را به عنوان ورودی وارد می‌کند:

Email: test@example.com' OR 1 = 1 -- ']

Order Number: 1

اکنون برنامه شما آن ورودی را می‌گیرد و آن را مستقیماً در رشته SQL قرار می‌دهد. چیزی که اجرا می‌شود به دستور فوق تبدیل می‌شود:

SELECT * FROM orders WHERE email='test@example.com' OR 1 = 1 -- '] AND id=1;

و نتیجه؟ مهاجم اکنون اطلاعات سفارش همه را دارد که می‌تواند به معنای نام‌ها، ایمیل‌ها، آدرس‌ها و موارد دیگر باشد.

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

در سال 2018 میلادی شرکت لنوو مشابه چنین حمله‌ای را تجربه کرد که باعث بروز نقض داده‌ای شد که اطلاعات یک میلیون مشترک این شرکت را فاش کرد. به‌طوری که هکرها توانستند از طریق پیاده‌سازی حمله تزریق کد اس‌کیوال دسترسی کامل به وب‌سایت این شرکت به دست آورند.

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

تزریق SQL فقط به سرقت از پایگاه داده محدود نمی‌شود. نگرانی دیگری که وجود دارد یکپارچگی داده‌ها است. اگر یک مهاجم به پایگاه داده دسترسی داشته باشد، می‌تواند با تغییر داده‌های موجود در آن آسیب زیادی به اطلاعات وارد کند، پرسشی که مطرح است این است که یک مهاجم از تغییر داده‌ها چه چیزی به دست آورد؟ در این‌جا دو سناریو مفروض است:

1. یک مهاجم به پایگاه داده مراقبت‌های بهداشتی که حاوی اطلاعات حساس کاربران است دسترسی پیدا می‌کند. در این‌جا هکر می‌تواند اطلاعات روی پایگاه داده اصلی را تغییر دهد. در این‌جا سازمان مربوطه ممکن است تا مدت‌ها متوجه این تغییرات نشود و زمانی که نشانه‌های آشکاری را مشاهده کرد تازه متوجه شوند که چه اتفاقاتی افتاده که دیگر خیلی دیر است. در این مدت مهاجم ممکن است از شرکت برای بازگرداندن تغییرات به حالت اصلی باج‌خواهی کند یا اسناد را به‌گونه‌ای تغییر دهد تا از شرکت‌های بیمه پول دریافت کند.

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

همان‌گونه که مشاهده می‌کنید، حفره‌ها در برنامه‌های کاربردی و پایگاه‌های داده‌ای می‌توانند باعث بروز مشکل نقض‌های داده‌ای به روش‌های مختلف شوند.

چگونه از حمله sql پیشگیری کنیم؟

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

1. همیشه ورودی کاربر را تأیید و ارزیابی کنید.

2. ورودی کاربر را مستقیماً اجرا نکنید.

به بیان ساده دقت کنید هنگام ساخت یک برنامه، هرگز نباید به ورودی که کاربر وارد می‌کند اعتماد کنید. در مطلب sql injection  چیست؟ درباره این حمله، مفصل‌تر بخوانید.

3.       اسکریپت بین‌سایتی یا xss

اسکریپت بین‌سایتی یا Cross Site Scripting آسیب‌پذیری است که به مهاجمان اجازه می‌دهد کدهای مخرب را معمولاً از طریق یک فرم یا آدرس اینترنتی که در مرورگر کاربر اجرا می‌شود، ارسال کنند. این حمله از نظر فنی یک نوع تزریق است، اما مخاطرات مستقیم کمتری برای شرکت‌ها دارد، زیرا یک حمله سمت کلاینت است.

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

فرض کنید در حال جست‌وجوی بهترین بانک برای دریافت کارت اعتباری هستید. در فرم یا انجمن اینترنتی شخصی یک بانک معروف را با لینکی به وب‌سایت بانک پیشنهاد می‌کند که در ظاهر معتبر است. به‌طور مثال، آدرسی که دریافت می‌کنید در قالب یک ابرمتن (متنی که آدرس اینترنتی دارد) چیزی شبیه به https://legit-bank.com است. شما بدون تحقیق بیشتر روی آن کلیک کنید.

اما در واقع آدرس اینترنتی واقعی شبیه به ترکیب زیر است:

https ://legit-bank.com/search?query=<script>هشدار(‘BOOM!’)</script>

وارد صفحه می‌شوید و یک پنجره هشدار با پیام “BOOM!” دریافت می‌کنید. چه اتفاقی افتاد؟ در این سناریوی فرضی، مهاجم یک صفحه آسیب‌پذیر را در وب‌سایت بانک پیدا کرده که صفحه جستجو است. در ادامه <script>alert(‘BOOM!’)</script> را در کادر جستجو تایپ کرده، برنامه درخواست را با استفاده از ورودی به عنوان رشته آماده کرده، محاوره را اجرا کرده و سپس پیامی مبنی بر اینکه هیچ نتیجه‌ای یافت نشد را ارسال می‌کند. در این سناریو توسعه‌دهندگان باید می‌دانستند که قبل از اجرای پرس‌وجو، ورودی‌های پشتیبان را باید پاکسازی کنند، چه مشکلی پیش آمد؟

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

حالا هر فردی روی این لینک کلیک کند تحت تأثیر این اسکریپت مخرب قرار می گیرد. البته، یک پنجره هشدار بیشتر فقط مزاحم است، اما حملات XSS می‌توانند بسیار خطرناک‌تر باشند و مستقیما کدی را درون مرورگر کاربر اجرا کنند.

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

در برخی برنامه‌ها، مهاجم می‌تواند از کوکی نشستی که سرقت کرده برای جعل هویت کاربر در وب‌سایت بانک استفاده کند. در این حالت نیازی به نام کاربری و رمز عبور ندارند، زیرا وجود کوکی از دیدگاه برنامه به این معنی است که کاربر قبلاً وارد سیستم شده است! این موضوع به نام روبایش نشست (Session) نیز شناخته می‌شود. این بردار حمله به شرح زیر است:

کاربر به بانک خود وارد می‌شود و یک کوکی جلسه دریافت می‌کند که در ادامه به برنامه می‌گوید چه کسی است.

در ادامه کاربر روی لینکی که آلوده است کلیک می‌کند (لینکی که هکر قبلا آلوده کرده و در سایت قرار دارده است).

جاوا‌اسکریپت از روی لینک اجرا می‌شود و محتوای document.cookie را دریافت می‌کند.

آن کوکی از طریق جاوا اسکریپت در آدرس اینترنتی به سرور مهاجم ارسال می‌شود.

مهاجم کوکی جلسه را سرقت می‌کند و شروع به ارسال درخواست برای بانک می‌کند و آن کوکی را همراه با درخواست ارسال می‌کند.

مهاجم اکنون به حساب بانکی آن کاربر دسترسی دارد.

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

چگونه مانع پیاده‌سازی موفقیت‌آمیز حمله xss شویم؟

همان‌گونه که در مورد حملات تزریق مشاهده کردیم، بهترین راه برای جلوگیری از بروز حملات XSS این است که تمام ورودی‌های غیرقابل اعتماد کاربر را بررسی کنید. نحوه انجام این‌کار به شرح زیر است:

اعتبارسنجی تمام داده‌ها

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

در این‌جا ارزیابی کاراکترهای Escaping نیز اهمیت زیادی دارد، به‌ویژه اگر می‌خواهید اجازه دهید ورودی ارسال شده توسط کاربر در صفحه‌ای نشان داده شده یا در پایگاه داده‌ای ثبت شود. این حرف به این معنا است که کاراکترهای خاص مانند < را به کد هگزا آن‌ها تغییر دهید، به طوری که قابلیت اجرایی نداشته باشند. به‌طور مثال، تبدیل کاراکترهای خاص به معادل هگزا شبیه به حالت زیر است:

&lt;script&gt;alert(‘BOOM!’)&lt;/script&gt;

اکثر چارچوب‌های فرانت‌اند مدرن قبل از رندر کردن به‌طور پیش‌فرض وضعیت داده‌های Escape را ارزیابی می‌کنند. فقط مطمئن شوید که از این تکنیک آگاه هستید تا هر زمان که از یک فریمورک استفاده کردید که این‌کار را انجام نمی‌دهد، خودتان قادر به انجام این‌کار هستید.

آسیب پذیری‌های شخص ثالث

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

به آخرین پروژه‌ای که روی آن کار کرده‌اید فکر کنید. آیا از بسته‌ها یا ماژول‌های خارجی استفاده کردید؟ به احتمال زیاد این‌کار را انجام داده‌اید. اگر مطمئن نیستید، نگاهی به پوشه node_modules خود بیندازید. شما احتمالاً فقط چند بسته را به تنهایی نصب کرده‌اید، اما همه بسته‌ها وابستگی‌ها مرتبط روی سیستم شما نصب شده‌اند. این وابستگی‌ها مربوطه به کدهای اجرایی هستند. بنابراین چگونه می‌توانید مطمئن باشید که صدها بسته نصب شده بدون آسیب‌پذیری هستند؟

پیشگیری از بروز حمله شخص ثالثی

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

اولین قدم این است که قبل از نصب بسته مطمئن شوید که به آن اعتماد دارید. هنگام استفاده از بسته‌ای که حاوی کد نوشته شده توسط شخص دیگری است، همیشه میزان قابل توجهی ریسک وجود دارد که باید آن‌را قبول کنید. در حالت ایده‌آل، باید هر فایلی که در هر بسته‌ای که قرار است نصب شود را به صورت دستی بررسی کنید. بسیاری از شرکت‌ها، تیم‌های امنیتی برای انجام این‌کار دارند، البته، این وظیفه توسعه‌دهنده یا تیم نرم‌افزاری است که این موضوع را بررسی کنید. در اینجا مواردی وجود دارد که باید هنگام ارزیابی ریسک یک بسته در نظر بگیرید. آیا منبع باز است؟ اگر نه از شرکت معتبری هست؟ آیا محبوب است و به‌طور فعال توسط جامعه توسعه‌دهندگان بررسی می‌شود؟ آیا مشکلی در گیت‌هاب در ارتباط با آن گزارش شده که بیان‌گر مخرب بودن آن باشد.

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

هنگامی که تصمیم گرفتید از بسته ثالثی استفاده کنید، هنوز چند کار دیگر وجود دارد که باید انجام دهید تا مطمئن شوید بسته مشکل امنیتی خاصی ندارد.

1. هنگامی که نام بسته را تایپ می‌کنید، به دقت بررسی کنید که املای آن درست باشد. در دنیای برنامه‌نویسی مشکلی وجود دارد که typosquatting نام دارد. بر مبنای این مشکل مهاجمان یک بسته مخرب ایجاد می‌کنند و سپس نامی شبیه به یک بسته قانونی و محبوب به آن تخصیص می‌دهند. در چند سال گذشته بسته‌های پایتون، PyPI، حاوی چند بسته مخرب تایپی بوده‌اند.

به‌طور مثال، ممکن است به شکل تصادفی pip install djago را به جای pip install django تایپ کنید، اما هیچ خطایی را مشاهده نکنید، زیرا چند بسته مخرب در مخزن بارگذاری شده باشد. Npm نیز مشابه چنین مشکلاتی را دارد.

بنابراین، اولین کاری که باید انجام دهید، ارزیابی است و مطمئن شوید که املای بسته‌ها را به درستی تایپ کرده‌اید.

2. در مرحله بعد باید اطمینان حاصل کنید که بسته با وصله‌های امنیتی به‌روز باشد! Npm این‌کار را نسبتاً ساده کرده است. هر بار که npm install را اجرا می‌کنید، یک ممیزی اجرا می‌شود که آسیب‌پذیری‌های امنیتی را در تمام ماژول‌های Node پروژه شما بررسی می‌کند. در یک پایگاه کد موجود، می‌توانید در هر زمان ممیزی npm را برای اجرای این موضوع بررسی کنید.

اگر در ترمینال خود پیامی دریافت کردید مبنی بر اینکه برخی از بسته‌های شما دارای آسیب‌پذیری هستند، کمی وقت بگذارید تا آن‌ها را بررسی کرده و در صورت نیاز به‌روز‌رسانی لازم را اعمال کنید. حتی می‌توانید npm audit fix را برای نصب خودکار به‌روزرسانی‌های لازم اجرا کنید. اگر این مسیر را می‌روید، مطمئن شوید که از تغییرات مهمی که همراه با به‌روزرسانی بسته ایجاد می‌شود، آگاه هستید. Npm به شما در این مورد هشدار میردهد.

به‌طور خلاصه، موارد احتیاطی که باید هنگام استفاده از بسته‌های شخص ثالث رعایت کنید به شرح زیر است:

1. بسته‌های خود را به‌روز نگه دارید.
2. اطمینان حاصل کنید که به بسته، صاحبان بسته و نگهداری از بسته اعتماد دارید.
3. هنگام نصب بسته، مطمئن شوید که اشتباهات تایپی ندارید.
4. ممیزی npm را روی پروژه‌های موجود اجرا کنید.

در صورت امکان، از کارشناسان امنیتی آشنا به مباحث امنیتی درخواست کمک کنید تا بسته‌های منبع باز و وابستگی‌ها را برای شما بررسی کنند.