البرمجة الدفاعية

الموسوعة الحرة

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

البرمجة الدفاعية هي منهجية لتحسين البرمجيات وشفرة المصدر ، من حيث:

  • الجودة العامة – تقليل عدد الأخطاء والمشاكل البرمجية .
  • جعل الكود المصدري قابلاً للفهم – يجب أن يكون الكود المصدري قابلاً للقراءة والفهم حتى يتم اعتماده في عملية تدقيق الكود .
  • جعل البرنامج يتصرف بطريقة يمكن التنبؤ بها على الرغم من المدخلات غير المتوقعة أو إجراءات المستخدم.

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

برمجة آمنة

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

int risky_programming ( char * input ) { char str [ 1000 ]; // ... strcpy ( str , input ); // نسخ المدخلات. // ... }

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

int secure_programming ( char * input ) { char str [ 1000 + 1 ]; // واحد إضافي للحرف الفارغ.// ...// نسخ المدخلات دون تجاوز طول الوجهة. strncpy ( str , input , sizeof ( str ));// إذا كان طول السلسلة المدخلة أكبر من أو يساوي حجم السلسلة النصية، فلن تُنهي الدالة strncpy السلسلة بحرف فارغ. // نتغلب على هذه المشكلة بتعيين الحرف الأخير في المخزن المؤقت إلى NUL دائمًا، // مما يؤدي فعليًا إلى اقتطاع السلسلة إلى أقصى طول يمكننا التعامل معه. // يمكن أيضًا إيقاف البرنامج صراحةً إذا كان طول السلسلة المدخلة طويلًا جدًا. str [ sizeof ( str ) - 1 ] = '\0' ;// ... }

البرمجة الهجومية

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

الثقة بصحة البيانات الداخلية

برمجة دفاعية مفرطة
const char * trafficlight_colorname ( enum traffic_light_color c ) { switch ( c ) { case TRAFFICLIGHT_RED : return "red" ; case TRAFFICLIGHT_YELLOW : return "yellow" ; case TRAFFICLIGHT_GREEN : return "green" ; } return "black" ; // يتم التعامل معها كإشارة مرور معطلة. }
البرمجة الهجومية
const char * trafficlight_colorname ( enum traffic_light_color c ) { switch ( c ) { case TRAFFICLIGHT_RED : return "red" ; case TRAFFICLIGHT_YELLOW : return "yellow" ; case TRAFFICLIGHT_GREEN : return "green" ; } assert ( 0 ); // التحقق من أن هذا القسم غير قابل للوصول. }

مكونات برمجية موثوقة

برمجة دفاعية مفرطة
إذا كان ( is_legacy_compatible ( user_config )) { // الاستراتيجية: لا تثق بأن الكود الجديد سيتصرف بنفس طريقة الكود القديم ( old_code ( user_config ); } else { // الخيار البديل: لا تثق بأن الكود الجديد سيتعامل مع نفس الحالات إذا ( new_code ( user_config ) != OK ) { old_code ( user_config ); } }
البرمجة الهجومية
// توقع ألا يحتوي الكود الجديد على أي أخطاء جديدة إذا ( new_code ( user_config ) != OK ) { // أبلغ بصوت عالٍ وأنهِ البرنامج فجأةً للحصول على الاهتمام اللازم report_error ( "حدث خطأ جسيم" ); exit ( -1 ); }

التقنيات

فيما يلي بعض تقنيات البرمجة الدفاعية:

إعادة استخدام ذكية لشفرة المصدر

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

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

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

مشاكل الإرث

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

مشاكل الإرث هي مشاكل متأصلة عندما يُتوقع من التصاميم القديمة أن تعمل مع متطلبات اليوم، خاصة عندما لم يتم تطوير التصاميم القديمة أو اختبارها مع وضع تلك المتطلبات في الاعتبار.

واجهت العديد من منتجات البرمجيات مشاكل مع شفرة المصدر القديمة؛ على سبيل المثال:

  • قد لا يكون الكود القديم قد تم تصميمه في إطار مبادرة برمجة دفاعية، وبالتالي قد يكون ذا جودة أقل بكثير من الكود المصدري المصمم حديثًا.
  • قد يكون الكود القديم قد كُتب واختُبر في ظروف لم تعد سارية. وقد لا تكون اختبارات ضمان الجودة القديمة صالحة بعد الآن.
    • مثال 1 : قد يكون الكود القديم مصممًا لإدخال ASCII ولكن الآن الإدخال هو UTF-8 .
    • المثال 2 : قد يكون الكود القديم قد تم تجميعه واختباره على معمارية 32 بت، ولكن عند تجميعه على معمارية 64 بت، قد تحدث مشاكل حسابية جديدة (مثل اختبارات الإشارة غير الصالحة، وتحويلات النوع غير الصالحة، وما إلى ذلك).
    • المثال 3 : قد يكون الكود القديم قد استهدف الأجهزة غير المتصلة بالإنترنت، ولكنه يصبح عرضة للاختراق بمجرد إضافة اتصال الشبكة.
  • لا تُكتب البرامج القديمة مع مراعاة المشاكل الجديدة. على سبيل المثال، من المرجح أن تكون البرامج المصدرية المكتوبة عام 1990 عرضة للعديد من ثغرات حقن التعليمات البرمجية ، لأن معظم هذه المشاكل لم تكن مفهومة على نطاق واسع في ذلك الوقت.

أمثلة بارزة على مشكلة الإرث:

  • BIND 9 ، الذي قدمه بول فيكسي وديفيد كونراد تحت عنوان "BINDv9 هو إعادة كتابة كاملة "، "كان الأمن أحد الاعتبارات الرئيسية في التصميم"، [ 2 ] مع تسمية الأمن والمتانة وقابلية التوسع والبروتوكولات الجديدة كاعتبارات رئيسية لإعادة كتابة التعليمات البرمجية القديمة.
  • عانى نظام التشغيل مايكروسوفت ويندوز من ثغرة أمنية في ملفات تعريف ويندوز (WMF) وغيرها من الثغرات المتعلقة بهذا التنسيق. ويصف مركز استجابة مايكروسوفت الأمنية ميزات WMF بأنها "أُضيفت دعم WMF حوالي عام 1990... كان ذلك زمنًا مختلفًا في مجال الأمن السيبراني... كانت جميعها موثوقة تمامًا" ، [ 3 ] ولم تكن تُطوَّر ضمن مبادرات الأمن السيبراني في مايكروسوفت.
  • تُكافح أوراكل مشاكل الأنظمة القديمة، مثل الشيفرة المصدرية القديمة التي كُتبت دون مراعاة مخاطر حقن SQL وتصعيد الصلاحيات ، مما أدى إلى العديد من الثغرات الأمنية التي استغرق إصلاحها وقتًا طويلاً، كما أنها لم تُسفر عن إصلاحات كاملة. وقد أثار هذا الأمر انتقادات حادة من خبراء الأمن مثل ديفيد ليتشفيلد ، وألكسندر كورنبرست ، وسيزار سيرودو . [ 4 ] [ 5 ] [ 6 ] ومن الانتقادات الأخرى أن عمليات التثبيت الافتراضية (التي تُعدّ في معظمها إرثًا من الإصدارات القديمة) لا تتوافق مع توصياتها الأمنية الخاصة، مثل قائمة التحقق الأمنية لقاعدة بيانات أوراكل ، والتي يصعب تعديلها لأن العديد من التطبيقات تتطلب الإعدادات القديمة الأقل أمانًا لتعمل بشكل صحيح.

التقنين

من المرجح أن يبتكر المستخدمون ذوو النوايا الخبيثة أنواعًا جديدة من تمثيلات البيانات غير الصحيحة. على سبيل المثال، إذا حاول برنامج ما رفض الوصول إلى الملف "/etc/ passwd "، فقد يمرر المخترق صيغة أخرى لهذا الملف، مثل "/etc/./passwd". يمكن استخدام مكتبات التوحيد القياسي لتجنب الأخطاء الناتجة عن المدخلات غير القياسية .

عدم التسامح مع الأخطاء "المحتملة"

افترض أن بنى البرمجيات التي تبدو عرضة للمشاكل (مثل الثغرات الأمنية المعروفة، وما إلى ذلك) هي أخطاء وثغرات أمنية محتملة. القاعدة الأساسية هي: "لستُ على دراية بجميع أنواع الثغرات الأمنية . يجب عليّ الحماية من تلك التي أعرفها ، ثم يجب أن أكون استباقيًا!".

طرق أخرى لتأمين التعليمات البرمجية

  • من أكثر المشاكل شيوعًا الاستخدام غير المُدقَّق لهياكل بيانات ذات حجم ثابت أو مُخصَّصة مُسبقًا لبيانات ذات حجم ديناميكي، مثل مُدخلات البرنامج ( مشكلة تجاوز سعة المخزن المؤقت ). ويشيع هذا الأمر بشكل خاص مع بيانات السلاسل النصية في لغة C. لا يُنصح باستخدام دوال مكتبة C مثل `const`، لأن الحد الأقصى لحجم المخزن المؤقت للإدخال لا يُمرَّر كوسيط. يمكن استخدام دوال مكتبة C مثل `const` بأمان، ولكن يتطلب ذلك من المبرمج توخي الحذر عند اختيار سلاسل التنسيق الآمنة، وذلك بتنظيفها قبل استخدامها.getsscanf
  • قم بتشفير/توثيق جميع البيانات المهمة المنقولة عبر الشبكات. لا تحاول تطبيق نظام تشفير خاص بك، بل استخدم نظامًا مُثبتًا وموثوقًا . كما أن التحقق من الرسائل باستخدام دالة تجزئة أو تقنية مشابهة يُساعد في تأمين البيانات المرسلة عبر الشبكة.

قواعد أمن البيانات الثلاث

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

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

جميع البيانات مهمة حتى يثبت العكس - وهذا يعني أنه يجب التحقق من جميع البيانات على أنها غير صالحة قبل إتلافها.

جميع البيانات ملوثة حتى يثبت العكس - وهذا يعني أنه يجب التعامل مع جميع البيانات بطريقة لا تكشف بقية بيئة التشغيل دون التحقق من سلامتها.

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

للمزيد من المعلومات

انظر أيضاً

مراجع

  1. ↑ بولانجر، جان لويس (2016-01-01)، "6 - تقنية لإدارة سلامة البرمجيات" ، في بولانجر، جان لويس (محرر)، تطبيقات البرمجيات القابلة للتصديق 1 ، إلسيفير، ص 125-156 ، ISBN  978-1-78548-117-8تم الاطلاع عليه بتاريخ 2022-09-02
  2. ↑ "أرشيف fogo: بول فيكسي وديفيد كونراد يتحدثان عن BINDv9 وأمن الإنترنت بقلم جيرالد أوسكوبويني" . موقع influence.net . تاريخ الاسترجاع: 27 أكتوبر 2018 .
  3. ↑ "بالنظر إلى قضية مؤسسة وول ستريت، كيف وصلت إلى هذه الحالة؟" . مركز أبحاث السوق . مؤرشف من الأصل بتاريخ 24 مارس 2006. تم الاطلاع عليه بتاريخ 27 أكتوبر 2018 .
  4. ↑ ليتشفيلد، ديفيد. "باغتراك: أوراكل، أين التحديثات؟؟؟" . seclists.org . تم الاطلاع عليه بتاريخ 27-10-2018 .
  5. ↑ ألكسندر، كورنبرست. "باغتراك: ردًا على: أوراكل، أين التصحيحات؟؟؟" . seclists.org . تم الاطلاع عليه بتاريخ 27-10-2018 .
  6. ↑ سيرودو، سيزار. "باغتراك: ردًا على: [ كشف كامل ] ردًا على: أوراكل، أين التصحيحات؟؟؟" . seclists.org . تم الاطلاع عليه بتاريخ 27-10-2018 .