اختبار أمان الويب عملياً

لماذا يهم

الشيفرة المتقنة يُبطلها بسهولة أسلوب نشرها وما بُنيت منه. فصفحة تصحيح تُركت مفعّلة، أو حساب مدير افتراضي، أو مكتبة قديمة لها ثغرة منشورة، تفتح باباً دون خطأ برمجي واحد في الميزة التي اختبرتها. وكلا الأمرين من فئات OWASP Top 10:2025: سوء الإعداد الأمني (A02:2025) وإخفاقات سلسلة توريد البرمجيات (A03:2025)، وكلاهما يسهل كشفه بالأدوات الآلية التي يوجّهها المهاجمون إلى المواقع العامة.

أما للمختبِر فسير العمل يجعل عمله آمناً وقابلاً للدفاع عنه: يُتفق على النطاق والبيئة وحسابات الاختبار وقناة الإبلاغ قبل أول طلب، وبعد ذلك تستطيع أن تبيّن ما اختُبر وكيف وما تُرك عمداً.

سير العمل: سبع خطوات بترتيب ثابت

الإذن قبل أي طلب، والفحوص منخفضة الأثر قبل النشطة، والتحقق قبل الإبلاغ. ودليل OWASP WSTG هو قائمة الفحص خلف الخطوات: اختبارات مجمّعة حسب المجال، لكل منها معرّف مثل WSTG-CONF-06 وأهداف وإرشادات للمعالجة. اختر المجالات التي تناسب مخاطر المنتج، وعلّم كل اختبار: منجز، أو لا ينطبق، أو ملاحظة، واذكر المعرّف في التقرير.

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

• 1. النطاق والإذن: المضيفون ونافذة الاختبار والإجراءات المستثناة وجهة اتصال للطوارئ وقناة الملاحظات، كتابةً.
• 2. الخريطة عبر الوكيل: الصفحات والأدوار ونقاط نهاية API ورفع الملفات والسكربتات الخارجية، وحساب اختبار لكل دور.
• 3. الجولة السلبية: إعادة التوجيه إلى HTTPS، وHSTS، وTLS ⁦1.2⁩ أو ⁦1.3⁩، وترويسات الأمان وسمات ملفات تعريف الارتباط على كل نوع من الصفحات.
• 4. فحوص الإعداد: الحسابات الافتراضية، ومخرجات التصحيح، والأخطاء، وعرض محتويات المجلدات، وطرق HTTP، ومسارات الإدارة.
• 5. المكوّنات: افرز فحص الاعتماديات وقائمة مكوّنات البرمجيات (SBOM) للبناء المختبَر.
• 6. الماسح والاختبارات اليدوية: فحص DAST نشط، وقد ينشئ سجلات ويرسل رسائل بريد، حيث يسمح النطاق فقط؛ واختبارات WSTG يدوية للتحكم في الوصول ومنطق الأعمال وCSRF، وهي ما لا تستطيع الماسحات الحكم عليه بموثوقية.
• 7. التحقق والربط والإبلاغ وإعادة الاختبار: أعد إنتاج كل خيط يدوياً، وسمِّ فئته في Top 10، وارفعه في القناة الخاصة، وأعد الاختبار بعد الإصلاح.

جرّبها: فاحص إعادة التوجيه جرّبها: محلّل ترويسات الأمان جرّبها: محلّل ملفات تعريف الارتباط (Cookies)

سوء الإعداد الأمني والفشل الآمن

سوء الإعداد (Misconfiguration) ضعف في طريقة ضبط البرمجيات لا في طريقة كتابتها: إعداد افتراضي لإطار العمل، أو ميزة لم يعطّلها أحد، أو إعداد نُسخ من بيئة التطوير. وكل فحص هنا طلب عادي مع قراءة متأنية للاستجابة.

والفشل الآمن هو النصف الآخر. ففئة A10:2025 سوء التعامل مع الحالات الاستثنائية (Mishandling of Exceptional Conditions) تشمل الاستثناءات غير المعالَجة، والفحوص التي تفشل مفتوحة (Fail Open) أي تمنح الوصول لأن خدمة الصلاحيات تجاوزت المهلة، والعمليات التي تبقى نصف منجزة. استدعِ الحالة بأمان، بقيمة مشوَّهة أو ببديل (Stub) لاعتمادية يتجاوز المهلة على بيئة الاختبار، وتحقق من أن الطلب رُفض، وأن الرسالة عامة، وأنه لم يبقَ سجل جزئي.

• الحسابات الافتراضية (WSTG-ATHN-02): جرّب فقط بيانات الاعتماد الافتراضية الموثّقة لدى المورّد على كل لوحة وجدتها الخريطة، ومحاولات قليلة على الأكثر. المتوقع: الرفض.
• أوضاع التصحيح (Debug Mode): صفحات التصحيح وأشرطة أدواته، وخرائط المصدر (Source Maps)، ونقاط النهاية المخصصة للاختبار. تأكد على النسخة المرشّحة للإصدار أن إعداد الإصدار يعطّلها.
• تتبّعات المكدس والأخطاء المفصّلة (WSTG-ERRH-01): أرسل نوعاً خاطئاً (/api/orders/abc)، أو حقلاً ناقصاً، أو قيمة طويلة جداً. المتوقع: رمز حالة من فئة ⁦4xx⁩ ورسالة قصيرة برقم مرجعي؛ لا تتبّع مكدس ولا SQL ولا مسارات ملفات ولا إصدارات.
• عرض محتويات المجلد (Directory Listing): اطلب مجلدات مثل /static/. المتوقع: ⁦403⁩ أو ⁦404⁩، لا صفحة «Index of».
• طرق HTTP (WSTG-CONF-06): أرسل OPTIONS واقرأ Allow؛ يجب رفض TRACE، وأن تُرَدّ الطرق غير اللازمة بـ⁦405⁩. ولا تجرّب PUT أو DELETE إلا على سجل أنشأته أنت.
• نقاط نهاية الإدارة والتشخيص (WSTG-CONF-05): يجب ألا تجيب لوحات الإدارة وصفحات الصحة والمقاييس والحالة المفصّلة من الإنترنت دون تسجيل دخول المدير.
• ترويسات الأمان: سُجّلت في الجولة السلبية؛ وكثيراً ما تغيب عن صفحات الخطأ وإعادات التوجيه واستجابات API.

جرّبها: منشئ طلبات API

المكوّنات المعرّضة وسلسلة التوريد: SCA وCVE وCVSS وSBOM

كثير من مكوّنات تطبيق الويب يدخل بشكل غير مباشر عبر مكوّنات أخرى. وفئة A03:2025 إخفاقات سلسلة توريد البرمجيات تشمل المكوّنات وخطوات البناء ذات الثغرات المعروفة أو غير المصانة أو غير المتتبَّعة أو المخترقة. يعمل الفحص عادةً في خط الأنابيب؛ والمختبِر يقرؤه ويفرزه مع المطور ويحمله إلى قرار الإصدار.

افرز كل تنبيه بأربعة أسئلة. هل الإصدار المعرّض في البناء المشحون، أم في اعتمادية تطوير فقط؟ هل تصل طريقة استخدام المنتج للمكوّن إلى الشيفرة المعرّضة؟ هل يوجد إصلاح، وماذا يغيّر؟ هل الثغرة معروفة بأنها مستغَلة؟ وتذكر ذلك النشرةُ أو قائمةٌ عامة مثل فهرس CISA للثغرات المستغَلة المعروفة (Known Exploited Vulnerabilities Catalog). والنتائج: إصلاح فوري، أو إصلاح في إصدار مخطط، أو «لا يمسّ المنتج» مع تدوين السبب، أو نتيجة إيجابية كاذبة. أما قبول المخاطرة فقرار مالك الأمان أو مالك المنتج.

• تحليل تركيبة البرمجيات (Software Composition Analysis, SCA) يقرأ ملفات الاعتماديات (مثل package.json وملف القفل package-lock.json، أو ملف pom.xml في Maven)، ويسرد كل اعتمادية مباشرة وغير مباشرة بإصدارها، ويطابقها مع نشرات الثغرات المنشورة.
• معرّف CVE بالصيغة CVE-<year>-<number> يسمّي ثغرة واحدة مُفصحاً عنها علناً؛ ويربط النشرة بالماسح وبالإصلاح، وبه تُدمج التكرارات.
• النظام الشائع لتقييم الثغرات (Common Vulnerability Scoring System, CVSS) الذي تصونه منظمة FIRST يعطي درجة أساسية من ⁦0.0⁩ إلى ⁦10.0⁩: لا شيء (None) ⁦0.0⁩، ومنخفضة ⁦0.1–3.9⁩، ومتوسطة ⁦4.0–6.9⁩، وعالية ⁦7.0–8.9⁩، وحرجة ⁦9.0–10.0⁩. والمتّجه (Vector) يشرح السبب: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (⁦9.8⁩) يعني هجوماً عبر الشبكة، بتعقيد منخفض، دون صلاحيات ولا تفاعل من المستخدم، وبأثر عالٍ على السرية والسلامة والتوافر. وتحقق من بادئة الإصدار (⁦3.1⁩ أو ⁦4.0⁩) قبل المقارنة بين درجتين.
• يسمّي CVSS هذه الفئات مستويات خطورة، لكن الدرجة الأساسية تقيّم الثغرة بوجه عام لا في منتجك: فهي مُدخل لخطورة تقرير العيب، لا تلك الخطورة نفسها.
• قائمة مكوّنات البرمجيات (Software Bill of Materials, SBOM) تسرد مكوّنات بناء واحد بإصداراتها ومورّديها وعلاقات الاعتماد بينها، بصيغة معيارية مثل SPDX أو CycloneDX، فيصبح سؤال «هل تمسّنا الثغرة؟» بحثاً لا تخميناً.

جرّبها: عارض شجرة JSON جرّبها: مقارنة JSON

ربط الملاحظات بقائمة OWASP Top 10:2025

يذكر كل بند في التقرير اختبار WSTG (كيف فُحص) وفئة Top 10 مع سنتها (نوع الخطر). وإذا انطبقت الملاحظة على فئتين فاختر السبب الجذري: صفحة تصحيح تُركت مفعّلة هي A02، وتتبّع مكدس من استثناء غير معالَج هو A10.

• A02:2025 سوء الإعداد الأمني (Security Misconfiguration): الحسابات الافتراضية، وأوضاع التصحيح، وإعدادات الأخطاء المفصّلة، وعرض محتويات المجلدات، والطرق غير اللازمة، ونقاط نهاية الإدارة أو التشخيص المكشوفة، والترويسات والسمات الغائبة.
• A10:2025 سوء التعامل مع الحالات الاستثنائية: تتبّعات مكدس مكشوفة، وفحوص تفشل مفتوحة، وعمليات نصف منجزة.
• A03:2025 إخفاقات سلسلة توريد البرمجيات (Software Supply Chain Failures): مكوّنات وأدوات بناء معرّضة أو غير مصانة أو غير متتبَّعة.
• A04:2025 إخفاقات التشفير (Cryptographic Failures): HTTP صريح وTLS قديم.
• A01:2025 خلل التحكم في الوصول (Broken Access Control): نقطة نهاية إدارة تجيب دون الدور الصحيح، وملاحظات اختبارات الأدوار اليدوية.
• A08:2025 إخفاقات سلامة البرمجيات أو البيانات (Software or Data Integrity Failures): سكربتات من CDN غير موثوق دون فحص سلامة، وتحديثات غير متحقَّق منها.

مثال تطبيقي: فرز ملاحظة من الماسح والإبلاغ عنها

التقرير الأمني خريطة للمهاجم. ارفعه فقط في القناة التي يسمّيها النطاق، وهي عادةً مشروع مقيّد الصلاحيات في المتتبع، لا تذكرة عامة ولا محادثة الفريق. واحجب معرّفات الجلسات والرموز وكلمات المرور والبيانات الشخصية، وأثبت الملاحظة بالقدر اللازم فقط: استجابة واحدة تُظهر بريد مستخدم آخر دليل؛ أما تنزيل الجدول فحادثة أمنية.

في فحص متجر الكتب أطلق فحص الاعتماديات للبناء ⁦412⁩ تنبيهين، فحصهما المطور والمختبِر مقابل قائمة SBOM للبناء. والأسماء ومعرّف النشرة مختلَقة.

• التنبيه الآخر، مكتبة لتشغيل الاختبارات بدرجة ⁦9.8⁩ حرجة، سُجّل «لا يمسّ المنتج»: فهي اعتمادية تطوير غائبة عن SBOM البناء المشحون. ومع ذلك جُدولت ترقيتها، لأنها تعمل على أجهزة CI التي تحمل أسراراً.
• وأصبح تنبيه ⁦8.8⁩ هو الملاحظة لأن الإصدار المعرّض يُشحن ويصل إليه أي مستخدم مسجّل: الحسم كان للوجود وإمكانية الوصول، لا للدرجة. والخطورة المقترحة حرجة (Critical) على مقياس الفريق، لا فئة CVSS العالية (High)، لأن أي مستخدم مسجّل قد يشغّل شيفرة على خدمة الصور بحسب النشرة.
• أعد الاختبار على البناء ⁦413⁩: أعد الفحص وتأكد من الإصدار المُصلَح في SBOM قبل الإغلاق. والثغرة في المكوّن نفسه تذهب إلى من يصونه عبر جهة الاتصال الأمنية المنشورة، لا عبر تذكرة عامة.

Finding WS-05  Vulnerable image library in avatar upload   Severity: Critical (proposed)
Category:  A03:2025 Software Supply Chain Failures
Source:    dependency scan (SCA), build 412
Component: acme-img-resize 3.2.0, transitive via avatar-service 1.4.2, runtime
Advisory:  CVE-YYYY-NNNNN  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  8.8 High
Fixed in:  acme-img-resize 3.2.4 (per the advisory)
Triage:    in the SBOM of build 412; reached on every avatar upload, which any
           logged-in user can make. No exploit attempted.
Impact:    per the advisory, a crafted image can run code on the image service.
Fix:       upgrade avatar-service, or pin acme-img-resize >= 3.2.4; rescan.
Evidence:  scan report and SBOM excerpt attached; no tokens or user data in them.
Status:    filed as SEC-231 (restricted security project); retest on build 413.

أسئلة شائعة

المراجع

• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.
• OWASP Cheat Sheet Series: Error HandlingOWASP Foundationاستجابات خطأ تساعد المستدعي دون تسريب تتبّعات الأخطاء أو الإصدارات أو المسارات الداخلية.
• NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008كيف تُخطَّط تقييمات الأمان وتُنفَّذ: المراجعة وتحديد الأهداف والتحقق من الثغرات وإعداد التقارير.