سنطلب اختبار اختراق لتطبيق ويب لكننا نريد التحضير أولاً — هل هناك قائمة تحقق نطبقها بأنفسنا؟

في العام الماضي أجرينا اختباراً لبرنامج B2B مشابه ودفعنا 5.000 جنيه إسترليني. لأننا لم نجرِ تحضيراً مسبقاً، كان 14 من أصل 22 نتيجة في التقرير مجرد ترويسات HTTP ناقصة وردود خادم افتراضية. ندمنا كثيراً عندما رأينا أن المستشار أنفق ما لا يقل عن 1.500 جنيه إسترليني من وقته في الإبلاغ عن هذه الأشياء البسيطة.

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

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

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

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

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

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

أكيد سجّل عنوان الـ IP كاستثناء في جدار الحماية. في اختبار الاختراق عندنا حُجب الخبير تماماً في اليوم الأول، وأرسلوا إيميلات نصف يوم لفتح الـ IP وراحت الفلوس على الفاضي.

أوافق.

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

كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر. مثبت بالتجربة.

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

دعوني ألخص ما قيل حتى الآن. تقرير الفحص الآلي ليس نفس اختبار الاختراق.

بالتوفيق.

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

حدث معنا هذا... إذا لم تقم بصياغة هذا كتابيًا من البداية، فستنشأ خلافات لاحقًا.

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

لدي رأي مختلف. عندما نتخذ قرارات دون قياس، نعود لنفس النقطة دائماً.

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

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

اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

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

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