أساسيات اختبار الأمان
اختبار الأمان (Security Testing) يتحقق من أن النظام يحمي بياناته ووظائفه من سوء الاستخدام: فلا يرى المعلومات إلا من يحق له رؤيتها (السرّية)، ولا يغيّرها أحد دون صلاحية أو دون أثر (السلامة)، وتبقى الخدمة متاحة لمن يستحقها (التوافر). وبينما يسأل الاختبار الوظيفي «هل تعمل الميزة للمستخدم الشرعي؟»، يسأل اختبار الأمان «ماذا يحدث حين يحاول ذلك شخص لا ينبغي أن يقدر عليه؟».
في بوابة رواتب، يؤكد الاختبار الوظيفي أن الموظفة تستطيع تنزيل قسيمة راتبها. أما اختبارات الأمان فتؤكد أنها لا تستطيع تنزيل قسيمة زميلها بتغيير المعرّف في الرابط، وأن الحساب البنكي الذي حدّثته هو حسابها فعلاً عند تشغيل الرواتب، وأن البوابة تبقى تعمل يوم صرف الرواتب تحت سيل من محاولات الدخول الفاشلة. ويعدّ ISTQB اختبار الأمان نوعاً من الاختبار غير الوظيفي، يُقاس وفق خاصية الجودة التي يسميها ISO/IEC 25010 «الأمان».
لماذا يهم
العيب الوظيفي يكلّف عادةً مستخدماً واحداً مهمة واحدة. أما العيب الأمني فقد يكشف بيانات جميع المستخدمين دفعة واحدة، والمهاجم الذي يجده لا يكتب تقرير عيب. تأتي الكلفة لاحقاً على شكل اختراق وغرامة تنظيمية وعملاء مفقودين وإصلاح طارئ تحت الضغط، وهي عادةً أعلى بكثير من كلفة الاختبار الذي كان سيكشف الثغرة.
وبالنسبة إلى المختبِر، الأمان هو المجال الذي تثمر فيه عاداته المعتادة أكثر ما تثمر: التفكير في الحالات السلبية، وقراءة المتطلب بحثاً عمّا يمنعه، والتشكيك فيما يفترضه النظام. فكثير من العيوب الأمنية عيوب عادية، فحص ناقص أو إعداد افتراضي خاطئ أو رسالة خطأ مفصّلة أكثر من اللازم، يجدها المختبِر الذي يعرف عمّا يبحث دون أدوات خاصة. يمنحك هذا الدرس المفردات والقواعد الأساسية، وتبدأ الدروس التالية بـ OWASP Top 10 ثم تتناول المجالات الرئيسية، كالمصادقة والجلسات والتحكم في الوصول والحقن وغيرها، واحداً تلو الآخر.
ما يحميه الأمان: السرّية والسلامة والتوافر
يسهل اختبار متطلبات الأمان حين تسمّي أيّ الخصائص الثلاث يحميها كل متطلب. السرّية (Confidentiality): لا تظهر المعلومات إلا لمن له صلاحية رؤيتها. السلامة (Integrity): لا تتغيّر البيانات والوظائف إلا عبر فاعلين مخوَّلين ومسارات مخوَّلة، مع إمكانية تتبّع التغييرات. التوافر (Availability): الخدمة موجودة وبأداء مقبول حين يحتاجها المستخدمون الشرعيون. يسمّي أهل الأمان هذه الخصائص ثالوث CIA. ويذكر ISO/IEC 25010:2023 السرّية والسلامة ضمن الخصائص الفرعية للأمان، إلى جانب عدم الإنكار (Non-repudiation) والمساءلة (Accountability) والأصالة (Authenticity) والمقاومة (Resistance)، أي مواصلة العمل أثناء التعرض لهجوم، ويضع التوافر تحت الموثوقية (Reliability)، ولهذا تُجرى اختبارات التوافر غالباً مع أعمال الأداء.
تقترح كل خاصية أسئلة اختبار خاصة بها، والنتيجة المتوقعة لاختبار الأمان كثيراً ما تكون ألّا يحدث شيء: يُرفض الطلب، وتبقى البيانات دون تغيير، وتستمر الخدمة في العمل.
- السرّية: هل يستطيع زائر غير مسجّل، أو موظف آخر، أو دور أدنى قراءة قسيمة الراتب؟ هل تتسرّب القسيمة عبر رابط أو سجل أو ذاكرة مؤقتة أو رسالة خطأ؟
- السلامة: هل يمكن تغيير الحساب البنكي دون إعادة المصادقة، أو بطلب معدَّل، أو بطلب معاد إرساله؟ هل يُسجَّل كل تغيير مع من أجراه ومتى؟
- التوافر: ماذا يحدث لصفحة تسجيل الدخول تحت دفعة من المحاولات الفاشلة، أو حين يُرسل ملف بحجم 50 ميغابايت إلى نموذج «استفسار عن قسيمتي»؟ هل تُبطئ إساءةُ مستخدم واحد الجميعَ؟
التهديدات والثغرات والهجمات والمخاطر
خمس كلمات تدور حولها معظم أحاديث الأمان، ويخلط المختبِرون بينها. الأصل (Asset) هو ما يستحق الحماية: بيانات الرواتب، وتشغيل الرواتب، وسمعة الشركة. والتهديد (Threat) سبب محتمل لإلحاق ضرر بأصل، ويُسمّى عادةً بفاعله: موظف ساخط، أو جماعة إجرامية، أو روبوت آلي، أو مدير نظام أمين يرتكب خطأً. والثغرة (Vulnerability) ضعف يمكن أن يستغله تهديد: فحص تفويض ناقص، أو مكتبة قديمة، أو رابط إعادة تعيين كلمة مرور لا تنتهي صلاحيته، أو نسخة احتياطية متروكة في مجلد عام. والهجوم (Attack) محاولة لاستغلال ثغرة ضد أصل، والاستغلال (Exploit) هو التقنية أو الشيفرة التي تنفّذ ذلك. والخطر (Risk) يجمع احتمال نجاح الهجوم مع حجم الضرر الذي يسببه، وهو منطق الاحتمال والأثر نفسه الذي يقوم عليه الاختبار المبني على المخاطر.
ومن هذه التعريفات يتضح تقسيم العمل. فالمختبِر لا يستطيع إزالة التهديدات؛ الروبوتات موجودة سواء كانت البوابة ضعيفة أم لا. لكنه يجد الثغرات قبل أن يجدها المهاجم، ويبلّغ عنها بأدلة كافية ليحكم الفريق على الخطر. ومذكرة قصيرة كالتي أدناه، تُكتب عند بداية الميزة، تحوّل قلقاً غامضاً إلى شروط اختبار:
الأصل: قسائم الرواتب (PDF)
التهديد: موظف يقرأ قسيمة راتب زميله
الثغرة: رابط القسيمة يستخدم معرّفاً يسهل تخمينه ولا يفحص الملكية
شرط الاختبار: GET لمعرّف قسيمة مستخدم آخر بجلستي، والمتوقع 403 أو 404 ولا قسيمة
الأصل: رقم الحساب البنكي الذي يُصرف إليه الراتب
التهديد: مهاجم بجلسة مسروقة يحوّل الراتب إلى حساب آخر
الثغرة: يُحفظ التغيير دون إعادة المصادقة ودون إشعار
شرط الاختبار: غيّر الحساب، والمتوقع طلب إعادة المصادقة وإرسال إشعار وسجل تدقيق
الأصل: حسابات الموظفين
التهديد: روبوت يجرّب كلمات مرور مسرّبة
الثغرة: لا حدّ لعدد المحاولات، ونص الخطأ يكشف وجود اسم المستخدم
شرط الاختبار: دفعة من المحاولات الفاشلة، والمتوقع قفل أو تأخير، والرسالة نفسها لأي مستخدمجرّبها: مولّد سيناريوهات الاختبار جرّبها: مولّد الاختبارات السلبية
أربع طرق للنظر: SAST وDAST ومسح الثغرات واختبار الاختراق
يستخدم اختبار الأمان عدة مقاربات تنظر إلى النظام من جهات مختلفة. وكلٌّ منها يجد ثغرات تفوت غيرها، لذا تجمع الفرق الناضجة بينها، وينبغي للمختبِر أن يعرف أيّها كشف ماذا.
- الاختبار الساكن لأمان التطبيقات (SAST) يحلّل الشيفرة المصدرية أو المصرَّفة دون تشغيلها، كمراجع يقرأ كل سطر. يجد نقاط الضعف على مستوى الشيفرة مبكراً، كاستعلام SQL مبني بضمّ النصوص أو سرّ مكتوب داخل الشيفرة، ويشير إلى الملف والسطر. يعمل في محرّر المطوّر (IDE) وفي خط أنابيب CI، وكثيراً ما يبلّغ عن نتائج تتبيّن أنها إيجابيات كاذبة (false positives)، ولا يرى إعدادات التشغيل ولا كيفية نشر المكوّنات.
- الاختبار الديناميكي لأمان التطبيقات (DAST) يختبر التطبيق أثناء تشغيله من الخارج، كما يفعل المستخدم أو المهاجم، فيرسل الطلبات ويفحص الاستجابات. ويُطلق الاسم عادةً على أدوات آلية تزحف في التطبيق وترسل طلبات شبيهة بالهجمات، لكن المبدأ نفسه حين يؤديه المختبِر يدوياً. يجد ما هو مكشوف فعلاً: ترويسة أمان ناقصة، أو ملف تعريف ارتباط للجلسة (session cookie) بلا
HttpOnly، أو مدخلاً يعكس سكربتاً، أو نقطة نهاية تجيب دون رمز. يحتاج إلى بيئة اختبار منشورة وحسابات اختبار، ويفوته ما لا يصل إليه من الشيفرة، ولا يقول أيّ سطر يُصلح. ومعظم ما يفعله مختبِر الجودة يدوياً في المتصفح أو عميل API اختبارٌ ديناميكي بهذا المعنى. - مسح الثغرات (Vulnerability Scanning) يفحص ما هو مثبّت ومكشوف، من خوادم وأطر عمل ومكتبات ومنافذ مفتوحة وإعدادات TLS، بحثاً عن الثغرات المعروفة والإعدادات الخاطئة الشائعة. وتُنشر الثغرات المعروفة بمعرّفات CVE (Common Vulnerabilities and Exposures)، مثل CVE-2021-44228 لثغرة Log4j المعروفة باسم Log4Shell؛ وتحليل مكوّنات البرمجيات (SCA) يجري المطابقة نفسها لتبعيات التطبيق. المسح سريع وواسع وقابل للتكرار، وبوابة جيدة في خط الأنابيب، لكنه لا يعرف إلا الثغرات المعروفة سلفاً ولا يعرف شيئاً عن منطق عملك.
- اختبار الاختراق (Penetration Testing) محاكاة مصرَّح بها يقودها إنسان لهجوم ضمن نطاق ووقت متفق عليهما. يربط المختبِر بين النتائج، خطأ مفصّل مع سياسة كلمات مرور ضعيفة، ليبيّن ما يستطيع المهاجم الوصول إليه فعلاً. ويصفه NIST SP 800-115 في أربع مراحل: التخطيط والاستكشاف والهجوم والتقرير. يعطي أقوى الأدلة وأعمق تغطية لنظام واحد في لحظة واحدة، وهو الأغلى، لذا يُجدول غالباً قبل إصدار كبير أو مرة في السنة.
SASTساكن · الشيفرة
الاختبار الساكن لأمان التطبيقات
- ما ينظر إليه:
- الشيفرة المصدرية أو المصرَّفة دون تشغيلها
- ما يحتاجه:
- الشيفرة ومجموعة قواعد للغتها
- نتيجة نموذجية:
- استعلام SQL مبني بضمّ النصوص في الملف X، السطر 112
- حدوده:
- إعدادات التشغيل والنشر؛ وكثير من الإيجابيات الكاذبة
- متى ومن:
- بيئة التطوير وCI عند كل إيداع؛ المطورون يملكون النتائج
DASTديناميكي · التطبيق أثناء تشغيله
الاختبار الديناميكي لأمان التطبيقات
- ما ينظر إليه:
- التطبيق أثناء تشغيله، من الخارج، كما يفعل المهاجم
- ما يحتاجه:
- بيئة اختبار منشورة وحسابات اختبار
- نتيجة نموذجية:
- ملف جلسة بلا
HttpOnly؛ نقطة نهاية تجيب دون رمز - حدوده:
- الشيفرة التي لا يصل إليها؛ ولا يسمّي السطر الذي يُصلح
- متى ومن:
- كل نشر في بيئة الاختبار؛ مختبِرو الجودة وأدوات DAST
مسح الثغراتآلي · ثغرات معروفة
يطابق المكوّنات مع الثغرات المعروفة
- ما ينظر إليه:
- الخوادم وأطر العمل والمكتبات والمنافذ وإعدادات TLS المثبّتة
- ما يحتاجه:
- وصولاً إلى الشبكة أو قائمة التبعيات، وقاعدة ثغرات محدَّثة
- نتيجة نموذجية:
- نسخة إطار عمل لها CVE منشور؛ TLS 1.0 ما زال مفعّلاً
- حدوده:
- منطق العمل، والثغرات التي لم تسجّلها أي قاعدة بيانات بعد
- متى ومن:
- بوابة في خط الأنابيب وتشغيلات مجدولة؛ فريق المنصة أو الأمان
اختبار الاختراقيقوده إنسان · مصرَّح به
محاكاة هجوم مصرَّح بها تربط الثغرات بعضها ببعض
- ما ينظر إليه:
- النظام كله ضمن النطاق المتفق عليه، كما يفعل مهاجم ماهر
- ما يحتاجه:
- تصريحاً مكتوباً ونطاقاً ونافذة زمنية وخبيراً
- نتيجة نموذجية:
- خطأ مفصّل مع سياسة كلمات مرور ضعيفة يقودان إلى دور مدير الموارد البشرية
- حدوده:
- كل ما هو خارج النطاق، وكل ما أُضيف بعد الاختبار
- متى ومن:
- قبل إصدار كبير أو سنوياً؛ فريق متخصص أو مورّد
معظم ما يفعله مختبِر الجودة يدوياً في المتصفح أو عميل API اختبار ديناميكي.
مثال تطبيقي: أول جولة أمان على تسجيل الدخول في بوابة الرواتب
وُقّعت قواعد الاشتباك أعلاه؛ لديك بيئة الاختبار وثلاثة حسابات اختبار وفترة بعد الظهر. الجولة الأولى لا تحاول الاقتحام، بل تفحص الضوابط الأساسية خاصيةً خاصية وتسجّل الأدلة.
- السرّية: سجّل الدخول بحساب EMP-1001، وافتح قسيمتك، ولاحظ الرابط
/slips/48213.pdf، ثم اطلب/slips/48214.pdf، وهي قسيمة حساب الاختبار الآخر EMP-1002. المتوقع: 403 أو 404 دون قسيمة؛ سجّل رمز الحالة لا المحتوى. كرّر دون جلسة: المتوقع 401 أو إعادة توجيه إلى صفحة تسجيل الدخول. - الجلسة والإعداد: الصق ترويسات استجابة تسجيل الدخول في محلل ملفات تعريف الارتباط (Cookie Analyzer) ومحلل ترويسات الأمان (Security Header Analyzer). المتوقع: يحمل ملف تعريف ارتباط الجلسة
SecureوHttpOnlyوقيمةSameSite، وتوجدStrict-Transport-SecurityوContent-Security-PolicyوX-Content-Type-Options: nosniffوحماية من التضمين في الإطارات (X-Frame-Optionsأو التوجيهframe-ancestorsفي CSP)؛ وهذه الترويسات معاً تُلزم المتصفح باستخدام HTTPS فقط، وتحدّ من المصادر التي تُحمَّل منها السكربتات، وتمنعه من تخمين نوع المحتوى ومن عرض الصفحة داخل إطار في موقع آخر. كل عنصر ناقص نتيجة تُرفق بها الاستجابة بالضبط. - السلامة: بحساب EMP-1001 غيّر الحساب البنكي. المتوقع: تطلب البوابة كلمة المرور أو رمزاً لمرة واحدة مجدداً، وتُشعر الموظف، وتكتب سجل تدقيق. ثم تحقّق من أن أحداً غيره لا يستطيع إجراء هذا التغيير: أرسل طلب التغيير نفسه لحساب EMP-1001 برمز EMP-1002، من عميل API أو من مختبِر مصادقة API (API Authentication Tester). المتوقع: 403 أو 404، وحساب EMP-1001 دون تغيير حين تتحقق منه مجدداً. تفترض الأداة أن الرمز الذي تُدخله ينبغي قبوله، فتَعُدّ هذا الرفض فشلاً؛ لكن الرفض هنا هو النتيجة المطلوبة تماماً، أما صفوفها التي لا تحمل رمزاً صالحاً للاستخدام فيُتوقع أن تتلقى 401.
- المصادقة والتوافر: أدخل كلمة مرور خاطئة لحساب EMP-1002 خمس عشرة مرة. المتوقع: قفل الحساب أو تأخير متزايد بعد العدد المتفق عليه من المحاولات، ونص الخطأ نفسه لكلمة المرور الخاطئة وللمستخدم غير الموجود، حتى لا يكشف تسجيل الدخول أسماء المستخدمين الموجودة. وفي الأثناء يظل EMP-1001 قادراً على تسجيل الدخول كالمعتاد: فلا يجوز أن تُقفل المحاولاتُ الفاشلة لحساب واحد الخدمةَ على الجميع.
جرّبها: محلّل ترويسات الأمان جرّبها: محلّل ملفات تعريف الارتباط (Cookies) جرّبها: مختبِر مصادقة API
أخطاء شائعة
- اعتبار الأمان مهمة مختبِر الاختراق وحده، فلا يُفحص شيء حتى الاختبار السنوي، وتصل كل النتائج قبل الإصدار بأسبوع.
- الاختبار بمستخدم شرعي وبيانات صالحة فقط؛ فالعيوب الأمنية تسكن مسارات المستخدم الخطأ والرمز الناقص والطلب المعدَّل.
- الخلط بين التهديد والثغرة: «قد يسرق أحدهم كلمات المرور» تهديد لا يمكن اختباره؛ أما «رابط إعادة التعيين لا تنتهي صلاحيته» فثغرة يمكن اختبارها.
- تشغيل ماسح، ثم تسجيل نتائجه المئة دون قراءتها واعتبار المنتج مختبَراً؛ فمخرجات الماسح تحتاج إلى فرز، ولا تقول شيئاً عن منطق العمل.
- اختبار نظام أو بيئة أو خدمة طرف ثالث لم يذكرها التصريح المكتوب، لمجرد أنه كان يمكن الوصول إليها.
- لصق بيانات شخصية حقيقية أو رمز جلسة حيّ في تذكرة أو دردشة أو أداة على الإنترنت أثناء توثيق نتيجة.
من منظور ضمان الجودة
في الفريق الحقيقي يبدأ اختبار الأمان في جلسة تنقيح القصص: لكل قصة تمس تسجيل الدخول أو الأدوار أو المال أو البيانات الشخصية أو رفع الملفات أو تكاملاً خارجياً، اسأل عمّا تمنعه القصة كما تسأل عمّا تسمح به، واكتب ذلك معايير قبول سلبية. اسأل المطورين أيّ ماسحات SAST وتبعيات تعمل في خط الأنابيب ومن يفرز نتائجها؛ واسأل مالك المنتج من يعتمد نطاق الأمان في خطة الاختبار، ومتى كان آخر اختبار اختراق وماذا وجد.
سجّل النتائج الأمنية عيوباً عادية مع حقلين إضافيين: الخاصية المتأثرة (السرّية أو السلامة أو التوافر) والدليل (الطلب والاستجابة بالضبط مع حجب الأسرار). قدّر الخطورة بحسب الأثر، وسجّل مدى سهولة الوصول إلى الثغرة، لأن فرق الأمان تزن الاثنين معاً حين ترتّب النتائج. وأبقِ التذكرة مقيّدة الوصول، وبعد الإصلاح أجرِ اختبار التأكيد بالطلب نفسه، ثم اختبارات الانحدار على المواضع المجاورة التي قد يكون الإصلاح أغفلها، مثل الفحص نفسه على API كما على صفحة الويب.
تمرين عملي
صنّف قائمة مخاوف إلى تهديدات وثغرات وشروط اختبار
أرسل إليك مالك منتج بوابة الرواتب القائمة أدناه بعد جلسة توعية أمنية. قرّر لكل سطر هل يسمّي تهديداً أم ثغرة أم أصلاً، واكتب شرط اختبار واحداً لكل ثغرة مع خاصية CIA التي يحميها، وحدّد أيّ البنود يمكنك اختبارها بنفسك في بيئة الاختبار وفق قواعد الاشتباك الواردة في الدرس، وأيّها من اختصاص الماسح أو مختبِر الاختراق.
1. قد يبيع مخترقون رواتب موظفينا.
2. تصدير PDF يضع رقم الموظف في اسم الملف، والمجلد عام.
3. رابط «نسيت كلمة المرور» المرسل بالبريد الإلكتروني يظل يعمل بعد استخدامه مرة.
4. تعمل البوابة بنسخة من إطار عمل ويب عمرها ثلاث سنوات.
5. بيانات رواتب 1200 موظف.
6. قد يُخدع مدير النظام فيعتمد تغييراً مزيفاً لحساب بنكي.
7. صفحات الخطأ تطبع تتبّع المكدس (stack trace) كاملاً، بما فيه اسم قاعدة البيانات.- صنّف كل سطر: أصل أو تهديد أو ثغرة.
- اكتب لكل ثغرة شرط اختبار مع نتيجة متوقعة.
- ضع على كل شرط اختبار وسم السرّية أو السلامة أو التوافر.
- قرّر: في نطاقك، أم للماسح، أم لمختبِر الاختراق.
إظهار الإجابة النموذجية
السطر 1 تهديد (الفاعل: مجرمون، الهدف: بيع البيانات) والسطر 5 هو الأصل الذي يستهدفه؛ ولا يمكن اختبار أيّ منهما وحده. والسطر 6 تهديد أيضاً (هندسة اجتماعية تستهدف مدير النظام)، لكنه يشير إلى ثغرة يمكنك اختبارها: تغيير حساب بنكي يسري دون فحص ثانٍ.
السطر 2، ثغرة، السرّية: اطلب ملف التصدير لرقم موظف آخر دون جلسة، ثم بجلسة مستخدم اختبار آخر؛ المتوقع 401 أو 403 أو 404 ولا ملف. في نطاقك.
السطر 3، ثغرة، سلامة الحساب: استخدم رابط إعادة التعيين ثم افتحه مرة أخرى؛ المتوقع خطأ ولا إعادة تعيين ثانية. في نطاقك بحساب اختبار.
السطر 4، ثغرة إن كانت لتلك النسخة ثغرات معروفة، وقد تمس الخصائص الثلاث: مطابقة نسخة إطار العمل مع الثغرات المعروفة مهمة الماسح. شرط الاختبار: لا يُبلغ فحص التبعيات في خط الأنابيب عن أي ثغرة معروفة غير معالجة لهذا الإطار فوق الخطورة المتفق عليها؛ وأنت تتأكد من أن المسح يعمل وأن لنتائجه مالكين.
السطر 6، الثغرة الكامنة وراء التهديد، السلامة: أدخل بحساب HR-ADMIN-01 تغييراً للحساب البنكي لـ EMP-1002 وتحقق من أنه يبقى معلّقاً حتى يجتاز فحصاً ثانياً، كتأكيد الموظف من جلسته الخاصة أو موافقة معتمِد ثانٍ؛ المتوقع: لا يتغير حساب الصرف قبل ذلك، ويُبلَّغ الموظف، ويُكتب سجل تدقيق. في نطاقك؛ أما خداع مدير حقيقي فعلاً فهندسة اجتماعية تمنعها قواعد الاشتباك.
السطر 7، ثغرة، سرّية الإعدادات: تسبّب في خطأ بطلب معرّف غير صالح؛ المتوقع صفحة خطأ عامة والتفاصيل في سجل الخادم فقط. في نطاقك؛ أما هل يتيح تتبّع المكدس للمهاجم التقدم أبعد، فسؤال لمختبِر الاختراق.
أسئلة شائعة
هل اختبار الأمان وظيفي أم غير وظيفي؟
يصنّفه ISTQB اختباراً غير وظيفي يقيّم خاصية الأمان في ISO/IEC 25010. وعملياً تبدو كثير من اختبارات الأمان تماماً كالاختبارات الوظيفية السلبية، طلب من المستخدم الخطأ ونتيجة متوقعة 403، فالتصنيف يغيّر من يخطط للاختبار لا كيف تكتبه.
هل أحتاج إلى أن أكون مخترقاً أو أن أعرف البرمجة؟
لا. معظم العيوب الأمنية التي يجدها مختبِر الجودة، من فحوص تفويض ناقصة وملفات تعريف ارتباط ضعيفة للجلسة وأخطاء مفصّلة وترويسات ناقصة، تحتاج إلى عميل API ومتصفح وعادةِ تجربة المسار الممنوع. وتساعد قراءة الشيفرة في نتائج SAST، أما مهارات الاستغلال فمن اختصاص مختبِري الاختراق.
هل يمكنني التدرب على موقع عام لا أملكه؟
لا، إلا إذا كان ينشر برنامج مكافآت ثغرات أو سياسة إفصاح مسؤول تسمح بذلك صراحةً، وعندها ضمن تلك السياسة فقط. تدرّب على بيئة اختبارك، أو على تطبيقات تدريبية ضعيفة عمداً تثبّتها بنفسك، أو على أدوات مُتقن بترويسات ورموز حسابات اختبار منسوخة من أنظمة مصرَّح لك باختبارها، لا برمز حيّ لمستخدم حقيقي أبداً.
ما الفرق بين مسح الثغرات واختبار الاختراق؟
المسح آلي وواسع: يطابق النسخ والإعدادات مع الثغرات المعروفة ويعمل على كل بناء. واختبار الاختراق يدوي ومحدد النطاق وعميق: يحاول شخص الوصول إلى شيء ثمين بالجمع بين الثغرات، بما فيها ما لا تذكره أي قاعدة بيانات، ويبلّغ عمّا وصل إليه. يحتاج الفريق إلى الاثنين؛ فالمسح لا يحل محل الاختبار، والاختبار لا يُجرى كل يوم.
المراجع
- OWASP Web Security Testing Guide (WSTG)المنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessmentكيف تُخطَّط تقييمات الأمان وتُنفَّذ: المراجعة وتحديد الأهداف والتحقق من الثغرات وإعداد التقارير.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelنموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
تدرّب بأدوات متقن
تقييم ترويسات أمان HTTP (CSP وHSTS وX-Frame-Options وReferrer-Policy وPermissions-Policy وCOOP/CORP) من ترويسات ملصقة أو عنوان URL عام.
تحليل ترويسات Set-Cookie والتحقق من أفضل الممارسات في Secure وHttpOnly وSameSite وDomain وPath وانتهاء الصلاحية والحجم.
اختبر مصادقة Bearer وBasic ومفتاح API والترويسات المخصّصة على نقطة نهاية وقارن الاستجابات المصرّح بها بغير المصرّح بها.
ولّد سيناريوهات اختبار عالية المستوى تغطي الجوانب الوظيفية والسلبية والأمنية وسهولة الاستخدام والتوافق لأي ميزة.
ولّد حالات اختبار سلبية لحقول النماذج وواجهات API: قيم فارغة وnull ونوع خاطئ وطول زائد وحقن وصيغة غير صالحة.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.