يمكن لأداة Vulnerability Scanner اكتشاف عدد كبير من الأنماط المعروفة بسرعة، لكنها لا تعرف دائمًا ما إذا كان المستخدم يملك حق الوصول إلى سجل معين، أو ما إذا كانت عملية استرداد الأموال تخالف قواعد العمل، أو ما إذا كان الانتقال بين خطوتين في Workflow يتيح تنفيذ إجراء لم يكن يفترض السماح به.
لهذا لا يساوي الفحص الآلي اختبار اختراق كاملًا. أفضل Web Penetration Test يجمع بين الأتمتة والتفكير اليدوي داخل نطاق اختبار مصرح به، مع التركيز على الصلاحيات، وحالات التطبيق، ومنطق الأعمال، وتأثير النتيجة فعليًا.
يتوافق هذا النهج مع OWASP Top 10:2025 ومع متطلبات OWASP ASVS 5.0.0 ومنهجية OWASP Web Security Testing Guide.
لماذا لا يكفي Vulnerability Scanner وحده؟
الماسح الآلي ممتاز عندما تكون المشكلة قابلة للاكتشاف من Request أو Response أو Configuration أو Signature معروفة. لكنه يواجه صعوبة عندما تحتاج النتيجة إلى فهم العلاقة بين عدة مستخدمين أو أدوار أو خطوات داخل التطبيق.
على سبيل المثال، قد يرى Scanner استجابة HTTP ناجحة، لكنه لا يعرف بالضرورة أن البيانات المعادة تخص مستخدمًا آخر. وقد يرى Request صالحًا تقنيًا دون أن يعرف أن العملية التجارية لا تسمح بتنفيذ الإجراء مرتين.
إذا كنت تريد فهم المصطلحات الأساسية قبل المتابعة، يوضح دليل مصطلحات الأمن السيبراني الفرق بين Vulnerability وExploit وPenetration Testing ومفاهيم أمنية أخرى مرتبطة بهذا النوع من الاختبارات.
1. Broken Access Control
تظل أخطاء التحكم في الوصول من أهم ما يجب اختباره يدويًا. وفي OWASP Top 10:2025 احتفظت فئة Broken Access Control بالمركز الأول.
المشكلة لا تكون دائمًا في تسجيل الدخول نفسه، بل في السؤال التالي: بعد تسجيل الدخول، هل يستطيع المستخدم تنفيذ عمليات أو الوصول إلى بيانات لا تخصه؟
مثال دفاعي بسيط: يمتلك مستخدم حسابًا صالحًا ويطلب فاتورة تخص حسابه. عند تغيير معرف السجل، يعيد التطبيق فاتورة تخص عميلًا آخر دون التحقق من ملكية المورد.
يجب أن يغطي الاختبار:
- الوصول إلى Objects يملكها مستخدم آخر.
- تعديل أو حذف موارد لا يملكها المستخدم.
- الاختلاف بين صلاحيات القراءة والكتابة والحذف.
- واجهات API التي تطبق Authorization بشكل مختلف عن واجهة الويب.
- الوظائف التي تعتمد على التحقق في الواجهة فقط بدل Server Side.
- سياسة Deny by Default والامتياز الأقل.
تؤكد إرشادات OWASP الخاصة بـBroken Access Control أن تطبيق ضوابط الوصول يجب أن يتم في جهة موثوقة على الخادم، لا عبر إخفاء أزرار أو الاعتماد على بيانات يستطيع العميل تعديلها.
2. Horizontal وVertical Privilege Escalation
هناك فرق مهم بين نوعين من تجاوز الصلاحيات.
Horizontal Privilege Escalation يحدث عندما يستطيع مستخدم الوصول إلى بيانات أو وظائف تخص مستخدمًا آخر يمتلك المستوى نفسه من الصلاحيات.
أما Vertical Privilege Escalation فيحدث عندما يتمكن مستخدم منخفض الصلاحية من الوصول إلى وظيفة مخصصة لدور أعلى، مثل Moderator أو Administrator.
الاختبار اليدوي مهم هنا لأن المختبر يستطيع إنشاء عدة حسابات وأدوار ومقارنة ما يسمح به التطبيق لكل منها، بدل الاكتفاء بالسؤال عما إذا كان Endpoint يستجيب أم لا.
يجب أيضًا اختبار Authorization على كل عملية حساسة بصورة مستقلة. وجود زر لا يظهر للمستخدم العادي ليس ضابطًا أمنيًا إذا كان الخادم يقبل العملية نفسها عند إرسال Request مباشرة.
3. Business Logic Flaws
ثغرات منطق الأعمال من أكثر المشكلات التي تظهر قيمة الاختبار اليدوي بوضوح، لأن Request قد يكون صحيحًا تمامًا من الناحية التقنية بينما يكون تسلسل العمليات نفسه قابلًا للإساءة.
أمثلة على الأسئلة التي يجب طرحها أثناء الاختبار:
- هل يمكن استخدام خصم أكثر من العدد الذي تسمح به السياسة؟
- هل يمكن تجاوز خطوة إلزامية في Workflow؟
- هل يستطيع المستخدم تنفيذ Refund أو إجراء مالي أكثر من مرة؟
- هل يتحقق الخادم مجددًا من السعر والكمية والحدود قبل تنفيذ العملية النهائية؟
- هل يمكن تنفيذ عملية بترتيب مختلف عن التسلسل الذي تفترضه الواجهة؟
- هل توجد حدود تجارية يفرضها JavaScript فقط ولا يتحقق منها الخادم؟
هذه المشكلات لا تعني بالضرورة وجود CVE أو Payload معروف. الخطأ قد يكون خاصًا بقواعد التطبيق نفسه، ولهذا يصعب اكتشافه دون فهم ما يفترض أن يحدث وما لا يفترض أن يحدث.
4. Session Management
بعد نجاح المصادقة تصبح Session Token عنصرًا شديد الحساسية لأنها تمثل هوية المستخدم في الطلبات اللاحقة. لذلك يجب ألا يقتصر الاختبار على صفحة Login.
من المهم التحقق من:
- هل يتم إبطال Session بعد Logout؟
- هل يتغير Session Identifier بعد المصادقة أو تغير مستوى الصلاحية؟
- هل توجد Idle وAbsolute Timeouts مناسبة؟
- هل Cookies الحساسة تستخدم خصائص Secure وHttpOnly وSameSite بالشكل الملائم؟
- هل تبقى جلسات قديمة فعالة بعد تغيير كلمة المرور أو حدث أمني حساس عندما ينبغي إبطالها؟
- هل Session Identifier قابل للتنبؤ أو يحتوي معلومات لا ينبغي كشفها؟
تشرح OWASP Session Management Cheat Sheet دورة حياة Session وآليات حمايتها وعلاقتها بالمصادقة والتحكم في الوصول.
5. Password Reset وAccount Recovery
قد تكون آلية تسجيل الدخول محمية جيدًا بينما تصبح عملية استرجاع الحساب هي المسار الأضعف.
يجب اختبار Recovery Flow باعتباره جزءًا مستقلًا من سطح الهجوم، بما في ذلك:
- هل يكشف التطبيق وجود حساب مرتبط بعنوان بريد معين؟
- هل Reset Token عشوائي بما يكفي؟
- هل له مدة صلاحية محدودة؟
- هل يمكن استخدامه أكثر من مرة؟
- هل يتم إبطال الرموز السابقة عند إصدار رمز جديد عندما يتطلب التصميم ذلك؟
- هل يمكن تغيير البريد الإلكتروني أو MFA دون إعادة تحقق مناسبة من هوية المستخدم؟
- هل يتم إنشاء Session جديدة تلقائيًا بطريقة قد تؤدي إلى سلوك غير مرغوب بعد تغيير كلمة المرور؟
وتوصي OWASP Forgot Password Cheat Sheet باستخدام رموز عشوائية وآمنة ومحدودة الصلاحية وأحادية الاستخدام، مع تجنب كشف ما إذا كان الحساب موجودًا من الأساس.
6. Server-Side Request Forgery أو SSRF
تظهر SSRF عندما يستطيع المستخدم التأثير في الوجهة التي يتصل بها الخادم نفسه. يمكن أن توجد هذه الوظيفة في Webhooks أو جلب الصور من URL أو عمليات Import أو تكاملات خارجية وغيرها.
في OWASP Top 10:2025 أصبحت SSRF ضمن فئة Broken Access Control بدل وجودها كفئة مستقلة كما كان الحال في إصدار 2021.
الاختبار لا يجب أن يقتصر على معرفة ما إذا كان الخادم يستطيع طلب URL خارجي؛ بل يجب فهم حدود الاتصال التي يفترض أن يمتلكها التطبيق وما إذا كان يمكن تجاوز سياسات الوجهة بصورة غير متوقعة.
دفاعيًا، ينبغي مراجعة:
- حصر الوجهات المسموح بها عندما يسمح تصميم النظام بذلك.
- التحقق من أسماء النطاقات وعناوين IP بصورة صحيحة.
- التعامل الآمن مع Redirects.
- منع الوصول غير المطلوب إلى الشبكات الداخلية وخدمات البنية التحتية.
- تطبيق Network Segmentation وضوابط Egress عندما تكون مناسبة.
يوفر دليل OWASP لمنع SSRF تفاصيل دفاعية حول تصميم ضوابط الوجهات وحالات الاستخدام المختلفة.
7. File Upload
فحص امتداد الملف وحده لا يكفي لحماية وظائف رفع الملفات. يجب تقييم المسار الكامل منذ استقبال الملف وحتى تخزينه ومعالجته وإتاحته مرة أخرى.
تشمل النقاط المهمة:
- الامتدادات المسموح بها وفق حاجة العمل.
- التحقق من نوع الملف وعدم الثقة في Content-Type وحده.
- توليد أسماء ملفات آمنة بدل الاعتماد على الاسم المقدم من المستخدم.
- تحديد الحجم والعدد ومعدلات الرفع.
- تخزين الملفات خارج Webroot عندما يكون ذلك مناسبًا.
- منع امتلاك الملفات المرفوعة صلاحيات تنفيذ غير ضرورية.
- فحص المحتوى عند الحاجة باستخدام Antivirus أو Sandbox أو آليات مناسبة لنوع الملف.
- مراجعة طريقة إعادة تقديم الملفات للمستخدمين، وليس عملية الرفع فقط.
تجمع OWASP File Upload Cheat Sheet هذه الضوابط وتوضح لماذا لا يمكن الاعتماد على Extension أو Content-Type كحاجز منفرد.
8. Path Traversal
كل وظيفة تسمح للمستخدم بالتأثير في اسم ملف أو مسار تستحق مراجعة دقيقة، مثل Download وExport وTemplate Handling وفك الأرشيف وتقديم الملفات الثابتة.
المشكلة الأساسية هي السماح لمدخل يسيطر عليه المستخدم بالتأثير في الموقع النهائي داخل نظام الملفات بطريقة تتجاوز الدليل المخصص للعملية.
المعالجة القوية لا تعتمد على البحث عن سلسلة نصية واحدة وحذفها. الأفضل تصميم التطبيق بحيث لا يحتاج العميل إلى التحكم في مسارات فعلية أصلًا، واستخدام معرفات داخلية مع Canonicalization والتحقق من أن المسار النهائي بقي داخل الجذر المسموح به.
كما يجب اختبار الاختلافات بين أنظمة التشغيل، وآليات فك الترميز، والمكونات التي قد تعيد تفسير المسار في مرحلة لاحقة.
9. Race Conditions
تحدث Race Condition عندما تعتمد صحة العملية على ترتيب أو توقيت أحداث متزامنة دون وجود تنسيق كافٍ بينهما.
من الأنماط المهمة حالة Time-of-Check to Time-of-Use، حيث يتم التحقق من شرط ثم تنفيذ العملية لاحقًا، بينما يمكن أن تتغير الحالة بين المرحلتين.
قد تظهر المشكلة في وظائف مثل:
- الأرصدة والمدفوعات.
- القسائم والخصومات.
- المخزون.
- الدعوات.
- Limits وQuotas.
- العمليات التي يجب تنفيذها مرة واحدة فقط.
يفيد الاختبار اليدوي هنا في فهم الحالة التي يجب أن تكون Atomic وما إذا كان التطبيق يحافظ على قواعده تحت Requests متزامنة. ويشرح OWASP مفهوم Race Conditions وعلاقة بعض الحالات بنمط TOCTOU.
10. Security Misconfiguration
ليس من الضروري أن تكون الثغرة داخل Source Code. قد يكون التطبيق مصممًا بصورة جيدة لكن بيئة التشغيل أو الخادم أو الخدمة المحيطة به تضيف سطح هجوم غير مقصود.
ارتفعت Security Misconfiguration إلى المركز الثاني في OWASP Top 10:2025، وهو ما يعكس أهمية مراجعة الإعدادات إلى جانب اختبار الكود نفسه.
أثناء Web Pentest يجب مراجعة أمور مثل:
- Debug أوDevelopment Features المفعلة في Production.
- الحسابات أو بيانات الاعتماد الافتراضية.
- Admin Interfaces المكشوفة دون حاجة.
- Directory Listing.
- Backup Files والملفات غير المقصودة داخل Webroot.
- Verbose Error Messages التي تكشف تفاصيل داخلية.
- CORS وسياسات الوصول غير المضبوطة.
- التخزين السحابي أو الموارد العامة التي كان يفترض أن تكون خاصة.
- Security Headers والإعدادات الأمنية التي يفترضها تصميم التطبيق.
أين SQL Injection وXSS وبقية Injection؟
عدم وجود SQL Injection أو XSS ضمن هذه القائمة لا يعني أنها أصبحت غير مهمة. فئة Injection ما تزال موجودة في OWASP Top 10:2025 في المركز الخامس وتشمل عائلات متعددة من أخطاء تفسير المدخلات غير الموثوقة.
الفرق أن كثيرًا من أدوات DAST تستطيع البحث آليًا عن مجموعة كبيرة من الأنماط الشائعة، بينما تركز هذه القائمة على المشكلات التي تحتاج بصورة خاصة إلى معرفة السياق والأدوار وحالة التطبيق وقواعد العمل.
حتى عند اكتشاف Scanner لنتيجة محتملة مثل Injection، يبقى التحقق البشري مهمًا لتقليل False Positives وفهم شروط المشكلة وتأثيرها الفعلي ووضع الأولوية الصحيحة للإصلاح.
لماذا ASVS أفضل من Checklist عشوائية؟
اختبار مجموعة Payloads ثم عدم العثور على نتيجة لا يثبت أن التطبيق آمن. الأفضل أن يبدأ الاختبار من Security Requirements واضحة تحدد ما الذي يجب التحقق منه أصلًا.
يوفر OWASP ASVS معيارًا يمكن استخدامه لتحديد متطلبات التحقق الأمني. الإصدار المستقر الحالي هو ASVS 5.0.0، وتغطي متطلباته مجالات مثل Authentication وSession Management وAccess Control والتحقق من البيانات والتشفير وواجهات API وغيرها.
أما OWASP WSTG فيوفر منهجية عملية أوسع لاختبار تطبيقات وخدمات الويب. الإصدار المستقر المعروض حاليًا هو WSTG 4.2، بينما يستمر تطوير الجيل 5.0 من المشروع.
استخدام الاثنين معًا يحقق فصلًا مفيدًا: ASVS يساعدك على تحديد ما الذي يجب أن يكون صحيحًا، بينما WSTG يساعد في تنظيم كيفية التحقق من كثير من تلك الجوانب أمنيًا.
Scanner وPenetration Test ليسا الشيء نفسه
| الجانب | Vulnerability Scanner | Web Penetration Test |
|---|---|---|
| اكتشاف الأنماط المعروفة | قوي وسريع | يمكن الاستفادة من الأتمتة ثم التحقق |
| فهم Business Logic | محدود | جزء أساسي من الاختبار اليدوي |
| مقارنة أدوار المستخدمين | قد يكون محدودًا حسب الأداة والإعداد | يمكن اختبار العلاقات والصلاحيات في السياق |
| تحديد الأثر الحقيقي | يعتمد غالبًا على قواعد وتصنيفات عامة | يربط النتيجة ببيانات ووظائف التطبيق |
| Chaining بين Findings | محدود عادةً | يمكن دراسة العلاقة بين عدة نقاط ضعف |
| التغطية المتكررة والواسعة | ممتازة للأتمتة | أبطأ لكنها أعمق في المناطق التي تحتاج سياقًا |
هذا لا يجعل Scanner غير مفيد؛ العكس صحيح. أدوات الفحص ضرورية لتوسيع التغطية وتسريع العمل واكتشاف الأنماط المعروفة، ويمكن التعرف على أمثلة من هذه الفئة ضمن دليل أدوات وبرامج الأمن السيبراني. المشكلة تبدأ فقط عندما يتم اعتبار تقرير آلي بديلًا كاملًا لاختبار الاختراق.
ما الذي يجب أن يحتويه تقرير Pentest الجيد؟
قيمة Finding لا تأتي من اسم الثغرة وحده. يجب أن يستطيع الفريق التقني فهم المشكلة وإثباتها وإصلاحها ثم إعادة اختبارها.
بالنسبة لكل Finding مهم، من المفيد توثيق:
- النطاق المتأثر: الوظيفة أو Endpoint أو الدور الذي ظهرت فيه المشكلة.
- المتطلبات: هل تحتاج المشكلة إلى حساب؟ وما مستوى الصلاحية المطلوب؟
- الدليل: معلومات كافية لإثبات النتيجة دون جمع بيانات غير ضرورية.
- الأثر: ماذا يستطيع مستخدم غير مخول فعله فعليًا؟
- السبب الجذري: هل المشكلة في Authorization أم Workflow أم Configuration أم State Management؟
- المعالجة: الضابط المطلوب إصلاحه بدل الاكتفاء بمنع طريقة اختبار واحدة.
- إعادة الاختبار: التأكد من أن الإصلاح يعالج السبب دون إنشاء Regression جديد.
الخلاصة
الفحص الآلي مهم، لكنه لا يستطيع وحده إثبات أن تطبيق الويب يطبق قواعده الأمنية والتجارية بصورة صحيحة.
أكثر المناطق التي تستحق اختبارًا يدويًا قويًا تشمل Broken Access Control، وتجاوز الصلاحيات، ومنطق الأعمال، وإدارة الجلسات، واسترداد الحساب، وSSRF، ورفع الملفات، وPath Traversal، وRace Conditions، وسوء التهيئة.
والهدف من Web Pentest الجيد ليس إنتاج أكبر عدد ممكن من Findings، بل اختبار حدود الثقة والصلاحيات والبيانات وسير العمل، ثم تحويل النتائج القابلة للإثبات إلى إصلاحات قابلة للتنفيذ.
استخدم الأتمتة حيث تتفوق في السرعة والتغطية، واستخدم الاختبار اليدوي حيث يحتاج الأمن إلى فهم السياق. ويجب دائمًا تنفيذ أي اختبار اختراق على الأنظمة التي تملك تصريحًا واضحًا لاختبارها وداخل Scope متفق عليه.