سنستلم أول تقرير اختبار اختراق (pentest) لنا، ما الذي يجب أن يحتويه التقرير الجيد وإلامَ ننتبه؟

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

عندما يصل التقرير إلى طاولتكم، تحققوا من هذه النقاط الثلاث: 1) هل تم الخروج عن النطاق أم تم فحص جميع النطاقات الفرعية المذكورة في العقد؟ 2) هل يمكن إعادة تمثيل خطوات الثغرة خطوة بخطوة لكل نتيجة؟ 3) هل صيغت مقترحات الحلول بما يتوافق مع نظام التشغيل والمكتبات البرمجية التي تستخدمونها؟

تعديل: كتبت خطأً أعلاه، أرجو المعذرة.

في أول اختبار دفعنا لصالحه 5.200 Euro في باريس، خرج التقرير بـ 48 ثغرة. وعندما فحصناه، وجدنا أن 22 منها لم تكن سوى إعلانات إصدارات غير مهمة في الخادم. اعترضنا وصفينا التقرير، وركزنا على الـ 6 ثغرات الحرجة المتبقية. القيمة ليست بعدد صفحات التقرير، بل بعدد الثغرات الحرجة التي تم فرزها والتحقق منها.

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

في أول تقرير أصبنا بالذعر عندما رأينا صفحات مليئة بتحذيرات ssl، واتضح لاحقاً أن الفاحص التلقائي قام بتوليدها تلقائياً. الخبير لم يجرب حتى api injection واحدة يدوياً. نصيحتي لكم أن ترفضوا فوراً أي تقرير يخلو من لقطات الشاشة والـ payloads.

ملاحظة: كتبت هذا بناءً على تجربتي الشخصية، قد لا ينطبق على الجميع.

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

معظم الشركات تضع تقرير الـ pentest على الرف فور استلامه. النقطة الحاسمة بقدر جودة التقرير هي ما إذا كان يتضمن حق إجراء فحص ثانٍ (re-test) بعد الإصلاح. إن لم يكن الفحص اللاحق مشمولاً، فسيظل التقرير مجرد وثيقة مكلفة تسجل ما حدث في الماضي فقط.

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

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

ظهرت ثلاث وجهات نظر مختلفة، وكلها تكمل بعضها. تقرير الفحص الآلي ليس نفس اختبار الاختراق.

أتمنى أن يفيدك هذا.

إذا كنت ستسلك هذا المسار، فحل هذه المشكلة من البداية. لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً.

بالتوفيق.

هذا العنوان مؤرشف.

أخذت ملاحظة، شكرًا لك.

أنت محق، لقد مررت بنفس المسار. فعل الجميع لشيء ما لا يعني أنه صحيح.

صححوا لي إن أخطأت.

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

الإجابة تختلف كثيراً حسب القطاع، لا توجد قاعدة عامة... طيب بالتوفيق.

أنت محق.

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

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

موضوع في الوقت المناسب تمامًا.

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

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