تحليل البرامج

في علم الحاسوب ، يُعرَّف تحليل البرامج [ 1 ] بأنه عملية تحليل سلوك برامج الحاسوب فيما يتعلق بخصائص مثل الصحة، والمتانة، والأمان، والتشغيل المستمر. ويركز تحليل البرامج على مجالين رئيسيين: تحسين البرنامج وصحة البرنامج . يركز الأول على تحسين أداء البرنامج مع تقليل استهلاك الموارد، بينما يركز الثاني على ضمان قيام البرنامج بالوظيفة المرجوة منه.

يمكن إجراء تحليل البرنامج دون تنفيذ البرنامج ( تحليل البرنامج الثابت )، أو أثناء وقت التشغيل ( تحليل البرنامج الديناميكي )، أو مزيج من الاثنين.

تحليل البرامج الثابتة

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

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

تُعدّ التحسينات غير الصحيحة غير مرغوب فيها للغاية. لذا، في سياق تحسين البرامج، توجد استراتيجيتان رئيسيتان للتعامل مع التحليل غير القابل للحسم حسابيًا:

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

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

التحكم في التدفق

يهدف تحليل تدفق التحكم إلى الحصول على معلومات حول الدوال التي يمكن استدعاؤها في نقاط مختلفة أثناء تنفيذ البرنامج. تُمثَّل هذه المعلومات بمخطط تدفق التحكم (CFG)، حيث تمثل العقد تعليمات البرنامج، بينما تمثل الحواف مسار التحكم. ومن خلال تحديد كتل التعليمات البرمجية والحلقات، يُصبح مخطط تدفق التحكم نقطة انطلاق لتحسينات المُصرِّف.

تحليل تدفق البيانات

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

التفسير المجرد

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

أنظمة الكتابة

تربط أنظمة الأنواع أنواعًا معينة بالبرامج التي تستوفي متطلبات محددة. والغرض منها هو اختيار مجموعة فرعية من برامج لغة معينة تُعتبر صحيحة وفقًا لخاصية معينة.

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

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

أنظمة التأثير

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

التحقق من النموذج

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

تحليل البرامج الديناميكية

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

الاختبار

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

يراقب

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

تقسيم البرنامج

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

انظر أيضاً

مراجع

  1. نيلسون، ف.، نيلسون، هـ. ر.، وهانكين، س. (2015). مبادئ تحليل البرامج . سبرينغر.
  2. جوفانوفيتش، ن.، كرويجل، س.، وكيردا، إ. (مايو 2006). بيكسي: أداة تحليل ثابتة للكشف عن ثغرات تطبيقات الويب. في ندوة IEEE حول الأمن والخصوصية لعام 2006 (ص 6-). IEEE.

للمزيد من القراءة

  • شعار ويكيميديا ​​كومنزالوسائط المتعلقة بتحليل البرنامج على ويكيميديا ​​كومنز