كيفية استخدام التحليل الثابت بشكل صحيح

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

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

حول التحليل الثابت

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

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

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

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

قم بإجراء التحليل

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


يسلم المطور رمز المصدر للاختبار

يتم إيلاء اهتمام خاص لمتطلبات كود البناء. تتطلب معظم المحللين لعدد من اللغات أن يتم جمع الكود أثناء التحليل (لغات JVM - Java ، Scala ، Kotlin وما شابه ، C / C ++ ، Objective-C ، C #). أنت تدرك كم هو مؤلم: إعادة إنتاج بيئة مشروع كبير للتجميع على جهاز جديد. من ناحية أخرى ، فإن هذه المتطلبات لها ما يبررها ؛ فهي تتبع من تقنيات التحليل وخصائص هذه اللغات.

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

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

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

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

عملية التحليل

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


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

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

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

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

نتائج التحليل

دعنا ننتقل إلى نتائج الفحص (لفترة طويلة ذهبنا إليها). أنت تنتظر عدد نقاط الضعف في نافذة المحلل مع الخوف ، وأنت مندهش للغاية لرؤيته. 156 حرجة و 1260 متوسطة و 3210 منخفضة. تذهب إلى صفحة النتائج وتغرق في عدد المشاكل التي تم العثور عليها. تقوم بتنزيل تقرير pdf وترى عدة آلاف من الصفحات النصية. خمن ما سيقوله مطور الشفرة عندما يرى مثل هذه اللوحة؟


ينقل حارس الأمن تقرير الثغرات إلى المطور

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

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

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

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

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

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

تحقق من المحلل

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


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

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

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

الكفاءات

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

الاندماج في عملية التنمية

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

يجب أن تحتوي الأداة على واجهة غير رسومية كاملة (على سبيل المثال ، CLI أو REST API) ، والتي يمكنك من خلالها دمج المحلل في أي من عملياتك. من الجيد إذا كان المحلل لديه تكاملات جاهزة مع مكونات متنوعة: المكونات الإضافية لـ IDEs أو أنظمة البناء ، أو التكامل مع أنظمة التحكم في الإصدار ، أو المكونات الإضافية لخوادم CI / CD (Jenkins ، TeamCity) ، أو التكامل مع أنظمة إدارة المشروع (JIRA) أو العمل مع المستخدمين ( Active Directory).

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

الملخص

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