في هذه الأيام ، تتعرض خدمات الويب باستمرار لمجموعة متنوعة من الهجمات. لذلك ، الأمان هو شيء يجب تذكره في جميع مراحل دورة حياة المشروع. يحتفظ مؤلفو المادة ، التي ننشر ترجمتها اليوم ، بمخزن على GitHub ، والذي يحتوي على حوالي 80 توصية لتأمين التطبيقات التي تعمل على منصة Node.js. تحتوي هذه المادة ، استنادًا إلى العديد من المنشورات الأمنية ، على أكثر من عشرين توصية بشأن Node.js وبعض النصائح العامة. علاوة على ذلك ، تغطي هذه المادة أهم 10 نقاط ضعف من قائمة مشروع OWASP.
1. استخدام قواعد اللتر ، تهدف إلى التحقق من أمن التعليمات البرمجية
التوصيات
أثناء التطوير ، استخدم
مكونًا إضافيًا موجهًا للأمان للليتر ، مثل
eslint-plugin-security . يتيح لك هذا تحديد الثغرات الأمنية ومشكلات الأمان في وقت مبكر جدًا - وقت كتابة الرمز المناسب. يساعد هذا الأسلوب على إيجاد نقاط ضعف في أمان البرنامج. من بينها استخدام الأمر
eval ، واستدعاء العمليات الفرعية ، واستيراد الوحدات مع النقل إلى الأمر المقابل لشيء مختلف عن سلسلة حرفية (على سبيل المثال ، سلسلة معينة تشكلت على أساس البيانات المرسلة إلى الخادم من قبل المستخدم).
→
إليك بعض المواد المفيدة حول قواعد اللنتر
يقول
آدم بالدوين ما يلي حول الفحص: "لا ينبغي أن تكون Linter مجرد أداة تتبع بدقة القواعد المتعلقة بعدد المسافات المستخدمة ، والفواصل المنقوطة ، واستخدام الأمر Eval. يوفر ESLint للمطور نظامًا أساسيًا قويًا يمكنه اكتشاف وإزالة مجموعة واسعة من الأنماط التي يحتمل أن تكون خطرة في التعليمات البرمجية. نحن نتحدث ، على سبيل المثال ، عن التعبيرات العادية ، وعن التحقق من إدخال المستخدم ، وما إلى ذلك. أعتقد أن اللنتر يمنح المطورين المهتمين بقضايا الأمن أداة جديدة قوية تستحق الانتباه إليها ".
المشاكل المحتملة
ما يبدو وكأنه عيب أمني بسيط أثناء التطوير هو أن يصبح نقطة ضعف خطيرة في الإنتاج. بالإضافة إلى ذلك ، إذا لم يتبع جميع مطوري المشاريع قواعد أمان موحدة عند العمل مع التعليمات البرمجية ، فقد يؤدي ذلك إلى نقاط ضعف فيها ، أو ، على سبيل المثال ، إلى اختراق البيانات السرية في المستودعات العامة.
2. تحديد عدد طلبات الخادم المتزامنة
التوصيات
تحظى هجمات DoS بشعبية كبيرة بين المجرمين الإلكترونيين ، ويسهل تنفيذها نسبيًا. يمكنك تنفيذ نظام للحد من عدد الطلبات لتطبيق ما باستخدام خدمة خارجية ، مثل موازن التحميل السحابي ، أو جدار الحماية السحابي ، أو خادم nginx ، أو بالنسبة للتطبيقات الصغيرة غير الحرجة ، باستخدام البرامج الوسيطة للحد من عدد الطلبات مثل
المعدل السريع -حد .
→
إليك المادة الخاصة بتنفيذ النظام للحد من تكرار الطلبات على الخادم
المشاكل المحتملة
يمكن مهاجمة تطبيق لا يوفر نظامًا للحد من عدد الطلبات المتزامنة ، مما سيؤدي إلى فشله. يتم التعبير عن هذا في حقيقة أن مستخدمي مثل هذا التطبيق إما سيجدون صعوبة في العمل معه أو لن يكونوا قادرين على التفاعل معه على الإطلاق.
3. إزالة المعلومات السرية من ملفات التكوين أو تشفيرها
التوصيات
لا تقم أبدًا بتخزين البيانات الحساسة في نص عادي في ملفات التكوين أو في التعليمات البرمجية. بدلاً من ذلك ، استخدم أنظمة إدارة البيانات الحساسة مثل منتجات Vault أو أنظمة Kubernetes / Docker Secrets ، أو استخدم متغيرات البيئة لتخزين هذه البيانات. يجب تشفير البيانات السرية المخزنة في نظام التحكم في الإصدار ، ويجب اتخاذ تدابير لتخزينها واستخدامها بشكل آمن. من بين هذه التدابير استخدام المفاتيح الديناميكية ، واستخدام تواريخ انتهاء صلاحية كلمة المرور ، وعمليات تدقيق الأمان ، وما إلى ذلك. استخدم الأنظمة للتحقق من الشفرة قبل الالتزام بها أو قبل إرسالها إلى المستودع لمنع الإرسال غير المقصود للبيانات الحساسة إلى المستودع العام.
→
إليك مادة حول إدارة البيانات الحساسة
المشاكل المحتملة
حتى إذا تم تخزين الرمز في مستودع مغلق ، فقد يصبح متاحًا للجمهور يومًا ما عن طريق الخطأ. عند هذه النقطة ، ستصبح جميع البيانات السرية المخزنة فيها ملكًا عامًا. ونتيجة لذلك ، سيؤدي وصول طرف ثالث إلى المستودع الذي يحمل الرمز إلى وصولهم عن غير قصد إلى الأنظمة المرتبطة به (قواعد البيانات وواجهات برمجة التطبيقات والخدمات وما إلى ذلك).
4. منع ثغرات إدخال الشفرة
التوصيات
من أجل منع عمليات حقن SQL / NoSQL والهجمات المشابهة الأخرى ، استخدم دائمًا مكتبات ORM / ODM أو آليات DBMS التي تهدف إلى تنظيف البيانات ، أو دعم الاستعلامات المعنونة أو المفهرسة ، والتحقق مما يأتي من المستخدم. لا تستخدم أبدًا ، لتضمين قيم معينة في نصوص الاستعلام ، فقط قوالب سلاسل جافا سكريبت ، أو سلسلة متسلسلة ، حيث يفتح هذا النهج تطبيقك على مجموعة واسعة من الثغرات الأمنية. تحتوي جميع المكتبات المحترمة لـ Node.js المستخدمة للعمل مع البيانات (على سبيل المثال ،
Sequelize ،
Knex ،
mongoose ) على حماية مدمجة ضد الهجمات عن
طريق حقن الشفرة.
→
إليك المواد الخاصة بمنع الحقن باستخدام مكتبات ORM / ODM
المشاكل المحتملة
يمكن أن يؤدي استخدام البيانات غير المؤكدة وغير النظيفة المستلمة من المستخدم في الاستعلامات إلى هجوم من خلال تقديم عامل عند العمل مع قاعدة بيانات NoSQL مثل MongoDB. إذا كنت لا تستخدم نظام تنظيف البيانات أو مكتبة ORM عند العمل مع قاعدة بيانات SQL ، فسيؤدي ذلك إلى احتمال حدوث هجوم عن طريق حقن SQL ، مما يخلق فجوة أمان ضخمة في التطبيق.
5. تجنب هجمات DoS من خلال تحديد شروط الإنهاء غير الطبيعي للعملية بشكل صريح
التوصيات
تعطل عملية العقدة عند حدوث خطأ غير معالج. ولكن في العديد من التوصيات التي تعكس أفضل الممارسات للعقدة ، يوصى بإنهاء العمليات حتى عندما يتم اعتراض خطأ ومعالجته. Express ، على سبيل المثال ، سوف يتعطل عند حدوث أي خطأ غير متزامن - ما لم يتم التفاف المسارات في تعبيرات
catch . تقدم هذه الحقيقة للمهاجمين فرصة جذابة للغاية. لقد اكتشفوا أنه عند وصول طلب معين ، تتعطل العملية ، ويبدأون في إرسال مثل هذه الطلبات فقط. لا توجد توصية من شأنها حل هذه المشكلة في ضربة واحدة ، ومع ذلك ، يمكن لبعض الحيل تخفيفها. لذلك ، في نهاية العملية بسبب خطأ غير معالَج ، تحتاج إلى إبلاغ المسؤول ، مع إعطاء هذا الإشعار أولوية قصوى. من الضروري التحقق مما يأتي للعملية في الطلبات وتجنب حالات الإنهاء غير الطبيعي للعملية بسبب الطلبات التي تم تشكيلها بشكل غير مقصود أو عن طريق الخطأ. يجب أن تكون جميع المسارات ملفوفة في تعبيرات
catch ويجب تكوين النظام بحيث ، إذا كان الطلب هو سبب الخطأ ، فإن العملية لن تتعطل (على عكس ما يحدث على مستوى التطبيق العالمي).
المشاكل المحتملة
دعونا نحلل الموقف التالي. هناك العديد من تطبيقات Node.js. ماذا يحدث إذا بدأنا في إرسال طلبات POST مع JSON فارغة كهيئة الطلب؟ سيؤدي ذلك إلى تعطل العديد من هذه التطبيقات.
الآن ، إذا أردنا لعب دور المجرمين الإلكترونيين ، حتى نتمكن من منع التطبيقات من التعطل ، فسيكون كافياً لمواصلة إرسال طلبات مماثلة إليهم.
6. تكوين رؤوس استجابة HTTP لزيادة أمن المشروع
التوصيات
يجب أن يستخدم التطبيق رؤوس HTTP موجهة نحو الأمان لمنع المهاجمين من اللجوء إلى تقنيات الهجوم الشائعة مثل البرمجة النصية عبر المواقع (XSS) ، والنقر فوق النقر ، وغيرها. من السهل تخصيص الرؤوس باستخدام وحدات خاصة مثل
الخوذة .
→
إليك المواد المتعلقة باستخدام الرؤوس الآمنة
المشاكل المحتملة
إذا لم يتم استخدام رؤوس HTTP الآمنة ، فسيكون المهاجمون قادرين على تنفيذ هجمات على مستخدمي تطبيقاتك ، مما يؤدي إلى نقاط ضعف كبيرة.
7. باستمرار ، تلقائيًا ، تحقق من مشروعاتك بحثًا عن استخدام التبعيات الضعيفة فيها
التوصيات
في النظام البيئي للآلية الوقائية الوطنية ، تعتبر المشاريع ذات التبعيات العديدة شائعة جدًا. يجب دائمًا التحكم في التبعيات ، نظرًا لاكتشاف نقاط ضعف جديدة. استخدم أدوات مثل
npm Audit أو
nsp أو
snyk لاكتشاف التبعيات المعرضة للمخاطر ومراقبتها وإصلاحها. قم بتضمين هذه الأدوات في نظام التكامل المستمر. سيسمح لك هذا باكتشاف التبعيات الضعيفة قبل دخولها في الإنتاج.
→
هنا مواد عن أمن تبعية المشروع
المشاكل المحتملة
يمكن للمهاجم تحديد إطار الويب المستخدم في المشروع وتنفيذ الهجمات على جميع الثغرات المعروفة.
8. حاول عدم استخدام وحدة التشفير القياسية Node.js لمعالجة كلمة المرور ، استخدم Bcrypt بدلاً من ذلك
التوصيات
يجب تخزين كلمات المرور أو البيانات الحساسة الأخرى (مفاتيح واجهة برمجة التطبيقات ، على سبيل المثال) عن طريق معالجتها بوظائف التشفير باستخدام "الملح" ، مثل Bcrypt. يجدر استخدام شيء مشابه تمامًا ، وليس وحدة
crypto القياسية Node.js لأسباب تتعلق بالأمان والأداء.
→
هنا هي المواد حول Bcrypt
المشاكل المحتملة
كلمات المرور أو بعض البيانات السرية التي يتم تخزينها دون تطبيق التدابير المناسبة لحمايتها تكون عرضة لهجمات القوة الغاشمة وهجمات القاموس ، مما يؤدي ، نتيجة لذلك ، إلى الكشف عن هذه البيانات.
9. استخدام أنظمة الهروب من الأحرف في بيانات HTML و JS و CSS المرسلة إلى المستخدم
التوصيات
إذا تم إرسال بعض البيانات إلى متصفح المستخدم من مصدر غير موثوق به ، فعندئذ حتى إذا كان يجب عرضها ببساطة ، يمكن أن تكون هذه البيانات رمزًا يمكن تنفيذه. يُشار إلى هذا عادةً باسم البرمجة النصية عبر المواقع (XSS). يمكنك تقليل مخاطر حدوث مثل هذه الهجمات باستخدام مكتبات خاصة تعالج البيانات بحيث لا يمكن تنفيذها. وهذا ما يسمى ببيانات الترميز أو الحماية.
→
إليك مادة حول حماية الإخراج
المشاكل المحتملة
إذا كنت لا تهتم بحماية البيانات ، يمكن للمهاجم ، على سبيل المثال ، حفظ كود جافا سكريبت الضار في قاعدة البيانات الخاصة بك ، والتي يمكن نقلها إلى العملاء دون تغيير وإطلاقها.
10. تحقق من بيانات JSON الواردة إلى الخادم
التوصيات
تحكم في محتويات نصوص الطلبات الواردة ، وتحقق مما إذا كانت تتوافق مع ما تتوقع رؤيته في مثل هذه الطلبات. إذا لم يكن الطلب كما هو متوقع ، فتوقف عن معالجته بسرعة. لتجنب العملية التي تستغرق وقتًا طويلاً في كتابة رمز التحقق من طلب كل مسار ، يمكنك استخدام أدوات JSON خفيفة الوزن للتحقق من صحة البيانات ، مثل
jsonschema أو
joi .
→
إليك المادة الخاصة بفحص بيانات JSON الواردة
المشاكل المحتملة
إذا كان الخادم يقبل أي طلبات بشكل ودي بدون فحصها بدقة ، فهذا يزيد بشكل كبير من سطح الهجوم في التطبيق ويلهم المهاجمين لمحاولة العثور على العديد منها مما يؤدي إلى "تعطل" النظام.
11. الحفاظ على الرموز المميزة لـ JWT المدرجة في القائمة السوداء
التوصيات
عند استخدام رموز JWT (على سبيل المثال ، إذا كنت تعمل مع
Passport.js ) ، بشكل افتراضي ، لا توجد آلية قياسية لإبطال امتيازات الوصول إلى النظام للرموز التي تم إصدارها بالفعل. حتى إذا وجدت أن مستخدمًا معينًا يفعل شيئًا غير طبيعي بشكل واضح ، فلا توجد طريقة ، من خلال آلية الرمز المميز ، لحظر وصوله إلى النظام ، طالما أن لديه رمز صالح. يمكن تخفيف هذه المشكلة من خلال تنفيذ قائمة سوداء بالرموز المميزة غير الموثوق بها ، ويتم التحقق من صحتها عند كل طلب.
←
إليك المواد المتعلقة برموز JWT المدرجة في القائمة السوداء
المشاكل المحتملة
يمكن للمهاجم استخدام الرموز التي تقع في الأيدي الخطأ. سيكون قادرًا على الوصول إلى التطبيق وانتحال شخصية مستخدم عادي - مالك الرمز المميز.
12. تحديد عدد محاولات تسجيل الدخول
التوصيات
في التطبيقات القائمة على التعبير السريع ، للحماية من هجمات القوة الغاشمة وهجمات القاموس ، يجدر استخدام البرامج الوسيطة المناسبة ، مثل
Express-brute . وبالمثل ، تحتاج إلى حماية المسارات المهمة مثل
/admin أو
/login . يجب أن تستند الحماية إلى تحليل خصائص الاستعلام ، مثل اسم المستخدم المستخدم في الاستعلام أو المعرفات الأخرى ، مثل معلمات نص الاستعلام.
→
إليك المادة الخاصة بتحديد عدد محاولات تسجيل الدخول
المشاكل المحتملة
إذا لم يحد التطبيق من عدد محاولات تسجيل الدخول ، يمكن للمهاجم إرسال عدد غير محدود من طلبات تسجيل الدخول إلى نظامك تلقائيًا ، على سبيل المثال ، محاولة الوصول إلى حساب مميز.
13. قم بتشغيل Node.js كمستخدم غير جذري
التوصيات
سيناريو شائع للغاية عندما يتم تشغيل Node.js كمستخدم جذري بامتيازات غير محدودة. على سبيل المثال ، هذه هي الطريقة التي يتم بها تكوين كل شيء بشكل افتراضي في حاويات Docker. من المستحسن إنشاء مستخدم ليس لديه امتيازات الجذر ، وإما تضمينه في صورة Docker ، أو بدء العملية نيابة عن هذا المستخدم عن طريق استدعاء الحاوية بعلامة
-u username .
→
إليك المادة الخاصة بتشغيل Node.js كمستخدم غير جذري
المشاكل المحتملة
إذا تم تشغيل Node.js تحت حساب مستخدم الجذر ، فإن المهاجم الذي كان قادرًا على تشغيل برنامج نصي على الخادم يحصل على إمكانيات غير محدودة على الجهاز المحلي. لنفترض أنه يمكنه تغيير إعدادات
iptable وإعادة توجيه حركة المرور إلى جهاز الكمبيوتر الخاص به.
14. الحد من كمية البيانات المرسلة في الطلبات باستخدام خادم وكيل عكسي أو وسيط
التوصيات
كلما كبرت كمية البيانات في نص الطلب ، زادت صعوبة معالجة خادم مترابط واحد لمثل هذا الطلب. يمنح استخدام الطلبات الكبيرة للمهاجم الفرصة لإغراق الخادم بالعمل غير الضروري دون إرسال عدد كبير من الطلبات إليه (أي بدون تنفيذ هجوم DoS / DDoS). يمكنك تقليل مخاطر مثل هذه الهجمات عن طريق الحد من حجم أجسام الطلبات الواردة على نظام حد معين (على جدار ناري أو على موازن تحميل) ، أو عن طريق تعيين
المحلل اللغوي السريع لاستقبال الحزم التي تحتوي على كمية صغيرة من البيانات فقط.
→
إليك مادة حول تحديد كمية البيانات المرسلة في الطلبات
المشاكل المحتملة
إذا لم تحدد كمية البيانات المرسلة في الطلبات ، فيمكن للمهاجم تحميل التطبيق عن طريق معالجة الطلبات الكبيرة. في هذا الوقت ، لن تتمكن من حل المهام التي صممت من أجلها. هذا يؤدي إلى ضعف الأداء ويجعل التطبيق عرضة لهجمات DoS.
15. تجنب استخدام الدالة Eval في JavaScript
التوصيات
وظيفة
eval شريرة لأنها تتيح لك تنفيذ كود JS التعسفي الذي تم تمريره إليها أثناء تنفيذ البرنامج. علاوة على ذلك ، ليس هذا إلا أن هذا الرمز يمكن أن يبطئ التطبيق. تشكل هذه الوظيفة خطرًا أمنيًا خطيرًا ، حيث قد يدخل كود JS الخبيث الذي يرسله المهاجم إلى الخادم.
بالإضافة إلى ذلك ، يجب عليك تجنب مُنشئ
new Function . لا تحتاج
setInterval setTimeout و
setInterval مطلقًا إلى تمرير رمز JS الذي تم إنشاؤه ديناميكيًا.
→
إليك الأشياء المتعلقة بالتقييم
المشاكل المحتملة
إذا وجد شخص ما طريقة لنقل كود JS الخبيث ، في شكل نص ، أو وظيفة
eval ، أو محرك JS مشابه آخر ، فسيكون له حق الوصول الكامل إلى الصفحة ، إلى كل ما يمكن القيام به باستخدام JavaScript. غالبًا ما ترتبط مشكلة عدم الحصانة هذه بهجمات XSS.
16. لا تفرط في تحميل تطبيقات Node.js أحادية الخيوط بتعبيرات عادية ضارة
التوصيات
تشكل التعبيرات العادية ، على الرغم من ملاءمتها ، تهديدًا لتطبيقات JavaScript بشكل عام ، وخاصة لمنصة Node.js. المعالجة بالتعبير المنتظم ما يأتي من المستخدم يمكن أن يخلق حمولة هائلة على المعالج. على سبيل المثال ، يمكن أن تكون معالجة التعبيرات العادية غير فعالة إلى حد أن التحقق من عشر كلمات يمكن أن يمنع دورة الأحداث لعدة ثوان ويحمل المعالج زيادة في طاقته. لذلك ، من الأفضل استخدام حزم الجهات الخارجية للتحقق من بيانات السلسلة ، مثل
validator.js ، بدلاً من كتابة التعبيرات العادية الخاصة بك. يمكنك استخدام حزمة
reg-regex لاكتشاف أنماط
regex الضعيفة.
→
إليك مواد التعبير العادي الخاصة بمكافحة البرامج الضارة
المشاكل المحتملة
يمكن أن تخضع التعبيرات العادية المكتوبة بشكل سيئ لنوع خاص من هجمات DoS ، حيث يتم حظر حلقة الحدث تمامًا. على سبيل المثال ، في نوفمبر 2017 ، تم اكتشاف أن حزمة
moment الشعبية كانت عرضة لمثل هذه الهجمات.
17. تجنب تحميل الوحدات باستخدام المتغيرات
التوصيات
تجنب استيراد الملفات التي تم تحديد مسارها كمعلمة ، بناءً على الاعتبارات التي يمكن من خلالها تعيين هذه المعلمة بناءً على البيانات من المستخدم. يمكن توسيع هذه القاعدة لتشمل هنا ، وبشكل عام ، الوصول إلى الملفات (باستخدام
fs.readFile() ) ، والوصول إلى أي موارد مهمة أخرى باستخدام المعلمات المتلقاة من المستخدم. إن استخدام
eslint-plugin-security يجعل من الممكن اكتشاف مثل هذه الأنماط غير الآمنة في وقت مبكر جدًا.
→
هنا مواد عن تحميل الوحدة الآمنة
المشاكل المحتملة
قد تكون البيانات التي يرسلها المهاجم إلى الخادم في الإعدادات المسؤولة عن استيراد ملفات معينة ، من بينها قد يكون ملفًا ضارًا تم تحميله مسبقًا إلى الخادم. يمكن أيضًا استخدام هذه البيانات للوصول إلى ملفات النظام الموجودة بالفعل على جهاز الكمبيوتر.
18. شغّل رمزًا غير آمن في وضع الحماية
التوصيات
إذا كنت بحاجة إلى تنفيذ التعليمات البرمجية الخارجية التي تدخل إلى التطبيق أثناء تشغيله (على سبيل المثال ، مكون إضافي معين) ، فاستخدم وضع الحماية الذي يعزل الرمز الرئيسي ويحميه من رمز المكون الإضافي. يمكن إنشاء بيئة مماثلة باستخدام عملية مخصصة ( cluster.fork()) ، أو بيئة بدون خادم ، أو حزمة npm مخصصة تعمل بمثابة وضع حماية.→ إليك مادة حول تشغيل رمز غير آمن في وضع الحمايةالمشاكل المحتملة
يمكن أن يهاجم الرمز الضار الموجود في المكون الإضافي التطبيق بعدة طرق متنوعة. من بينها دورات لا حصر لها ، زيادة في الذاكرة ، الوصول إلى متغيرات البيئة ، يجب الحفاظ على محتوياتها سرية.19.
, , . , , , .
child_process.execFile , , , , , .
→
,
, , , , .
20.
express, , . , , ,
Error ( ). , , , - , .
→
, , , , , , .
21. npm Yarn
, -, (MFA, multi-factor authentication). npm Yarn , . , , , . , . , , npm, .
, ?
eslint, .
22. ,
- . , — , - . , ,
X-Powered-By , , . , ( , , Node.js express).
→
-
- . , , -, — . .
23.
, . — , Node.js.
,
OWASP .
- root- .
- ( SSH-).
- , , , . OWASP, .
- , . , .
- OAuth, OpenID, . Basic Authentication.
- . , ( — ), X , Y .
- — , — . , .
- , , . ( — GitHub, AWS, Jenkins, ).
. , Node.js-.
! -, ?
