نلفت انتباهك إلى أفضل 10 أدوات تحكم استباقية لمطوري البرامج - 10 جوانب أمان يجب على مطوري البرامج التركيز عليها. تحتوي هذه المقالة على قائمة تقنيات الأمان المطلوبة للتنفيذ عند تطوير كل مشروع جديد.
البرامج غير المحمية تقوض أمن مرافق البنية التحتية الحيوية ، مثل الرعاية الصحية أو الدفاع أو الطاقة أو التمويل. أصبحت البنية التحتية الرقمية العالمية لدينا أكثر تعقيدًا ، حيث يزداد عدد العلاقات بين مكوناتها ، وبالتالي تتزايد أهمية أمان التطبيقات بشكل كبير. لم يعد بالإمكان تجاهل التهديدات الأمنية البسيطة نسبياً.
OWASP
مشروع أمان تطبيق الويب المفتوح (OWASP) هو مشروع أمان تطبيق ويب مفتوح المصدر. يشمل مجتمع OWASP الشركات والمؤسسات التعليمية والأفراد من جميع أنحاء العالم. تعمل OWASP على المقالات والبرامج التعليمية والوثائق والأدوات والتقنيات المتاحة للجمهور.
تتم الإشارة إلى مشروع OWASP من خلال العديد من المعايير والأدوات والمؤسسات ، بما في ذلك MITER و PCI DSS و DISA و FTC وغيرها الكثير.
يشبه مشروع Proactive Defense: Top-10 OWASP Requirements مشروع
OWASP Top-10 ، لكنه يركز على أساليب وتوصيات للحماية من التهديدات ، وليس على التهديدات نفسها. ترتبط كل طريقة وتوصية في هذا المستند بواحد أو أكثر من التهديدات من قائمة OWASP Top-10.
الأهداف والغايات
إن الهدف من مشروع Proactive Defense: OWASP Top 10 Requirements هو لفت الانتباه إلى أمان التطبيق من خلال معالجة أهم جوانب أمن المعلومات التي يجب على مطوري البرامج دراستها. نحن نشجع المؤسسات على الاستفادة من توصيات الدفاع الاستباقية لـ OWASP وتعليم المطورين كيفية الاهتمام بأمان التطبيق ، مع إعطاء أهمية للأخطاء التي حدثت في المؤسسات الأخرى. نأمل أن تكون توصيات OWASP مفيدة لك عند إنشاء تطبيقات آمنة.
الجمهور المستهدف
المستند مخصص للمطورين بشكل أساسي. ومع ذلك ، سيكون مفيدًا لمديري التطوير ومديري المنتجات ومتخصصي ضمان الجودة ومديري المشاريع والمشاركين الآخرين في عملية إنشاء البرامج.
أعلى 10 متطلبات الدفاع الاستباقية
C1: تعريف متطلبات السلامة
تصف متطلبات الأمان الوظائف التي يجب تنفيذها لتوفير إعدادات أمان برامج معينة. وهي تستند إلى معايير الصناعة والقوانين المعمول بها وبيانات الضعف. تحدد المتطلبات الوظائف التي يجب تطويرها أو تطويرها بشكل أكبر لحل مشكلات أمنية محددة أو للقضاء على التهديدات المحتملة.
يعد OWASP Application Security Certification Standard (ASVS) عبارة عن كتالوج لمتطلبات الأمان المتاحة وخيارات التحقق. يمكن أن يوفر OWASP ASVS متطلبات أمان متقدمة لفرق التطوير.
يتم تصنيف متطلبات الأمان استنادًا إلى وظائف الأمان ذات المستوى الأعلى الشائعة. على سبيل المثال ، تحتوي ASVS على الفئات التالية: المصادقة ، والتحكم في الوصول ، ومعالجة الأخطاء والتسجيل ، وخدمات الويب. لكل فئة هناك قائمة من المعلمات التي يوصى بالتحقق منها.
تتضمن عملية تطبيق متطلبات الأمان بنجاح أربع مراحل: البحث والاختيار ، والتوثيق ، والتنفيذ ، وتأكيد تنفيذ وظائف الأمان الجديدة ووظائف التطبيق.
C2: استخدام الأطر والمكتبات الآمنة
المكتبات والأطر الآمنة مع ميزات الأمان المضمنة تساعد المطورين على تجنب الثغرات الأمنية أثناء مرحلتي التطوير والتنفيذ. قد لا يتمتع المطورون الذين ينشئون تطبيقًا من البداية بمعرفة كافية أو وقت أو أموال كافية لتنفيذ أو الحفاظ على أمان التطبيق. يمكن أن يؤدي استخدام أطر عمل آمنة إلى زيادة مستوى أمان التطبيق.
عندما تقوم بتضمين مكتبات أو أطر عمل تابعة لجهات خارجية في برنامجك ، فيجب مراعاة التوصيات التالية:
- استخدام المكتبات والأطر من مصادر موثوقة تم تطويرها بنشاط واستخدامها على نطاق واسع في التطبيقات ؛
- ترجمة وتحديث كتالوج جميع مكتبات الطرف الثالث ؛
- اجعل المكتبات ومكوناتها محدثة. استخدم أدوات مثل التحقق من التبعية OWASP و Retire.JS لتحديد التبعيات في المشروعات ، وكذلك التحقق من الثغرات الأمنية المعروفة والمنشورة في كود الطرف الثالث ؛
- استخدم تغليف المكتبة والوظائف الضرورية لبرنامجك فقط لتقليل احتمالية وقوع هجمات.
C3: توفير الوصول الآمن إلى قواعد البيانات
هذا القسم مخصص لتوفير الوصول الآمن إلى جميع مستودعات البيانات ، بما في ذلك قواعد البيانات العلائقية وقواعد بيانات NoSQL.
أحد أخطر التهديدات لأمان التطبيق هو حقن SQL. هذا النوع من الهجوم سهل التنفيذ: يمكن حقن كود SQL إذا تمت إضافة مدخلات غير موثوق بها ديناميكيًا إلى استعلامات SQL ، والتي تحدث عادةً عن طريق إرفاقها بالخط الرئيسي. قد يؤدي استغلال هذه الثغرة الأمنية إلى سرقة أو حذف أو تغيير قواعد البيانات. يمكن أيضًا استخدام التطبيق لتنفيذ أوامر ضارة على نظام يحتوي على قاعدة بياناتك ، مما سيتيح للمهاجم الحصول على موطئ قدم في الشبكة.
لمنع حقن SQL ، يجب تجنب تفسير الإدخال الذي لم يتم التحقق منه كجزء من أوامر SQL. أفضل حل هو استخدام طريقة "تحديد معلمات الاستعلام". يجب تطبيق هذه الطريقة على تصميمات SQL و OQL ، وكذلك الإجراءات المخزنة.
يمكن العثور على أمثلة لمعلمات استعلام ASP و ColdFusion و C # و Delphi و .NET و Go و Java و Perl و PHP و PL / SQL و PostgreSQL و Python و R و Ruby و Scheme على
http://bobby-tables.com و في
مذكرة OWASP لمعلمات الاستعلام .
C4: تشفير البيانات وحمايتها
الترميز والهروب من طرق الحماية ضد حقن الشفرة. الترميز ، الذي يسمى أيضًا "تشفير الإخراج" ، هو تحويل الأحرف الخاصة إلى مجموعات مكافئة لا تشكل خطراً على المترجم الشفهي. على سبيل المثال ، يتم تحويل الحرف <إلى مجموعة <عند إضافته إلى صفحة HTML. يتكون الهروب من إضافة أحرف خاصة أمام أحرف أو سلاسل لمنع تفسيرها بشكل غير صحيح ، على سبيل المثال ، تتيح إضافة \ character قبل "(علامات الاقتباس المزدوجة) إمكانية ترجمتها كجزء من النص ، وليس كطرف فاصل أسطر.
من الأفضل تطبيق الترميز مباشرة قبل تمرير البيانات إلى المترجم. إذا قمت بتطبيق هذه الطريقة في وقت مبكر جدًا من معالجة الطلب ، فقد يؤثر الترميز أو التدريع على استخدام المحتوى في أجزاء أخرى من البرنامج. على سبيل المثال ، إذا تم تجاوز محتوى HTML قبل حفظه في قاعدة البيانات ، وتهرب الواجهة تلقائيًا من هذه البيانات مرة أخرى ، فلن يتم عرض المحتوى بشكل صحيح بسبب الهروب المزدوج.
يمكن استخدام الترميز أو الهروب لمنع أشكال التضمين الأخرى في المحتوى. على سبيل المثال ، يمكنك تحييد بعض الحروف الأولية الخاصة عند إدخال البيانات لأوامر النظام. وهذا ما يسمى "أوامر الهروب من نظام التشغيل" ، "قذيفة الهروب" ، إلخ. يمكن استخدام هذه الحماية لمنع "حقن الأوامر".
هناك أشكال أخرى من الهروب التي يمكن استخدامها لمنع الحقن ، على سبيل المثال ، الهروب من سمات XML التي تحمي من أشكال مختلفة من زخارف مسارات XML و XML ، وتجنب أسماء LDAP الفريدة لمنع حقن LDAP المختلفة.
C5: التحقق الإلزامي لجميع المدخلات
يعد التحقق من صحة بيانات الإدخال جزءًا من تقنية البرمجة التي تضمن وصول البيانات المنسقة بشكل صحيح إلى مكونات البرنامج.
القواعد النحوية والدلالية
يجب أن يتحقق التطبيق من البيانات للتأكد من مطابقتها للقواعد النحوية والدلالية (بهذا الترتيب) قبل استخدامها (بما في ذلك العرض للمستخدم).
تعني القاعدة النحوية أن البيانات تطابق العرض التقديمي المتوقع. على سبيل المثال ، في التطبيق ، يمكن للمستخدم تحديد "معرف" مكون من أربعة أرقام لأداء عمليات معينة. يمكن للمهاجم إدخال البيانات التي تسمح له بحقن كود SQL ، لذلك يجب أن يتحقق التطبيق من أن البيانات التي تم إدخالها هي أرقام بالضبط ومقدار أربعة أحرف بالضبط (بالإضافة إلى استخدام معلمة الاستعلام المناسبة).
تعني القاعدة الدلالية استخدام بيانات الإدخال فقط التي لا تتجاوز وظيفة وسياق معينين. على سبيل المثال ، عند تحديد إطار زمني ، يجب أن يسبق تاريخ البدء تاريخ الانتهاء.
القوائم البيضاء والسوداء
هناك طريقتان رئيسيتان للتحقق من بناء الجملة - القائمة السوداء والتحقق من القائمة البيضاء.
تم تصميم الطريقة الأولى للبحث عن محتوى "يحتمل أن يكون ضارًا" في البيانات. على سبيل المثال ، قد يمنع تطبيق ويب الإدخال الذي يحتوي على كلمة SCRIPT لمنع البرمجة النصية عبر المواقع. ومع ذلك ، يمكن التحايل على تدبير الحماية هذا باستخدام أحرف صغيرة أو مجموعة من الأحرف الصغيرة والأحرف الكبيرة لعلامة البرنامج النصي.
تهدف الطريقة الثانية إلى تأكيد توافق البيانات مع متطلبات مجموعة من القواعد "المختبرة". على سبيل المثال ، تبحث القائمة البيضاء للولاية الأمريكية عن رمز مكون من حرفين في قائمة الولايات الأمريكية الحالية.
عند إنشاء برنامج آمن ، يوصى باستخدام القائمة البيضاء كحد أدنى. يمكن أن تحتوي القوائم السوداء على أخطاء ، ويمكن التحايل عليها بطرق مختلفة ، وفي حد ذاتها يمكن أن تكون خطرة. على الرغم من أنه من الممكن تجاوز قيود القوائم السوداء ، إلا أنها قد تكون مفيدة في اكتشاف الهجمات الواضحة. وبالتالي ، تساعد القوائم البيضاء في الحد من احتمال وقوع هجوم عن طريق التحقق من أن البيانات تتوافق مع القواعد النحوية والدلالية ، في حين تساعد القوائم السوداء على اكتشاف ومنع الهجمات الواضحة.
الشيكات من جانب العميل والخادم
لضمان الأمن ، يجب دائمًا التحقق من الإدخال من جانب الخادم. يمكن أن تكون عمليات الفحص من جانب العميل مفيدة من حيث الوظيفة والأمان ، ولكن غالبًا ما يتم التحايل عليها بسهولة. لذلك ، يعد التحقق من جانب الخادم هو الأفضل للأمان. على سبيل المثال ، يمكن أن يؤدي التحقق من جافا سكريبت إلى تحذير المستخدم بأن الحقل يجب أن يحتوي على أرقام فقط ، ولكن يجب أن يؤكد التطبيق على جانب الخادم أن بيانات الإدخال هي أرقام في نطاق مقبول من القيم.
C6: تنفيذ التعريف الرقمي
التعريف الرقمي هو تمثيل فريد للمستخدم (أو أي كائن آخر) في المعاملات عبر الإنترنت. المصادقة هي عملية تأكيد أن الشخص أو الكيان هو من هو. إدارة الجلسة هي العملية التي يراقب بها الخادم حالة مصادقة المستخدم حتى يتمكن من الاستمرار في استخدام النظام دون إعادة المصادقة. الإصدار الخاص
NIST 800-63B : دليل التعريف الرقمي (المصادقة وإدارة دورة الحياة) يوفر توصيات مفصلة لتنفيذ متطلبات الهوية الرقمية والتوثيق وإدارة الجلسة.
C7: التحكم الإلزامي في الوصول
يتمثل التحكم في الوصول (أو التخويل) في السماح أو حظر طلبات محددة من المستخدمين أو البرامج أو العمليات ، ويشمل أيضًا إصدار وإلغاء هذه الامتيازات.
تجدر الإشارة إلى أن الترخيص (تأكيد حق الوصول إلى الوظائف أو الموارد الخاصة) لا يساوي المصادقة (التحقق من الهوية).
يؤثر التحكم في الوصول عادةً على العديد من جوانب البرنامج ، اعتمادًا على تعقيد نظام التحكم في الوصول. على سبيل المثال ، عادةً ما تكون إدارة البيانات الوصفية للتحكم في الوصول أو التخزين المؤقت لأغراض قابلية التوسع عبارة عن مكونات إضافية لنظام التحكم في الوصول الذي يجب إنشاؤه أو صيانته. هناك عدة طرق مختلفة للتحكم في الوصول:
- التحكم في الوصول الانتقائي (DAC) - يتضمن تقييد الوصول إلى الكائنات (على سبيل المثال ، الملفات أو عناصر البيانات) بناءً على المعرف ، وكذلك مبدأ "المعرفة الضرورية" للمواضيع (على سبيل المثال ، المستخدمين أو العمليات) و / أو المجموعات التي تنتمي إليها الكائنات ؛
- التحكم الإلزامي في الوصول (MAC) - يتضمن تقييد الوصول إلى موارد النظام استنادًا إلى أهمية البيانات (المعرّفة من قِبل الملصقات) الموجودة في هذه الموارد والسلطة الرسمية (أي الوصول) للمستخدمين للوصول إلى المعلومات ذات الأهمية المحددة ؛
- نموذج التحكم في الوصول المستند إلى الأدوار (RBAC) - يتضمن التحكم في الوصول إلى الموارد استنادًا إلى الأدوار التي تحدد الإجراءات المسموح بها مع الموارد ، ولا تستند إلى معرفات الموضوع ؛
- التحكم في الوصول المستند إلى السمة (ABAC) - يتضمن السماح أو رفض طلبات المستخدم بناءً على سمات المستخدم وسمات الكائن ، وكذلك العناصر البيئية التي يمكن تعريفها عالميًا وتكون أكثر صلةً بالسياسات المعمول بها.
C8: حماية البيانات في كل مكان
البيانات السرية مثل كلمات المرور وأرقام بطاقات الائتمان والسجلات الطبية والبيانات الشخصية والأسرار التجارية تتطلب حماية إضافية ، خاصةً إذا كانت خاضعة لقانون خصوصية البيانات ، مثل اللائحة العامة لحماية البيانات في الاتحاد الأوروبي (GDPR) ، أو قانون الحماية البيانات المالية ، مثل معيار أمان بيانات بطاقة الدفع (PCI DSS).
يمكن للمهاجمين سرقة البيانات من تطبيقات الويب وخدمات الويب بعدة طرق مختلفة. على سبيل المثال ، يمكن للمهاجم الاتصال بشبكة لاسلكية مشتركة وعرض أو سرقة البيانات السرية من المستخدمين الآخرين إذا تم إرسالها عبر اتصال إنترنت غير آمن. يمكن للمهاجم أيضًا استخدام حقن SQL لسرقة كلمات المرور وبيانات الاعتماد الأخرى من التطبيقات ، ثم وضعها في المجال العام.
تصنيف البيانات
تحتاج إلى تصنيف البيانات في نظامك وتحديد مستوى الأهمية لكل كتلة بيانات. يمكن عندئذ ربط كل فئة من فئات البيانات بقواعد الحماية المحددة لكل مستوى من مستويات الأهمية. على سبيل المثال ، قد تنسب معلومات التسويق العامة غير السرية إلى البيانات المتاحة للجمهور والتي يمكن نشرها على موقع ويب متاح للجمهور. يمكن أن تنسب أرقام بطاقات الائتمان إلى البيانات الشخصية للمستخدمين الذين يحتاجون إلى التشفير عند تخزينها أو نقلها.
تشفير الإرسال
عند نقل البيانات السرية عبر أي شبكة ، يجب تطبيق حماية الاتصال من طرف إلى طرف (أو التشفير). TLS هو بروتوكول التشفير الأكثر استخدامًا ودعمًا والذي يوفر اتصالات آمنة. يتم استخدامه في العديد من المناطق (تطبيقات الويب ، خدمات الويب ، تطبيقات الهاتف المحمول) لنقل البيانات بشكل آمن عبر الشبكة. لضمان أمان اتصالات TLS ، يجب عليك تكوينها بشكل صحيح.
تتمثل الفائدة الرئيسية لبروتوكول TLS في حماية بيانات تطبيق الويب من الوصول غير المصرح به والتغييرات أثناء النقل بين العملاء (متصفحات الويب) وخادم تطبيق الويب ، وكذلك بين خادم تطبيق الويب والخادم الداخلي أو غيره من المستعرضات ، مكونات المنظمة.
تشفير البيانات
القاعدة الأولى لإدارة البيانات الحساسة هي تجنب تخزين البيانات الحساسة كلما أمكن ذلك. إذا كنت بحاجة إلى حفظ البيانات السرية ، فتأكد من أنها تتمتع بحماية تشفير ضد الوصول والتغييرات غير المصرح بها.
يعد التشفير من أكثر مجالات أمن المعلومات تقدماً ؛ فهمه يتطلب معرفة وخبرة واسعة. من الصعب اختيار حل واحد ، نظرًا لوجود العديد من الطرق المختلفة للتشفير ، ولكل منها مزاياها وعيوبها ، التي يجب على مهندسي الويب ومطوري الويب فهمها بوضوح. علاوة على ذلك ، تعتمد أبحاث التشفير الجادة عادةً على نظرية أعلى للرياضيات والأرقام ، مما يخلق عتبة إدخال عالية.
C9: تنفيذ تسجيل الأحداث الأمنية ومراقبتها
يستخدم معظم المطورين بالفعل التسجيل للتصحيح والتشخيص. من المهم أيضًا تسجيل أحداث الأمان (البيانات المتعلقة بالأمان) أثناء تشغيل التطبيق. المراقبة عبارة عن تحليل مباشر لسجلات التطبيق والأمان باستخدام أدوات التشغيل الآلي المختلفة. يمكن تطبيق نفس الأدوات والقوالب على العمليات المستمرة والتصحيح والأمان.
فوائد تسجيل الأحداث الأمنية
يمكن استخدام سجلات أحداث الأمان من أجل:
- تزويد نظام الكشف عن الهجوم بالبيانات ؛
- تحليل والتحقيق في الحوادث ؛
- الامتثال للمتطلبات التنظيمية.
تطبيق تسجيل الأحداث الأمنية
فيما يلي توصيات لتطبيق تسجيل أحداث الأمان.
- استخدم النماذج والأساليب القياسية لتسجيل الأحداث في النظام وبين أنظمة مؤسستك. مثال على نظام أساسي لتسجيل الأحداث هو Apache Logging Services ، والذي يوفر توافق التسجيل بين تطبيقات Java و PHP و .NET و C ++.
- لا تسجل الكثير أو القليل من البيانات. على سبيل المثال ، تأكد من تسجيل الطوابع الزمنية وبيانات الاعتماد ، مثل عنوان IP المصدر ومعرف المستخدم ، ولكن لا تسجل أبدًا بيانات شخصية أو سرية.
- إيلاء اهتمام خاص لمزامنة الوقت بين العقد لضمان اتساق الطابع الزمني.
تسجيل للكشف عن الهجمات ومواجهتها
استخدم التسجيل لتحديد النشاط الذي يشير إلى سلوك المستخدم الضار. نشاط خطير محتمل يتم تسجيله:
- بيانات الإدخال خارج النطاق العددي المتوقع ؛
- تعدل بيانات الإدخال المكونات التي يجب أن تظل دون تغيير (قائمة الاختيار ، خانات الاختيار ، المكونات الأخرى ذات المدخلات المحدودة) ؛
- الطلبات التي تنتهك قواعد التحكم في الوصول من جانب الخادم ؛
- يمكن العثور هنا على قائمة أكثر تفصيلًا لعلامات الهجوم.
عندما يكتشف تطبيق ما هذا النشاط ، يجب أن يسجل هذا الحدث على الأقل ويصفه بأنه خطير. من الناحية المثالية ، يجب على التطبيق مواجهة الهجوم ، على سبيل المثال ، عن طريق إلغاء جلسة المستخدم وحظر حسابه. تسمح آلية التدابير المضادة للبرنامج بالرد على الهجمات القابلة للكشف في الوقت الفعلي.
C10: معالجة إلزامية لجميع الأخطاء والاستثناءات
تسمح معالجة الاستثناء للتطبيق بالاستجابة للأخطاء المختلفة (على سبيل المثال ، فشل الشبكة أو الاتصال بقاعدة بيانات) بطرق مختلفة. يعد التعامل الصحيح مع الاستثناءات والأخطاء ضروريًا لضمان موثوقية التعليمات البرمجية وأمانها.
تتم معالجة الأخطاء والاستثناءات على جميع مستويات التطبيق ، بما في ذلك منطق الأعمال الحاسم وميزات الأمان والأطر.من المهم معالجة الأخطاء أيضًا من حيث اكتشاف الهجمات. يمكن أن تتسبب بعض الهجمات على التطبيقات في حدوث أخطاء يمكنها اكتشاف أي هجوم في هذه العملية.معالجة خطأ غير صحيحة
وجد الباحثون في جامعة تورنتو أنه حتى وجود رقابة صغيرة عند معالجة الأخطاء أو تجاهلها يمكن أن يؤدي إلى أعطال حرجة في الأنظمة الموزعة .يمكن أن تتسبب معالجة الأخطاء غير الصحيحة في العديد من الثغرات الأمنية.- . . , , , . (, ) . , , , .
- TLS. Apple «goto fail» , TLS- Apple.
- . . . .
- , try/catch . .
- تأكد من أن رسائل الخطأ التي يتم عرضها لا تحتوي على بيانات مهمة ، ولكنها تحتوي على معلومات كافية للاستجابة بشكل مناسب.
- تأكد من تسجيل الاستثناءات بحيث يكون لدى الأشخاص في فريق الدعم الفني أو مراقبة الجودة أو التحقيق في الحوادث أو فريق الاستجابة بيانات كافية لحل المشكلة.
- اختبار والتحقق من رمز معالجة الأخطاء بعناية.
الخاتمة
يجب اعتبار هذه الوثيقة كنقطة انطلاق ، وليس كمجموعة شاملة من الأساليب والممارسات. مرة أخرى ، نريد أن نلاحظ أن المواد المقدمة تهدف إلى تعريفك بأساسيات تطوير البرمجيات الآمنة.عند إنشاء برنامج أمان للتطبيق ، يوصى بإكمال الخطوات التالية:
النسخة الكاملة للترجمة والنسخة الأصلية . شارك في الترجمة والتكيف: JZDLin و Alexey Skachkov و Ivan Kochurkin و Taras Ivashchenko .
تم إصدار هذه الوثيقة بموجب ترخيص Creative Commons Attribution ShareAlike 3.0 ، وتم ترجمتها وتكييفها بمشاركة الفرع الروسي لاتحاد OWASP .