نحن نتعرض للهجوم! 23+ الممارسات الأمنية Node.js أفضل

نحن نتعرض للهجوم! 23+ الممارسات الأمنية Node.js أفضل

تم جمعها وبرعاية وكتابة: يوني جولدبرج وكايل مارتن وبرونو شوفلر

مراجع تقني: ليران تال (مجموعة عمل الأمن Node.js)

مرحبًا بك في قائمتنا الشاملة لأفضل ممارسات الأمان في Node.js والتي تلخص وترتب المقالات والمقالات ذات التصنيف الأعلى

بضع كلمات قبل أن نبدأ

تنفجر هجمات الويب هذه الأيام حيث يأتي الأمن إلى مقدمة المسرح. قمنا بتجميع أكثر من 23 من أفضل ممارسات الأمان في Node.js (+40 من ممارسات الأمان العامة الأخرى) من جميع المقالات رفيعة المستوى حول العالم. يمثل العمل هنا جزءًا من مستودع GitHub لأفضل الممارسات ، والذي يحتوي على أكثر من 80 من ممارسات Node.js. ملاحظة: تحتوي العديد من العناصر على رابط قراءة المزيد لتوضيح الموضوع مع مثال على الكود ومعلومات مفيدة أخرى.

احصل على أفضل الممارسات الأسبوعية عبر موجز Twitter الخاص بنا

1. احتضان قواعد الأمن linter

TL ؛ DR: استخدم الإضافات اللنتينية المتعلقة بالأمان مثل eslint-plugin-security لالتقاط نقاط الضعف والقضايا الأمنية في أقرب وقت ممكن - أثناء ترميزها. يمكن أن يساعد هذا في التعرف على نقاط ضعف الأمان مثل استخدام eval أو استدعاء عملية تابعة أو استيراد وحدة نمطية باستخدام حرفي غير سلسلة (مثل إدخال المستخدم). انقر فوق "اقرأ المزيد" أدناه للاطلاع على أمثلة التعليمات البرمجية التي سيتم التقاطها بواسطة linter الأمان

خلاف ذلك: ما يمكن أن يكون الضعف الأمني ​​المباشر أثناء التطوير يصبح مشكلة رئيسية في الإنتاج. أيضًا ، قد لا يتبع المشروع ممارسات أمان تعليمات برمجية متسقة ، مما يؤدي إلى ظهور ثغرات أمنية أو أسرار حساسة تُرتكب في مستودعات عن بُعد

اقرأ المزيد: قواعد Linter

ليس من الضروري أن يكون Linting مجرد أداة لفرض القواعد المتحيزة حول المسافات البيضاء أو الفاصلة المنقوطة أو البيانات eval. يوفر ESLint إطارًا قويًا للتخلص من مجموعة واسعة من الأنماط التي يحتمل أن تكون خطرة في الشفرة (التعبيرات العادية والتحقق من صحة المدخلات وما إلى ذلك). أعتقد أنه يوفر أداة جديدة قوية تستحق الاهتمام من قِبل مطوري JavaScript المهتمين بالأمان. (آدم بالدوين)
المزيد من عروض الأسعار وأمثلة التعليمات البرمجية هنا

2. الحد من الطلبات المتزامنة باستخدام الوسيطة

هجمات TL ؛ DR: DOS شائعة جدًا وسهلة الاستخدام نسبيًا. قم بتطبيق الحد من المعدل باستخدام خدمة خارجية مثل موازنات التحميل السحابية أو جدران الحماية السحابية أو nginx أو الحزمة المرنة المحددة للسعر أو (للتطبيقات الأصغر والأقل أهمية) الوسيطة التي تحدد السعر (على سبيل المثال ، معدل السرعة السريعة)

بخلاف ذلك: قد يتعرض أي تطبيق لهجوم يؤدي إلى رفض الخدمة حيث يتلقى المستخدمون الحقيقيون خدمة متدهورة أو غير متوفرة.

قراءة المزيد: تطبيق الحد من معدل

3. استخراج الأسرار من ملفات التكوين أو استخدام الحزم لتشفيرها

TL ؛ DR: لا تقم أبدًا بتخزين أسرار النص العادي في ملفات التكوين أو شفرة المصدر. بدلاً من ذلك ، استخدم أنظمة الإدارة السرية مثل منتجات Vault أو أسرار Kubernetes / Docker أو استخدام متغيرات البيئة. كنتيجة أخيرة ، يجب تشفير الأسرار المخزنة في التحكم بالمصادر وإدارتها (مفاتيح التدوير ، انتهاء الصلاحية ، التدقيق ، إلخ). استخدم خطاطيف الدفع المسبق / الالتزام لمنع ارتكاب الأسرار بطريق الخطأ

خلاف ذلك: يمكن التحكم عن طريق المصدر ، حتى بالنسبة للمستودعات الخاصة ، عن طريق الخطأ ، عند هذه النقطة تتعرض جميع الأسرار. سيوفر الوصول إلى التحكم في المصدر لطرف خارجي عن غير قصد الوصول إلى الأنظمة ذات الصلة (قواعد البيانات ، apis ، الخدمات ، إلخ).

اقرأ المزيد: الإدارة السرية

4. منع ثغرات حقن الاستعلام مع مكتبات ORM / ODM

TL ؛ DR: لمنع حقن SQL / NoSQL والهجمات الضارة الأخرى ، استخدم دائمًا ORM / ODM أو مكتبة قاعدة بيانات تفلت من البيانات أو تدعم استعلامات معلمة محددة أو مفهرسة ، وتعتني بالتحقق من صحة إدخال المستخدم للأنواع المتوقعة. لا تستخدم أبدًا سلاسل قوالب JavaScript أو تسلسل السلسلة لحقن القيم في الاستعلامات لأن هذا يفتح التطبيق الخاص بك أمام مجموعة واسعة من نقاط الضعف. تحتوي جميع مكتبات الوصول إلى البيانات Node.js ذات السمعة الطيبة (مثل Sequelize و Knex و mongoose) على حماية مضمنة ضد هجمات الحقن

خلاف ذلك: قد يؤدي إدخال المستخدم غير المصادق أو غير المعتمد إلى حقن المشغل عند العمل مع MongoDB لـ NoSQL ، وعدم استخدام نظام التعقيم المناسب أو ORM سيسمح بسهولة لهجمات حقن SQL ، مما يخلق ثغرة أمنية هائلة.

اقرأ المزيد: منع حقن الاستعلام باستخدام مكتبات ORM / ODM

نقدر الجهد؟ يرجى نجمة مشروعنا على جيثب

5. تجنب هجمات DOS من خلال تحديد صراحة متى يجب أن تعطل العملية

TL ؛ DR: سوف تتعطل عملية العقدة عند عدم معالجة الأخطاء. توصي العديد من أفضل الممارسات بالخروج حتى لو تم اكتشاف خطأ وتم التعامل معه. Express ، على سبيل المثال ، سيتعطل عند حدوث أي خطأ غير متزامن - إلا إذا قمت بلف المسارات باستخدام جملة catch. هذا يفتح بقعة هجوم حلوة للغاية للمهاجمين الذين يتعرفون على المدخلات التي تؤدي إلى تعطل العملية وإرسال الطلب نفسه بشكل متكرر. لا يوجد علاج فوري لهذا ولكن هناك بعض التقنيات التي يمكن أن تخفف من الألم: تنبيه شديد الخطورة في أي وقت تعطل فيه عملية بسبب خطأ غير معالج ، والتحقق من صحة المدخلات وتجنب تعطل العملية بسبب إدخال غير صالح للمستخدم ، والتفاف جميع المسارات مع الصيد و ضع في اعتبارك عدم التعطل عند ظهور خطأ في طلب ما (على عكس ما يحدث عالميًا)

خلاف ذلك: هذا مجرد تخمين متعلم: نظرًا للعديد من تطبيقات Node.js ، إذا حاولنا تمرير نص JSON فارغ لجميع طلبات POST - فسوف تتعطل حفنة من التطبيقات. عند هذه النقطة ، يمكننا فقط تكرار إرسال نفس الطلب لإنزال التطبيقات بسهولة

6. اضبط رؤوس استجابة HTTP لتحسين الأمان

TL ؛ DR: يجب أن يستخدم تطبيقك رؤوسًا آمنة لمنع المهاجمين من استخدام الهجمات الشائعة مثل البرمجة النصية للمواقع المشتركة (XSS) و clickjacking وغيرها من الهجمات الضارة. يمكن تكوين هذه بسهولة باستخدام وحدات مثل خوذة.

خلاف ذلك: يمكن للمهاجمين تنفيذ هجمات مباشرة على مستخدمي التطبيق ، مما يؤدي إلى ثغرات أمنية هائلة

قراءة المزيد: استخدام رؤوس آمنة في التطبيق الخاص بك

7. فحص باستمرار وتلقائيا عن التبعيات الضعيفة

TL ؛ DR: مع النظام البيئي npm ، من الشائع أن يكون لديك العديد من التبعيات للمشروع. يجب دائمًا إبقاء التبعيات قيد الفحص عند العثور على ثغرات أمنية جديدة. استخدم أدوات مثل npm audit أو nsp أو snyk لتتبع ومراقبة وتصحيح التبعيات الضعيفة. دمج هذه الأدوات مع إعداد CI الخاص بك حتى تتمكن من الحصول على تبعية ضعيفة قبل أن تصل إلى الإنتاج.

خلاف ذلك: يمكن للمهاجم اكتشاف إطار الويب الخاص بك ومهاجمة جميع نقاط الضعف المعروفة.

اقرأ المزيد: أمن التبعية

8. تجنب استخدام مكتبة تشفير Node.js لمعالجة كلمات المرور ، استخدم Bcrypt

TL ؛ DR: يجب تخزين كلمات المرور أو الأسرار (مفاتيح API) باستخدام دالة هاش + ملح آمنة مثل bcrypt ، والتي يجب أن تكون الخيار المفضل على تطبيق JavaScript بسبب أسباب الأداء والأمان.

خلاف ذلك: كلمات المرور أو الأسرار التي لا تزال قائمة دون استخدام وظيفة آمنة تكون عرضة للإجبار الغاشم وهجمات القاموس التي سوف تؤدي إلى الكشف عنها في نهاية المطاف.

اقرأ المزيد: استخدم Bcrypt

9. الهروب HTML ، JS و CSS الإخراج

TL ؛ DR: قد يتم تنفيذ البيانات غير الموثوقة التي يتم إرسالها إلى المستعرض بدلاً من عرضها فقط ، ويُشار إليها عادةً على أنها هجوم نص برمجي عبر المواقع (XSS). قم بتخفيف ذلك عن طريق استخدام مكتبات مخصصة تضع علامة صريحة على البيانات كمحتوى خالص لا يجب تنفيذه أبدًا (على سبيل المثال ، الترميز ، الهروب)

خلاف ذلك: قد يقوم أحد المهاجمين بتخزين شفرة JavaScript ضارة في قاعدة بياناتك والتي سيتم إرسالها بعد ذلك إلى العملاء الفقراء

قراءة المزيد: الهروب الإخراج

10. التحقق من صحة مخططات JSON الواردة

TL ؛ DR: التحقق من الحمولة الفعلية للطلبات الواردة والتأكد من أنها تؤهل التوقعات ، وتفشل سريعًا إذا لم تكن كذلك. لتجنب ترميز التحقق من الصحة المملة داخل كل مسار ، يمكنك استخدام مخططات التحقق من الصحة خفيفة الوزن المستندة إلى JSON مثل jsonschema أو joi

بخلاف ذلك: يزيد كرمك ونهجك المتسامح من سطح الهجوم بشكل كبير ويشجع المهاجم على تجربة العديد من المدخلات حتى يجد بعض التراكبات لتعطل التطبيق

قراءة المزيد: التحقق من صحة مخططات JSON الواردة

11. دعم القائمة السوداء الرموز JWT

TL ؛ DR: عند استخدام الرموز المميزة لـ JWT (على سبيل المثال ، مع Passport.js) ، لا توجد افتراضيًا آلية لإبطال الوصول من الرموز المميزة الصادرة. بمجرد اكتشاف بعض أنشطة المستخدمين الضارة ، لا توجد طريقة لمنعهم من الوصول إلى النظام طالما أنهم يحملون رمزًا صالحًا. قم بتخفيف هذا عن طريق تطبيق قائمة سوداء من الرموز المميزة غير الموثوق بها والتي يتم التحقق من صحة كل طلب.

خلاف ذلك: يمكن استخدام الرموز المميزة منتهية الصلاحية أو في غير محله من قبل جهة خارجية للوصول إلى أحد التطبيقات وانتحال شخصية الرمز المميز.

قراءة المزيد: القائمة السوداء JWTs

12. منع هجمات القوة الغاشمة ضد الترخيص

TL ؛ DR: تقنية بسيطة وقوية هي الحد من محاولات التفويض باستخدام مقياسين:

  1. الأول هو عدد المحاولات الفاشلة المتتالية التي قام بها نفس المعرف / اسم المستخدم الفريد وعنوان IP.
  2. والثاني هو عدد المحاولات الفاشلة من عنوان IP خلال فترة زمنية طويلة. على سبيل المثال ، قم بحظر عنوان IP إذا قام بإجراء 100 محاولة فاشلة في يوم واحد.

خلاف ذلك: يمكن للمهاجم إصدار محاولات كلمة مرور آلية غير محدودة للوصول إلى حسابات مميزة في تطبيق ما

اقرأ المزيد: الحد من معدل الدخول

13. قم بتشغيل Node.js كمستخدم غير الجذر

TL ؛ DR: هناك سيناريو شائع حيث يعمل Node.js كمستخدم الجذر مع أذونات غير محدودة. على سبيل المثال ، هذا هو السلوك الافتراضي في حاويات Docker. يوصى بإنشاء مستخدم غير جذر وإما أن يخبزه في صورة Docker (الأمثلة الواردة أدناه) أو تشغيل العملية نيابة عن هؤلاء المستخدمين من خلال استدعاء الحاوية التي تحمل علامة "-u اسم المستخدم"

خلاف ذلك: يحصل المهاجم الذي يدير تشغيل برنامج نصي على الخادم على طاقة غير محدودة على الجهاز المحلي (مثل تغيير iptable وإعادة توجيه حركة المرور إلى الخادم الخاص به)

قراءة المزيد: تشغيل Node.js كمستخدم غير الجذر

14. الحد من حجم الحمولة النافعة باستخدام وكيل عكسي أو وسيط

TL ؛ DR: كلما كان حجم الحمولة الصافية للجسم أكبر ، كلما زاد صعوبة عمل الخيط الفردي في معالجته. هذه فرصة للمهاجمين لجلب الخوادم إلى الركبتين دون الحاجة إلى كمية هائلة من الطلبات (هجمات DOS / DDOS). قم بتخفيف هذا الحد من حجم النص للطلبات الواردة على الحافة (مثل جدار الحماية ، ELB) أو عن طريق تكوين محلل نص صريح لقبول حمولات صغيرة فقط

خلاف ذلك: سيتعين على التطبيق الخاص بك التعامل مع الطلبات الكبيرة ، غير قادر على معالجة العمل المهم الآخر الذي يتعين عليه إنجازه ، مما يؤدي إلى آثار على الأداء وقابلية التعرض لهجمات DOS

اقرأ المزيد: الحد من حجم الحمولة الصافية

احصل على أفضل الممارسات الأسبوعية عبر موجز Twitter الخاص بنا

15. تجنب بيانات جافا سكريبت eval

TL ؛ DR: eval هو الشر لأنه يسمح بتنفيذ كود JavaScript مخصص أثناء وقت التشغيل. هذا ليس مجرد مشكلة تتعلق بالأداء ولكنه يمثل أيضًا مشكلة أمنية مهمة بسبب شفرة جافا سكريبت الضارة التي يمكن الحصول عليها من مدخلات المستخدم. ميزة اللغة الأخرى التي يجب تجنبها هي مُنشئ دالة جديد. setTimeout و setInterval يجب ألا يتم تمرير كود JavaScript الديناميكي أيضًا.

خلاف ذلك: تعثر شفرة جافا سكريبت الخبيثة على طريقة في النص الذي تم تمريره إلى التقييم النهائي أو وظائف أخرى في الوقت الحقيقي لتقييم لغة جافا سكريبت ، وسوف تحصل على حق الوصول الكامل إلى أذونات JavaScript على الصفحة. غالبًا ما تتجلى مشكلة عدم الحصانة هذه في هجوم XSS.

قراءة المزيد: تجنب بيانات جافا سكريبت eval

16. منع الشر RegEx من التحميل الزائد تنفيذ موضوع واحد

TL ؛ DR: تعبيرات عادية ، بينما تكون في متناول اليد ، تشكل تهديدًا حقيقيًا لتطبيقات JavaScript بشكل عام ، وعلى منصة Node.js على وجه الخصوص. قد يتطلب إدخال المستخدم لتطابق النص مقدارًا بارزًا من دورات وحدة المعالجة المركزية للمعالجة. قد تكون معالجة RegEx غير فعالة إلى حد أن الطلب الفردي الذي يتحقق من صحة 10 كلمات يمكنه حظر حلقة الحدث بأكملها لمدة 6 ثوانٍ وتعيين وحدة المعالجة المركزية على . لهذا السبب ، تفضل حزم التحقق من الصحة الخاصة بجهات خارجية مثل validator.js بدلاً من كتابة أنماط Regex الخاصة بك ، أو الاستفادة من regex الآمن للكشف عن أنماط regex الحساسة

بخلاف ذلك: قد تكون عمليات إعادة التدوين المكتوبة بشكل سيئ عرضة لهجمات "التعبير العادي" التي من شأنها أن تمنع حلقة الحدث تمامًا. على سبيل المثال ، تم العثور على باقة اللحظة المشهورة مع استخدام RegEx الضار في نوفمبر 2017

اقرأ المزيد: منع RegEx الخبيثة

17. تجنب تحميل وحدة باستخدام متغير

TL ؛ DR: تجنب طلب / استيراد ملف آخر بمسار تم تقديمه كمعلمة نظرًا للقلق من أنه قد يكون مصدره إدخال المستخدم. يمكن توسيع هذه القاعدة للوصول إلى الملفات بشكل عام (أي fs.readFile ()) أو الوصول إلى الموارد الحساسة الأخرى مع المتغيرات الديناميكية الناشئة عن إدخال المستخدم. يمكن لإنتل لينج- Eslint-plugin-security أن يلتقط هذه الأنماط ويحذر في وقت مبكر بما فيه الكفاية

خلاف ذلك: يمكن لإدخال المستخدم الضار أن يجد طريقه إلى معلمة تُستخدم لطلب ملفات تم العبث بها ، على سبيل المثال ملف تم تحميله مسبقًا على نظام الملفات ، أو الوصول إلى ملفات النظام الموجودة بالفعل.

اقرأ المزيد: تحميل وحدة آمنة

18. تشغيل رمز غير آمن في رمل

TL ؛ DR: عند تكليفك بتشغيل تعليمات برمجية خارجية يتم توفيرها في وقت التشغيل (مثل البرنامج المساعد) ، استخدم أي نوع من بيئة تنفيذ "صندوق الحماية" التي تعزل وتحمي الشفرة الرئيسية ضد البرنامج المساعد. يمكن تحقيق ذلك باستخدام عملية مخصصة (على سبيل المثال cluster.fork ()) أو بيئة بدون خادم أو حزم npm مخصصة تعمل بمثابة صندوق رمل

خلاف ذلك: يمكن أن يهاجم المكون الإضافي من خلال مجموعة لا نهائية من الخيارات مثل الحلقات اللانهائية ، والحمل الزائد للذاكرة ، والوصول إلى متغيرات بيئة العملية الحساسة

قراءة المزيد: تشغيل رمز غير آمن في رمل

19. توخي الحذر عند العمل مع عمليات الطفل

TL ؛ DR: تجنب استخدام العمليات الفرعية عندما يكون ذلك ممكنًا والتحقق من صحة وتعقيم المدخلات للتخفيف من هجمات حقن القشرة إذا كنت لا تزال بحاجة لذلك. تفضل باستخدام child_process.execFile والذي بحكم التعريف سوف ينفذ أمرًا واحدًا فقط مع مجموعة من السمات ولن يسمح بتوسيع معامل shell.

خلاف ذلك: يمكن أن يؤدي الاستخدام الساذج للعمليات التابعة إلى تنفيذ الأوامر عن بُعد أو هجمات حقن القذيفة بسبب إدخال المستخدم الضار الذي تم تمريره إلى أمر نظام غير معيّن.

اقرأ المزيد: كن حذرًا عند التعامل مع العمليات الفرعية

20. إخفاء تفاصيل الخطأ من العملاء

TL ؛ DR: يخفي معالج الأخطاء السريعة المدمج تفاصيل الخطأ افتراضيًا. ومع ذلك ، تعتبر فرص تنفيذ منطق الخطأ الخاص بك مع كائنات خطأ مخصصة (تعتبر من قبل العديد من أفضل الممارسات) كبيرة. إذا قمت بذلك ، فتأكد من عدم إعادة كائن Error بالكامل إلى العميل ، والذي قد يحتوي على بعض تفاصيل التطبيق الحساسة

خلاف ذلك: تفاصيل التطبيق الحساسة مثل مسارات ملفات الخادم والوحدات الخارجية المستخدمة ، وسير العمل الداخلية للتطبيق التي يمكن استغلالها من قبل المهاجم ، يمكن تسربها من المعلومات الموجودة في تتبع المكدس

قراءة المزيد: إخفاء تفاصيل الخطأ من العملاء

21. تكوين 2FA ل npm أو الغزل

TL ؛ DR: يجب حماية أي خطوة في سلسلة التطوير باستخدام MFA (مصادقة متعددة العوامل) ، وتمثل npm / Yarn فرصة رائعة للمهاجمين الذين يمكنهم الحصول على كلمة مرور بعض مطور البرامج. باستخدام بيانات اعتماد المطور ، يمكن للمهاجمين إدخال تعليمات برمجية ضارة في المكتبات التي يتم تثبيتها على نطاق واسع عبر المشاريع والخدمات. ربما حتى على شبكة الإنترنت إذا نشرت في الأماكن العامة. إن تمكين المصادقة الثنائية في npm لا يترك فرصًا تقريبًا للمهاجمين لتغيير رمز الحزمة الخاصة بك.

بخلاف ذلك: هل سمعت عن مطور eslint الذي اختُطفت كلمة المرور؟

22. تعديل إعدادات الوسيطة الجلسة

TL ؛ DR: كل إطار عمل وتكنولوجيا على شبكة الإنترنت له نقاط ضعفه المعروفة - لإخبار المهاجم بإطار العمل الذي نستخدمه هو مساعدة كبيرة لهم. يمكن أن يؤدي استخدام الإعدادات الافتراضية لجلسات الحوار الوسيطة إلى تعريض تطبيقك لهجمات اختطاف خاصة بالوحدات النمطية والإطار بطريقة مماثلة لرأس X-Powered-By. حاول إخفاء أي شيء يحدد ويكشف تكدس التقنية الخاص بك (على سبيل المثال ، Node.js ، صريح)

خلاف ذلك: يمكن إرسال ملفات تعريف الارتباط عبر اتصالات غير آمنة ، وقد يستخدم المهاجم تعريف الجلسة لتحديد الإطار الأساسي لتطبيق الويب ، وكذلك نقاط الضعف الخاصة بالوحدة

اقرأ المزيد: ملفات تعريف الارتباط وأمن الجلسة

23. تجنب هجمات DOS من خلال تحديد صراحة متى يجب أن تعطل العملية

TL ؛ DR: سوف تتعطل عملية العقدة عند عدم معالجة الأخطاء. توصي العديد من أفضل الممارسات بالخروج حتى لو تم اكتشاف خطأ وتم التعامل معه. Express ، على سبيل المثال ، سيتعطل عند حدوث أي خطأ غير متزامن - إلا إذا قمت بلف المسارات باستخدام جملة catch. هذا يفتح بقعة هجوم حلوة للغاية للمهاجمين الذين يتعرفون على المدخلات التي تؤدي إلى تعطل العملية وإرسال الطلب نفسه بشكل متكرر. لا يوجد علاج فوري لهذا ولكن هناك بعض التقنيات التي يمكن أن تخفف من الألم: تنبيه شديد الخطورة في أي وقت تعطل فيه عملية بسبب خطأ غير معالج ، والتحقق من صحة المدخلات وتجنب تعطل العملية بسبب إدخال غير صالح للمستخدم ، والتفاف جميع المسارات مع الصيد و ضع في اعتبارك عدم التعطل عند ظهور خطأ في طلب ما (على عكس ما يحدث عالميًا)

خلاف ذلك: هذا مجرد تخمين متعلم: نظرًا للعديد من تطبيقات Node.js ، إذا حاولنا تمرير نص JSON فارغ لجميع طلبات POST - فسوف تتعطل حفنة من التطبيقات. عند هذه النقطة ، يمكننا فقط تكرار إرسال نفس الطلب لإنزال التطبيقات بسهولة.

24. منع عمليات إعادة التوجيه غير الآمنة

TL ؛ DR: يمكن لعمليات إعادة التوجيه التي لا تتحقق من صحة إدخال المستخدم أن تمكن المهاجمين من بدء عمليات الاحتيال الاحتيالية وسرقة بيانات اعتماد المستخدم وتنفيذ إجراءات ضارة أخرى.

بخلاف ذلك: إذا اكتشف أحد المهاجمين أنك لا تقوم بالتحقق من صحة المدخلات الخارجية التي يوفرها المستخدم ، فيجوز لهم استغلال هذه الثغرة الأمنية عن طريق نشر ارتباطات مصممة خصيصًا على المنتديات ووسائل التواصل الاجتماعي والأماكن العامة الأخرى لحمل المستخدمين على النقر فوقه.

اقرأ المزيد: منع عمليات إعادة التوجيه غير الآمنة

25. تجنب نشر الأسرار في سجل npm

TL ؛ DR: يجب اتخاذ الاحتياطات لتجنب خطر نشر الأسرار بطريق الخطأ إلى سجلات npm العامة. يمكن استخدام ملف .npmignore لإدراج ملفات أو مجلدات محددة في القائمة السوداء ، أو يمكن أن تعمل صفيف الملفات في package.json كقائمة بيضاء.

بخلاف ذلك: تكون مفاتيح API الخاصة بالمشروع أو كلمات المرور أو الأسرار الأخرى مفتوحة ليتم إساءة استخدامها من قبل أي شخص يصادفها ، مما قد يؤدي إلى خسائر مالية وانتحال شخصية وغيرها من المخاطر.

اقرأ المزيد: تجنب نشر الأسرار

نقدر الجهد؟ يرجى نجمة مشروعنا على جيثب

26. قائمة بـ 40 نصيحة أمنية عامة (لا تتعلق بالتحديد بـ Node.js)

الرموز النقطية التالية هي إجراءات أمنية مشهورة وهامة يجب تطبيقها في كل تطبيق. نظرًا لعدم ارتباطها بالضرورة بـ Node.js وتنفيذها بشكل مشابه بغض النظر عن إطار التطبيق - فإننا ندرجها هنا كملحق. يتم تجميع العناصر حسب تصنيف OWASP الخاص بهم. تتضمن العينة النقاط التالية:

  • تتطلب MFA / 2FA لحساب الجذر
  • قم بتدوير كلمات المرور ومفاتيح الوصول بشكل متكرر ، بما في ذلك مفاتيح SSH
  • قم بتطبيق سياسات كلمة مرور قوية ، لكل من العمليات وإدارة المستخدم داخل التطبيق ، راجع توصية كلمة مرور OWASP
  • لا تشحن أو تنشر باستخدام أي بيانات اعتماد افتراضية ، خاصة للمستخدمين المشرفين
  • استخدم طرق المصادقة القياسية فقط مثل OAuth و OpenID وما إلى ذلك - تجنب المصادقة الأساسية
  • الحد من معدل المصادقة: عدم السماح لأكثر من X محاولات تسجيل الدخول (بما في ذلك استعادة كلمة المرور ، وما إلى ذلك) في فترة Y دقيقة
  • عند فشل تسجيل الدخول ، لا تدع المستخدم يعرف ما إذا كان التحقق من اسم المستخدم أو كلمة المرور قد فشل ، ما عليك سوى إرجاع خطأ شائع في المصادقة
  • فكّر في استخدام نظام مركزي لإدارة المستخدم لتجنب إدارة حسابات متعددة لكل موظف (مثل GitHub ، AWS ، Jenkins ، وما إلى ذلك) والاستفادة من نظام إدارة مستخدم تم اختباره في المعركة

يمكن العثور على قائمة كاملة بـ 40 نصيحة أمنية عامة في مستودع أفضل ممارسات Node.js الرسمي!

اقرأ المزيد: 40 نصيحة أمنية عامة

قراءة جيدة أخرى:

  • أفضل ممارسات إنتاج Node.js - Yoni Goldberg
  • نظرة عامة على الأمن Node.js - Gergely Nemeth
  • أفضل ممارسات أمان Express - مسؤول Express
  • يوتيوب: خريطة طريق الأمن Node.js - مايك صموئيل

المؤلفون - عنا

  • يوني جولدبيرج - مستشار Node.js ، خدمة العملاء في الولايات المتحدة الأمريكية وأوروبا وإسرائيل
  • كايل مارتن - Full Stack Developer ومقره نيوزيلندا
  • برونو شوفلر - مطور مواقع ويب كامل ومتحمس Node.js
نقدر الجهد؟ التصفيق في الأسفل (حتى 50 مرة) يمكن أن يجعل يومنا