تدقيق الكود

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

إرشادات

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

نقاط ضعف عالية الخطورة

قد توجد بعض نقاط الضعف الشائعة عالية الخطورة نتيجة استخدام:

  • الوظائف التي لا تتحقق من الحدود (مثل strcpy و sprintf و vsprintf و sscanf ) والتي يمكن أن تؤدي إلى ثغرة تجاوز سعة المخزن المؤقت [ 3 ].
  • التلاعب بالمؤشرات في المخازن المؤقتة التي قد تتداخل مع فحص الحدود اللاحقة، على سبيل المثال: if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;[ 3 ]
  • استدعاءات مثل execve ()، وأنابيب التنفيذ، و system() وما شابه ذلك، خاصة عند استدعائها باستخدام وسائط غير ثابتة [ 3 ]
  • التحقق من صحة المدخلات، على سبيل المثال (في لغة SQL): هو مثال على ثغرة حقن SQLstatement := "SELECT * FROM users WHERE name = '" + userName + "';"
  • وظائف تضمين الملفات، على سبيل المثال (في لغة PHP): include($page . '.php');هي مثال على ثغرة أمنية تتعلق بتضمين الملفات عن بُعد
  • بالنسبة للمكتبات التي قد تكون مرتبطة ببرمجيات خبيثة، يتم إرجاع مرجع إلى بنية البيانات الداخلية القابلة للتغيير (سجل، مصفوفة). قد تحاول البرمجيات الخبيثة تعديل البنية أو الاحتفاظ بالمرجع لمراقبة التغييرات المستقبلية.

نقاط ضعف منخفضة الخطورة

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

  • ثغرات أمنية في التعليمات البرمجية من جانب العميل لا تؤثر على جانب الخادم (مثل البرمجة النصية عبر المواقع )
  • تعداد أسماء المستخدمين
  • اجتياز الدليل
  • مفاتيح API الحساسة

أدوات

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

الاعتماد على المتطلبات

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

انظر أيضاً

مراجع

  1. "تدقيق شفرة المصدر - الأسئلة الشائعة" . مؤرشف من الأصل بتاريخ 10 فبراير 2009. تم الاطلاع عليه بتاريخ 12 فبراير 2008 .
  2. "تدقيق مجاني لرمز التطبيقات: ضمان نجاح تطبيقك على الهاتف المحمول" . تم الاطلاع عليه بتاريخ 12-06-2024 .
  3. 1 2 3 "إرشادات تدقيق شفرة المصدر بلغة C" . مؤرشفة من الأصل بتاريخ 28-03-2008 . تم الاطلاع عليها بتاريخ 12-02-2008 .
  4. " التحليل الثابت في نهاية دورة حياة تطوير البرمجيات لا يعمل " مؤرشف بتاريخ 15-10-2010 في Wayback Machine " بقلم واين أريولا، SearchSoftwareQuality.com، 22 سبتمبر 2008