كيف تبحث عن ثغرات الويب؟

في هذا الدليل

مقدمة: لماذا هذا الموضوع يستحق وقتك؟
تهيئة بيئة العمل والأدوات اللازمة
بيئات التصحيح لكل لغة برمجة على حدة
تفعيل التصحيح عن بُعد لتطبيقات الـ JVM داخل IntelliJ IDEA
اختيار الأدوات المناسبة للمهمة
منهجية فك شفرة ثغرات CVE
الاستراتيجية الكبرى: من أين تبدأ؟
بناء إثبات الفكرة (PoC)
من إثبات يدوي إلى قالب Nuclei جاهز
تنظيم المعرفة: لماذا دفتر الملاحظات سلاحك السري؟
الممارسة تصنع الخبير: كيف تتحول إلى صائد ثغرات؟

مقدمة

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

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

الهدف النهائي؟ أن تكتسب عقلية منظمة وقابلة للاستنساخ في التعامل مع أي ثغرة ويب جديدة تصادفها.

بيئة العمل والأدوات اللازمة

قبل أن تلمس سطر كود واحد، يجب أن تفهم تمامًا على ماذا تبني تحقيقك. هل التطبيق مكتوب بـ Java؟ أم .NET؟ أم Node.js؟ أم Python أم PHP؟

هذا السؤال البسيط يحدد كل شيء لاحقًا: الأدوات التي ستستخدمها، وطريقة التصحيح، وحتى الأسلوب الذهني الذي ستعتمده لفهم منطق التطبيق.

كيف تحصل على نسخة قابلة للاختبار؟

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

الحالة الصعبة: أن يكون برنامجًا مغلق المصدر (Enterprise). هنا تواجه تحديًا حقيقيًا، خاصةً حين لا تتوفر الإصدارات القديمة التي تحوي الثغرة. الحل؟ اللجوء إلى:

التوثيق الرسمي للشركة المنتجة.
المنتديات المتخصصة وسجلات التغييرات (Changelogs).
تقارير CVE السابقة وكتابات الباحثين الأمنيين.
المدونات التقنية التي تعرض خطوات التثبيت والإعداد.

هذه المصادر غالبًا ما تحوي لآلئ معلوماتية: أرقام إصدارات دقيقة، وإعدادات شبكية، وحتى ملفات تعريف بيئة العمل.

بيئات التصحيح لكل لغة برمجة

لكل لغة طريقتها في التصحيح. إليك الدليل المختصر لأشهر المنصات:

تطبيقات Java — التصحيح عبر JVM عن بُعد

تُعدّ هذه واحدة من أقوى التقنيات وأكثرها استخدامًا في تحقيقات الـ N-day. الفكرة بسيطة: تُفعّل علامات (flags) خاصة عند تشغيل التطبيق، فيسمح لك الـ IDE بالاتصال بالعملية قيد التشغيل وفحص ذاكرتها أثناء العمل.

الخطوة الأولى: تفعيل وضع التصحيح في التطبيق

في أغلب الحالات، تعمل تطبيقات Java عبر خادم Tomcat. وستجد أن ملف catalina.sh هو المسؤول عن التشغيل. ما عليك سوى إضافة هذه العلامة إلى متغيرات JAVA_OPTS:

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

في بعض الحالات، يكون التطبيق عبارة عن أداة CLI مكتوبة بـ Java مباشرة. هنا أيضًا يمكنك تشغيلها يدويًا مع إضافة العلامة نفسها.

الخطوة الثانية: الاتصال من IntelliJ IDEA

هنا ننتقل إلى الفقرة التالية بالتفصيل.

تفعيل التصحيح عن بُعد داخل IntelliJ IDEA

أولًا: إضافة مكتبات JAR إلى المشروع

لكي يستطيع IntelliJ تنقيح التطبيق وفحص ملفاته:

اذهب إلى: File → Project Structure → Libraries.
اضغط زر "+" وأضف جميع ملفات JAR ذات الصلة.
ستظهر هذه المكتبات الآن في القسم "External Libraries" في اللوحة اليسرى.

ثانيًا: إعداد تكوين التنقيح

اضغط أيقونة Debug (أو Add Configuration).
اختر Remote JVM Debug.
حدّد الإعدادات المناسبة ثم اضغط Debug.

بعد الاتصال بنجاح، تصبح بين يديك قدرات تحليلية خارقة:

نقاط التوقف (Breakpoints): ضعها على الـ controllers، والفلاتر، ومكتبات Deserialization، ومحركات القوالب (Template Renderers).
تقييم التعبير (Evaluate Expression): طبّقها على كائنات الطلب (Request) لرؤية الـ parameters، والكوكيز، والـ Headers بعد تحليلها مباشرة.

نصيحة للمحقق المتمرس: الـ Breakpoints على نقاط Deserialization غالبًا ما تكشف ثغرات تنفيذ كود عن بُعد (RCE) بشكل شبه فوري.

تطبيقات .NET — أدوات JetBrains وILSpy

لتطبيقات .NET، لديك ترسانة قوية:

JetBrains dotPeek: لإجراء Decompilation وتحليل ديناميكي.
ILSpy: أداة مفتوحة المصدر لاسترجاع الكود عالي المستوى من الـ binaries.
dnSpyEx: نسخة محدّثة من dnSpy، تسمح بالتنقل والبحث وحتى تعديل الـ binaries أثناء التشغيل.

عند تفعيل Symbol paths وتوفير بيئة اختبار محلية، يمكنك الالتصاق بالعمليات الجارية (Attach to Process) لتنقيح خدمات .NET Core و.NET Framework التقليدية.

تطبيقات Node.js — VS Code يكفيك

إذا كان الهدف تطبيق JavaScript أو Node.js، فإن Visual Studio Code مع إضافة Node.js Debug الرسمية خيارك الأمثل. ضع نقاط التوقف على:

منطق الـ API.
الـ Middleware.
محرك القوالب (Templating).

لتُراقب معالجة الطلب لحظة بلحظة.

تطبيقات PHP — Xdebug هو رفيقك

لتطبيقات PHP، استخدم Xdebug مع VS Code أو PHPStorm. هذه التركيبة ممتازة لتفكيك منطق التوجيه (Routing) المعقّد وفحص المدخلات غير المُحقَّقة — وهو نمط شائع جدًا في تطبيقات PHP القديمة.

اختيار الأدوات المناسبة

أدوات فك الكود (Decompilers)

اللغة	الأدوات الموصى بها
Java	IntelliJ IDEA للتنقيح، مع CFR أو FernFlower أو Procyon لفك الـ JAR. ملاحظة: IntelliJ يقوم بفك الـ JARs تلقائيًا أثناء التصفح.
.NET	ILSpy، أو dotPeek، أو dnSpyEx للنسخة التفاعلية مع دعم البحث ومقارنة الباتشات.

أدوات مقارنة الباتشات (Patch Diffing)

عند توفّر الكود المصدري، Git هو صديقك المخلص:

استخدم Git مباشرة لمقارنة الإصدارات.
إضافات VS Code مثل Compare Folders لإجراء المقارنة بصريًا.
IntelliJ IDEA نفسه يدعم Compare Folder، ويمتد ذلك إلى دعم فك الـ JAR أثناء المقارنة.

منهجية فك شفرة ثغرات CVE

كيف تُرتّب أولوياتك عند اختيار CVE؟

ليست كل الثغرات تستحق وقتك. ركّز على تلك التي تجمع أكبر عدد من عوامل الخطورة:

الأولوية القصوى:

هجوم عن بُعد (Remote) دون الحاجة إلى مصادقة (Preauth).
تعقيد منخفض (Low complexity).
لا يحتاج إلى تفاعل مستخدم (No user interaction).
يعمل بـ الإعدادات الافتراضية.
يستهدف مكوّنات مواجهة للإنترنت (Edge-facing).

إشارات تستحق الاهتمام:

صدور Hotfix سريع من الشركة المنتجة (يدل على خطورة فعلية).
ورود كلمات مثل "header trust"، و"serialization"، و"templating"، و"path normalization" في الوصف.

ترتيب الأولويات:

RCE لا تحتاج إلى مصادقة (Preauth RCE) — الملك بلا منازع.
تجاوز المصادقة الواضح (Auth bypass).
تسريب معلومات (Info disclosure) — فقط إذا كشف tokens أو configurations تسمح بحركة جانبية أو رفع صلاحيات.

تقييم التأثير الفعلي

اسأل نفسك هذه الأسئلة:

هل الثغرة قابلة للوصول في النشر الشائع؟
هل تعمل بـ الإعدادات الافتراضية؟
هل تتطلب خطوات قليلة للاستغلال؟
هل يمكن بناء إثبات آمن وحتمي (Safe deterministic proof)؟
هل هناك إشارات إيجابية كاختلاف بسيط في الباتش، أو triggers مستقرة، أو ضعف في حدود الثقة بين Proxy والـ Webhook، أو نمط ثغرة متكرر في عائلة المنتج؟

الاستراتيجية الكبرى: من أين تبدأ؟

عند فك شفرة CVE، أمامك مساران رئيسيان بحسب المتاح:

المسار الأول: توفّر Hotfix أو Bundle للباتش

ابدأ فورًا من الباتش! فهو بوصلتك الذهبية، إذ يُشير مباشرة إلى:

الكود الذي تغيّر.
شرح الثغرة (غالبًا).
طريقة التخفيف (Mitigation).

المسار الثاني: لا يتوفر Hotfix — إعادة بناء شجرتي الكود

إذا لم يتوفر Hotfix مباشر، اتبع الخطوات التالية:

احصل على أقرب إصدار مصاب + أقرب إصدار مُصلَح (يُفضّل أن يكونا متجاورين حتى يكون الفرق صغيرًا).
فك الكود (Decompile) أو فك ضغط كلا الإصدارين.
أنشئ مستودع Git للشجرة المصابة.
انسخ ملفات الإصدار المُصلَح فوقها.
استخدم git diff لرؤية كل تغيير.

هذا الفرق هو خريطتك الذهبية نحو:

مسارات الكود المصابة.
المدخلات الخطيرة.
الإصلاح المقصود.

مثال عملي: إعداد بيئة المقارنة

الخطوة 1: تحضير أشجار الكود المفكوكة

mkdir -p /tmp/cve-reverse && cd /tmp/cve-reverse
jar xf vulnerable.jar -C vulnerable/
jadx -d vulnerable-src vulnerable.jar
jar xf patched.jar -C patched/
jadx -d patched-src patched.jar

الخطوة 2: إنشاء مستودع Git للمقارنة

cd /tmp/cve-reverse
cp -r vulnerable-src repo
cd repo
git init
git add . && git commit -m "vulnerable version"

# نسخ الملفات المُصلَّحة فوق
rsync -a --delete ../patched-src/ .
git add -A
git commit -m "patched version"

# عرض الفرق
git --no-pager diff HEAD~1 HEAD > ../patch.diff

الخطوة 3: أين تُركّز نظرك في الـ diff؟

تغييرات التحقق من المدخلات (هل أُزيلت أو أُضيفت Sanitizers؟).
فحوصات جديدة (null checks، قوائم بيضاء/سوداء، التحقق من التواقيع).
تغييرات في Callsites (مواقع استخدام الدالة غير الآمنة).
دوال مساعدة جديدة أو مُزالة.

أمثلة حقيقية من أرض الواقع

Zimbra — CVE-2024-45519: تحليل يُظهر كيف ننتقل من فهم الباتش إلى الاستغلال. نفهم الحارس الذي تغيّر، ثم نُعيد إنشاء الحالة قبل الإصلاح للوصول إلى تنفيذ الأوامر.
Ivanti EPMM — CVE-2025-4427/4428: نُشرت الكشوفات جنبًا إلى جنب مع التحليل. تفاصيل الباتش تُحدّد الشروط الدقيقة التي تعتمد عليها مفاتيح القوالب.
Versa — CVE-2025-34027: تناقضات في ترميز المسار (Path decoding) تحوّل "مرفوض" إلى "مسموح به" إذا حدث التطبيع (Normalization) بعد التحقق من الصلاحيات. هذا المثال يوضح كيف يصبح مسار الـ API بابًا خلفيًا.

بناء إثبات الفكرة (Proof of Concept)

بعد أن تفك شفرة الـ CVE وتُعيد إنتاجه، يأتي الدور على أهم مرحلة عملية: بناء إثبات فكرة مُحكَم، وآمن، وقابل للتكرار.

القواعد الذهبية لإثبات فكرة جيد

مُثبَّت الإصدار (Version-pinned): يجب أن يكون مرتبطًا بإصدار دقيق.
بلا آثار جانبية (Side-effect free): لا يغيّر حالة النظام بشكل دائم.
مؤشّر واحد قابل للملاحظة (Single observable marker): يعتمد على علامة واحدة واضحة للنجاح.
مُتحقَّق منه: اختبره ضد عدة إصدارات مصابة، وإصدار مُصلَح واحد على الأقل.

كيف تتأكد أنك في المسار الصحيح للكود؟

استخدم Breakpoints أو Logpoints لتأكيد أنك مررت بالمسار الصحيح. ثم شغّل بناءً مُصلَحًا كعنصر تحكّم سلبي — إذا اختفى التأثير في الإصدار المُصلَح، فهذا تأكيدك بأن الباتش هو السبب الحقيقي للإصلاح.

من إثبات يدوي إلى قالب Nuclei جاهز

إثبات الفكرة الجيد ليس مجرد طلب HTTP واحد — بل هو نواة قالب كشف تلقائي قابل للنشر في Nuclei. إليك خارطة التحويل:

1. اختر إثباتًا آمنًا

يُفضَّل الإشارات للقراءة فقط على تغيير الحالة:

مفتاح استجابة مميّز من endpoint داخلي.
ملف علامة (marker) غير ضار لاختبار اجتياز المسار (Traversal).
تأخير حتمي (Deterministic delay) لاختبار الفئات العمياء (Blind).

2. ترجمته إلى قالب Nuclei

استخدم طلبات HTTP خام ومركّزة:

ادمج علامة فريدة في الجسم مع مطابقة على كود الحالة أو جسم الاستجابة.
أو استخدم DSL duration check للحالات المعتمدة على التوقيت.
اضبط stop-at-first-match: true لتجنّب النتائج المكررة.
تجنّب إجراءات الكتابة افتراضيًا.

3. التحقق من القالب

اختبر ضد عدة إصدارات مصابة وإصدار مُصلَح واحد على الأقل. ووثّق:

الـ Headers المطلوبة.
سلوك إعادة التوجيه (Redirect behavior).
أي تأثيرات للـ Proxy/CDN.

4. تقوية القالب

فشل سريع عند إعادة التوجيه.
تقييد المهل الزمنية (Timeouts).
توثيق الافتراضات داخل القالب نفسه كتعليقات.
وفّر متغيّرًا ثانويًا آمنًا لاختلافات المنصات (Linux مقابل Windows مثلًا) بدلاً من حمولات (payloads) عامة ضبابية.

> فلسفة الإثبات: اختر إثباتات لا يمكن إنكارها، لكن قابلة للعكس: اكتب ملفًا في دليل مُعزول، أو اضرب endpoint قراءة فقط ذات صلاحيات، أو شغّل أمرًا آمنًا. أعد تشغيل نفس الطلب على الإصدار المُصلَح لتُثبت أن التأثير اختفى للسبب الصحيح.

تنظيم المعرفة: لماذا دفتر الملاحظات سلاحك السري؟

البحث الأمني الجيد يعيش أو يموت على التنظيم. كل ما يشرح ماذا جرّبت، ولماذا جرّبته، وما الذي تغيّر — يجب أن يبقى في مكان واحد واضح.

هيكل المجلدات المقترح لكل CVE

case-folder/
├── lab-notes.md          # ملاحظات تتطوّر مع التحقيق
├── lab/                  # ملفات الحاويات وتكوينات المنقّح
├── requests/             # صادرات Burp أو طلبات HTTP خام
├── diffs/                # اختلافات الإصدارات المفكوكة
└── detections/           # قالب Nuclei + سجلات التحقق

قواعد اللعبة

اعمل Commit بأحجام صغيرة بشكل طبيعي، واستخدم Git LFS للـ binaries الكبيرة أو أشجار الـ Decompiler حتى يبقى تاريخ المستودع سريع الاستنساخ.
سجّل كل شيء غريب لاحظته: رسائل خطأ غريبة، توقيتًا غير معتاد، إعدادات افتراضية مفاجئة، أي primitive يبدو في غير مكانه.

لماذا الملاحظات الصغيرة تصنع اكتشافات كبيرة؟

تلك الملاحظات الصغيرة قد لا تبدو ذات معنى في لحظتها، لكنها غالبًا ما تتحول لاحقًا إلى مفاتيح حرجة. عندما تعود لهدف ما بعد أسابيع أو أشهر بسياق جديد، تفتح لك تلك الملاحظات المتفرقة زوايا وسلاسل (chains) جديدة.

مثال واقعي: بحث Lucee الموثّق في مدوّنة ProjectDiscovery بدأ من مشكلات وسلوكيات صغيرة لُوحظت قبل شهرين. وعندما أعاد الفريق فحص تلك الملاحظات برؤية جديدة، تمكّنوا من تحويلها إلى RCE لا تحتاج إلى مصادقة ضد Apple.

الممارسة تصنع الخبير: كيف تتحول إلى صائد ثغرات؟

البحث في الثغرات هو في جوهره التعرّف على الأنماط عبر التكرار. وإليك وصفة الممارسة المنهجية:

وصفة تطوير الخبرة

اختر CVE مُفصَحًا عنه.
أعِد بناء البيئة.
تتبّع المسار من الباتش إلى الـ Primitive.
ابحث عن أنماط مشابهة في كود مجاور.
وثّق ما لم ينجح — هذه الملاحظات تصير حاسمة عند عودتك لأهداف بعد أشهر.

دعوة للمجتمع

حقل الأمن السيبراني يحتاج إلى باحثين مستعدين لـ:

تقوية قوالب الكشف وجعلها أكثر دقة.
التحقق عبر اختلافات المنصات المختلفة.
مشاركة حالات إعادة الإنتاج بتفاصيلها الكاملة.

الكلمة الأخيرة

اكتشافك القادم ينتظرك في رسالة خطأ تجاهلتها، أو تداخل ميزات لم يخطر ببال أحد اختباره.

حافظ على أدواتك حادّة، وملاحظاتك منظمة، وفضولك حيًّا.

الآن، اذهب واكسر شيئًا بأمان… ثم شارك ما تعلّمت على شبكة Professor Technology