ما اختبار الاختراق وما الذي لا يشمله
يقوم باختبار الاختراق مختص في الأمن السيبراني يملك إذنًا كتابيًا بمهاجمة هدف محدد. يبحث عن نقاط الضعف، ويحاول استغلالها ليُظهر أثرها الفعلي، ثم يكتب ما وجده. وقيمة الاختبار في الدليل: حين ترى كيف قرأ المهاجم بيانات عميل آخر، يصعب تجاهل المشكلة، وهذا أقوى أثرًا من سطر في تقرير أداة فحص.
ثلاثة أنشطة يختلط أمرها كثيرًا، ولكل منها سؤال مختلف يجيب عنه.
| النشاط | ما يفعله | ما قد يفوته |
|---|---|---|
| فحص الثغرات | أداة تفحص النظام الذي يعمل أو مكتباته بحثًا عن ثغرات معروفة وأخطاء إعداد شائعة. | منطق العمل، وكل ما يحتاج إلى حكم بشري، وسلاسل المشكلات الصغيرة. وينتج أيضًا إنذارات كاذبة. |
| اختبار الاختراق | مختص يجرّب التطبيق وهو يعمل، ويربط النتائج ببعضها ويحاول استغلالها. | مسارات الشيفرة التي لم يصل إليها المختبِر. والوقت محدود، فلا يكون الاختبار شاملًا. |
| مراجعة الشيفرة الآمنة | مراجع يقرأ الشيفرة المصدرية بدعم من أدوات التحليل الساكن. | مشكلات لا تظهر إلا في بيئة التشغيل، مثل إعدادات الخادم. |
تعمل هذه الأنشطة معًا بأفضل صورة. في مقال اختبار الاختراق مقابل فحص الثغرات تفصيل للمقارنة الأولى، وفي صفحة مراجعة الشيفرة الآمنة تفصيل للثالثة. وللتعريف المختصر راجع مدخل المسرد.
قلة النتائج في التقرير لا تثبت أن التطبيق آمن. هي تعني فقط أن المختبِر لم يجد منفذًا خلال الوقت والنطاق المتفق عليهما.
النطاق وقواعد الاختبار
قبل أن يبدأ الاختبار تتفقان، أنت والمختبِر، كتابةً على ما يجوز اختباره وكيف. وهذا يحمي الطرفين: فمهاجمة نظام دون إذن مخالفة قانونية في كثير من البلدان، واختبار النظام الخطأ قد يعطّل مستخدمين حقيقيين. ويسمّى هذا الاتفاق عادةً قواعد الاشتباك (Rules of Engagement). وينبغي أن يشمل:
- الأهداف: التطبيقات ونقاط API وإصدارات الجوال والبيئات وأدوار المستخدمين الداخلة في النطاق، وما هو خارجه صراحةً، مثل خدمات الأطراف الثالثة التي لا تملكها.
- البيئة: نسخة تجريبية تطابق بيئة الإنتاج هي الخيار الأسلم. واختبار الإنتاج ممكن بحذر وضمن حدود.
- التوقيت: نافذة الاختبار، وأي ساعات يجب أن يتوقف فيها.
- الأساليب: هل تُستثنى هجمات تعطيل الخدمة والهندسة الاجتماعية والوصول المادي؟ وهي تُستثنى عادةً في اختبار التطبيقات.
- التعامل مع البيانات: كيف تُخزَّن بيانات الاختبار وبيانات الدخول والنتائج، ومتى تُحذف.
- جهات الاتصال وشروط الإيقاف: من يتصل به المختبِر عند اكتشاف ثغرة حرجة أو عند حدوث عطل.
راجع أيضًا قواعد مزوّد الاستضافة والسحابة لديك، فكثير منها ينشر ما يجوز للعملاء اختباره على منصاته.
الصندوق الأسود والرمادي والأبيض
تصف هذه المصطلحات مقدار ما يعرفه المختبِر مسبقًا.
| النهج | ما يحصل عليه المختبِر | الأنسب لـ |
|---|---|---|
| الصندوق الأسود | العنوان العام فقط، كما يراه غريب من الخارج. | معرفة ما قد يجده مهاجم مجهول من الخارج. واقعي، لكن الوقت يذهب في الاستكشاف. |
| الصندوق الرمادي | حسابات اختبار لكل دور مستخدم، ووثائق API، وأحيانًا نظرة عامة على البنية. | معظم اختبارات التطبيقات. يذهب الوقت إلى المنطق المهم، مثل التحكم في الوصول بين المستخدمين. |
| الصندوق الأبيض | وصول كامل، بما فيه الشيفرة المصدرية ووثائق التصميم. | أعمق تغطية. والأفضل جمعه مع مراجعة الشيفرة. |
نقترح في معظم المنتجات الصندوق الرمادي. فحسابات الاختبار لمستخدم عادي ومدير ومستخدم من منظمة ثانية تتيح للمختبِر أن يتحقق هل يصل مستخدم إلى بيانات غيره، وهي من أكثر الثغرات الخطيرة شيوعًا في التطبيقات.
اختبار تطبيقات الويب وواجهات API وتطبيقات الجوال
تطبيقات الويب
يفحص المختبِرون المصادقة وإدارة الجلسات والتحكم في الوصول ومعالجة المدخلات (الحقن والبرمجة النصية عبر المواقع) ورفع الملفات ومنطق العمل وترويسات الأمان في المتصفح. ودليل OWASP لاختبار أمان الويب (WSTG) هو الفهرس المرجعي لحالات الاختبار. أما معيار OWASP للتحقق من أمان التطبيقات (ASVS) فيضع متطلبات التطبيق الآمن في ثلاثة مستويات من الصرامة. وقائمة OWASP لأخطر عشر ثغرات مفيدة للتوعية، لكنها ليست خطة اختبار.
واجهات API
تستحق واجهات API اختبارًا مستقلًا لأنها تكشف وظائف قد تخفيها الواجهة الرسومية. يفحص المختبِرون التفويض على مستوى كل كائن وكل وظيفة، وربط الحقول بالنموذج تلقائيًا (mass assignment)، وتحديد معدل الطلبات، والاستجابات التي تعيد بيانات أكثر مما تعرضه الشاشة. والمرجع الشائع هو قائمة OWASP لأخطر عشر ثغرات في واجهات API. أعطِ المختبِر مواصفات الواجهة، كملف OpenAPI، ليغطي كل نقطة.
تطبيقات الجوال
يغطي اختبار الجوال التطبيق على الجهاز وحركة بياناته مع الخلفية: بيانات مخزّنة على الهاتف بطريقة غير آمنة، وأسرار داخل حزمة التطبيق، وتحقق ضعيف من الشهادات، ومكوّنات مكشوفة. ويصف دليل OWASP لاختبار أمان تطبيقات الجوال (MASTG) الاختبارات، ويصف معيار التحقق من أمان تطبيقات الجوال (MASVS) المتطلبات. وتُختبر واجهة API الخلفية مع التطبيق.
وهناك أطر أوسع، مثل معيار تنفيذ اختبار الاختراق (PTES) ووثيقة NIST SP 800-115، تصف العملية كاملة من التخطيط إلى الاختبار إلى كتابة التقرير.
كيف تُكتب النتائج وتُرتَّب حسب الأولوية
التقرير الجيد من طبقتين: ملخص قصير يستطيع صاحب القرار غير التقني أن يتصرف بناءً عليه، وبند مفصّل لكل ثغرة. وينبغي أن يتضمن كل بند:
- عنوانًا واضحًا والمكوّن المتأثر.
- درجة الخطورة مع تعليلها، بناءً على الاحتمال والأثر، وغالبًا مع درجة CVSS.
- خطوات إعادة الإنتاج والأدلة، كالطلبات ولقطات الشاشة، ليرى المطوّر المشكلة بنفسه.
- الأثر بلغة واضحة.
- إصلاحًا محددًا موصى به.
يجب أن تعكس الخطورة حالة نظامك، لا مجرد درجة عامة. فضعف متوسط التصنيف في مسار الدفع قد يستحق استعجالًا أكثر من ضعف عالي التصنيف في صفحة لا يزورها أحد. والترتيب المعقول: الحرجة والعالية أولًا، ثم الإصلاحات السريعة، ثم الباقي ضمن العمل المعتاد. ويذكر التقرير الجيد أيضًا ما صمد جيدًا وما لم يُختبر.
إعادة الاختبار
الإصلاح مجرد ادعاء حتى يتحقق منه أحد. تكرر إعادة الاختبار خطوات كل ثغرة، ثم تصنفها: أُصلحت، أو أُصلحت جزئيًا، أو ما زالت مفتوحة. اتفقوا مسبقًا هل تشمل الخدمة إعادة الاختبار، وإلى متى بعد التقرير يمكن طلبها. وهي تكشف أيضًا إصلاحات تغلق مسارًا وتترك مسارًا مشابهًا مفتوحًا، كأن يُمنع الهجوم عبر حقل إدخال واحد وتبقى ثلاثة حقول أخرى بلا حماية.
كيف تستعد
- ثبّت النطاق: التطبيقات وأدوار المستخدمين والبيئات المطلوب اختبارها.
- جهّز بيئة تجريبية تطابق الإنتاج، وفيها بيانات واقعية غير حساسة.
- أنشئ حسابات اختبار لكل دور، منها حسابان في منظمتين منفصلتين إن كان منتجك يخدم عدة عملاء في نظام واحد.
- شارك الوثائق: مواصفات API ومخطط البنية وأي نموذج تهديدات سابق.
- حدّد من يجب أن يعلم بموعد الاختبار، كمزوّد الاستضافة وفريق المراقبة والدعم، حتى لا يظنه أحد هجومًا حقيقيًا.
- خذ نسخة احتياطية، وسمِّ شخصًا واحدًا يستطيع الرد أثناء الاختبار.
- أصلح المشكلات المعروفة أولًا، ليُصرف وقت المختبِر على ما لم تكتشفه بعد.
كم مرة تختبر
لا يوجد جدول واحد. من اللحظات الشائعة: قبل الإطلاق الأول، وبعد تغييرات كبيرة في البنية أو المصادقة أو مسارات الدفع، وبشكل دوري للأنظمة المهمة (كثير من الفرق تختار مرة في السنة)، وحين يطلب عميل أو شريك دليلًا، وبعد حادثة أمنية. وبين الاختبارات، تقلل عادات مثل فحص الاعتمادات ومراجعة الشيفرة ما سيجده الاختبار، فيذهب وقت المختبِر إلى المشكلات الأصعب. وإذا حدّد عقد أو معيار فترة للاختبار، فتأكد من المتطلب الدقيق لدى الجهة التي تحدده.
ماذا تسأل مزوّد الخدمة
- من سيجري الاختبار فعليًا، وما خبرته بتقنياتك ونوع تطبيقك؟
- أي منهجية يتبع: WSTG أو ASVS أو MASTG؟
- هل يمكنني الاطلاع على نموذج تقرير مجهول الهوية؟
- كيف يبلّغ عن ثغرة حرجة أثناء الاختبار بدل انتظار نهايته؟
- هل تشمل الخدمة إعادة الاختبار، ولأي مدة بعد التقرير؟
- كيف يتعامل مع بياناتك وبيانات الدخول وأي وصول يُمنح له، وكيف تُحذف بعد انتهاء العمل؟
- كيف يقلل المخاطر عند اختبار بيئة الإنتاج؟
- هل يختبر منطق العمل يدويًا، أم يكتفي بتشغيل أدوات الفحص؟
احذر من أي مزوّد يعد بإيجاد كل الثغرات، أو يقدّم عرض سعر دون أن يسأل عن النطاق.
في أسفاليا يبدأ كل مشروع بمراجعة للتهديدات، وتسبق الإطلاق مراجعة أمنية تسلّمك قائمة إصلاحات مرتبة حسب الأولوية. واختبار أمان تطبيقات الويب والجوال جزء من خدمة الأمن السيبراني لدينا. وإن كنا نحن من بنى منتجك، فقل لنا إن كنت تفضّل مختبِرًا مستقلًا آخر، فهذا طلب مشروع. ويمكن لأعمال قطر الاطلاع على صفحة الأمن السيبراني في قطر.