سيتم إجراء اختبار اختراق لموقعنا الحي — كيف نكتب خطة فحص لتجنب مخاطر التوقف؟

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

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

قبل سنتين عملنا فحص على الموقع الحي، وأثناء بحث خبير الاختبار عن SQL Injection أرسل استعلاماً يحتوي على أمر انتظار (sleep). خلال 3 دقائق استُنزف تجمع اتصالات قاعدة البيانات بالكامل وتوقفت شاشات الدفع عن العمل وأعطت أخطاء لمدة 20 دقيقة. وجود مهندس devops مناوب أمر لا بد منه.

نحن جعلنا الفحص بين 02:00 و 06:00 فجراً. في موقع يستقبل 1000 طلب يومياً تنخفض الطلبات ليلاً إلى 15 طلباً فقط. وفي حال حدوث أي تجمد تكون تكلفة خسارة العملاء شبه معدومة، إياك أن تجري فحصاً حياً أثناء ساعات العمل الرسمية.

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

لازم تحطوا رقم جوال وحيد للمسؤول بخطة الفحص وأول ما تحسوا بشي غريب يتصل الشخص اللي عم يعمل الـ pentest على هالرقم ومباشرة يوقف الأدوات مع أمر التوقف.

عدم القدرة على مطابقة بيئة الـ live مع الـ staging وعمل pentest ع الـ live وكأنه stress test هي مغامرة عجيبة خاصة بمجالنا. على الأقل خذوا نسخة احتياطية كاملة قبل الفحص بساعة عشان ما تصحوا الصبح على كارثة.

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

عشنا تقريباً نفس التجربة العام الماضي. انظروا أولاً إلى البيانات المتاحة لديكم عند اتخاذ القرار.

مثبت بالتجربة.

هناك ثلاثة أمور يجب مراعاتها أثناء القيام بذلك. المسألة ليست الرقم، بل الأساس الذي بُني عليه.

فعل الجميع لشيء ما لا يعني أنه صحيح. لو كنت مكانك، لسلك هذا المسار.

أوافق.

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

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

أتابع الموضوع.

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

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

بالضبط، بل إن هذا الجانب غير معروف بشكل كافٍ. محاولة فعل هذا بمفردك هي أغلى الطرق.

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

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

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

دعني أتركها كملاحظة، قد تكون مفيدة.

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

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