houmanpashaei/cve-2025-29927هذا ماسح CVE-2025-29927.
هذا ماسح احترافي مصمم لاكتشاف ثغرة تجاوز الوسيطة CVE-2025-29927 في تطبيقات Next.js.
X-Middleware-Subrequest المصممة لتجاوز وسيطة Next.jspip install -r requirements.txt playwright install
### تشغيل الماسح```bash
python main.py --domain https://example.com --threads 10 --timeout 10 --save
python main.py --help
| الخيار | الوصف |
|----------------|--------------------------------------------|
| `--domain` | عنوان URL الأساسي للموقع المستهدف (مطلوب) |
| `--user-agent` | وكيل مستخدم مخصص (الافتراضي: سلسلة Chrome) |
| `--timeout` | مهلة الطلب (الافتراضي: 10 ثوانٍ) |
| `--proxy` | عنوان الوكيل (اختياري) |
| `--save` | حفظ النتائج في `results.txt` |
| `--threads` | عدد الخيوط (الافتراضي: 10) |
| `--wordlist` | قائمة كلمات تتضمن مسارًا شائعًا |
---
## 🐳 استخدام Docker
### بناء صورة Docker```bash
docker build -t cve-scanner .
docker run -it --rm cve-scanner --domain https://example.com --save
## ⚙️ إجراءات GitHub
يتضمن هذا المشروع سير عمل لـ GitHub Actions لاختبار الإعداد عند الدفع (push). يقوم بما يلي:
- تثبيت التبعيات (dependencies)
- تثبيت متصفحات Playwright
- تشغيل فحص `--help`
انظر `.github/workflows/python.yml`.
---
## 🧱 الهيكل```
.
├── main.py # Entry point
├── config.py # CLI parser
├── crawler.py # Playwright crawler
├── scanner.py # Multi-threaded vulnerability testing
├── requirements.txt
├── Dockerfile
└── .github/workflows
نظرة عامة على ثغرة CVE-2025-29927
CVE-2025-29927 هي ثغرة أمنية حرجة في Next.js تسمح للمهاجمين بتجاوز المصادقة والتفويض المستندين إلى middleware. من خلال تضمين header داخلي خاص (X-Middleware-Subrequest) في طلبات HTTP، يمكن للمهاجم خداع خادم Next.js لتخطي تنفيذ الوسيطة، وبالتالي الوصول إلى المسارات المحمية. عملياً، يتم معالجة الطلب الذي كان سيتم حظره عادةً بواسطة middleware المصادقة (على سبيل المثال، إرجاع 401/403 أو إعادة التوجيه إلى صفحة تسجيل الدخول) بشكل طبيعي في حالة وجود هذا header، مما يؤدي فعلياً إلى تجاوز فحوصات الأمان. تؤثر هذه الثغرة على إصدارات Next.js من 11.1.4 حتى 15.2.2، ويُحث المسؤولون على تثبيت التصحيحات أو تنفيذ الإجراءات التخفيفية (مثل إزالة هذا header عند الوكيل) لحماية تطبيقاتهم.
يتطلب اكتشاف هذه الثغرة في تطبيق ويب اكتشاف نقاط النهاية الداخلية واختبارها باستخدام header ضار لمعرفة ما إذا كان الوصول غير المصرح به ممكناً. فيما يلي خطة تصميم لبرنامج Python متقدم سيزحف على موقع ويب مستهدف (بدعم كامل من JavaScript) ويفحص بحثاً عن CVE-2025-29927، مع استيفاء جميع المتطلبات المحددة.
لتلبية متطلبات الزحف العميق بما في ذلك المحتوى المعروض بواسطة JavaScript، سنستخدم Playwright (المفضل على Selenium لسرعته وواجهة برمجة التطبيقات الحديثة). Playwright هي مكتبة قوية لأتمتة المتصفحات بدون واجهة رسومية يمكنها التعامل مع تطبيقات الويب الديناميكية وأطر عمل JavaScript الحديثة. مقارنةً بـ Selenium، يقدم Playwright واجهة برمجة تطبيقات أكثر حداثة (مبنية على بروتوكول Chrome DevTools) ويدعم التشغيل المتزامن وغير المتزامن، مما قد يحقق أداءً أفضل لحالة الاستخدام لدينا. تتضمن المكتبات الرئيسية وتعليمات التثبيت الخاصة بها ما يلي:
playwright – لأتمتة المتصفح بدون واجهة رسومية (لتحميل تطبيقات الصفحة الواحدة أو الصفحات التي تتطلب JavaScript). (التثبيت: pip install playwright وتشغيل playwright install للحصول على ملفات المتصفح الثنائية).
requests أو httpx – لإرسال طلبات HTTP خلال مرحلة الفحص. يمكننا استخدام requests للبساطة أو httpx/aiohttp لدعم غير المتزامن. (التثبيت: pip install requests أو pip install httpx).
bs4 (BeautifulSoup) – لتحليل HTML واستخراج الروابط عند الحاجة. يمكن لـ Playwright الاستعلام المباشر عن DOM، لكن استخدام BeautifulSoup على محتوى HTML للصفحة يكون مباشراً للعثور على علامات الربط. (التثبيت: pip install beautifulsoup4).
concurrent.futures (مدمج) أو asyncio – لتنفيذ التزامن. للخيوط المتعددة، سنستخدم concurrent.futures.ThreadPoolExecutor من Python (لا حاجة لتثبيت إضافي). في حالة استخدام نهج غير متزامن، يمكن استخدام asyncio من Python مع httpx للطلبات المتوازية.
التبرير: تم اختيار Playwright لقدرته على كشط المحتوى الديناميكي دون تعقيدات كبيرة. "باستخدام Playwright يمكننا أتمتة المتصفحات بدون واجهة رسومية... للتنقل عبر الويب تماماً مثل الإنسان، مما يجعله رائعاً لكشط مواقع الويب الديناميكية المدعومة بـ JavaScript". وهذا يضمن أن الزاحف يمكنه رؤية الروابط أو عناصر واجهة المستخدم التي يتم إنشاؤها بواسطة البرامج النصية (والتي قد يفوتها زاحف بسيط يعتمد على requests).
سيستخدم وحدة الزحف Playwright في وضع بدون واجهة رسومية لإجراء زحف عميق للموقع المستهدف. الهدف هو اكتشاف المسارات الداخلية (نقاط النهاية) لاختبارها، بما في ذلك تلك التي تظهر فقط بعد تنفيذ JavaScript. نقاط التصميم الرئيسية للزاحف:
التنقل عبر المتصفح بدون واجهة رسومية: قم بتشغيل مثيل متصفح (مثل Chromium) في وضع بدون واجهة رسومية عبر Playwright. استخدم سياق متصفح مع وكيل مستخدم مخصص إذا حدده المستخدم (مزيد من التفاصيل في القسم التالي). على سبيل المثال، يمكننا إنشاء سياق باستخدام browser.new_context(user_agent=<user_agent_string>) لمحاكاة وكيل المستخدم المختار. إذا تم تكوين وكيل، قم بتطبيقه عند التشغيل (يسمح Playwright بتعيين خادم وكيل عند تشغيل المتصفح أو السياق).
استراتيجية الزحف التكراري: ابدأ من عنوان URL أساسي معين (بذرة). استخدم page.goto(base_url, timeout=<T>) لتحميل الصفحة (المهلة قابلة للتكوين). انتظر حتى تهدأ الشبكة أو تأخير قصير للسماح بتحميل المحتوى الديناميكي إذا لزم الأمر. ثم استخرج الروابط. يمكننا استخراج الروابط إما عن طريق:
links = page.evaluate("Array.from(document.querySelectorAll('a[href]'), a => a.href)")، أو<a href>.تصفية الروابط: قم بتصفية الروابط غير الموجودة ضمن النطاق المستهدف (للبقاء داخلياً). أيضاً تجاهل عناوين URL للملفات الثابتة مثل الصور، CSS، JS، إلخ. على سبيل المثال، تخطي أي عنوان URL يحتوي على امتدادات ملفات مثل .css, .js, .jpg, .png, .gif, .svg, .woff إلخ. النهج العملي (المستوحى من قالب ProjectDiscovery) هو تجاهل أي مسار يحتوي على "نقطة" بعد الشرطة المائلة الأولية. لقد استخرجوا نقاط النهاية بنمط regex href=['"](https://github.com/houmanpashaei/cve-2025-29927/blob/HEAD/%5C/%5B%5E.%5C%22%27%5D+)['"] – يلتقط هذا المسارات الداخلية التي لا تحتوي على نقطة (وبالتالي تخطي الأصول). سنقوم بتنفيذ منطق مماثل في الكود لتجنب وضع الموارد الثابتة أو الروابط الخارجية في قائمة الانتظار.
التتبع والتحكم في العمق: حافظ على مجموعة من عناوين URL التي تمت زيارتها لتجنب الحلقات اللانهائية أو التكرار. استخدم طابور (FIFO) لاجتياز الرسم البياني للروابط في الموقع بطريقة BFS. اختيارياً، اسمح للمستخدم بتحديد حد لعمق الزحف أو أقصى عدد من الصفحات للزيارة لمنع التشغيل إلى أجل غير مسمى على المواقع الكبيرة.
المحتوى المعروض بواسطة JavaScript: نظراً لأننا نستخدم متصفحاً حقيقياً، حتى الروابط التي تتم إضافتها إلى DOM بواسطة البرامج النصية (على سبيل المثال، تطبيق React يعرض قائمة بعد جلب البيانات) ستكون مرئية للزاحف. يجب أن نأخذ في الاعتبار النقر أو التفاعل إذا لزم الأمر (على سبيل المثال، إذا كانت بعض الصفحات لا يتم تحميلها إلا بعد إجراء المستخدم). ومع ذلك، للحفاظ على البساطة والسرعة، سيركز التصميم الأولي على جمع روابط href في كل صفحة يتم تحميلها. يمكننا التحسين لاحقاً للتعامل مع أشياء مثل التمرير اللانهائي أو المحتوى خلف النقرات إذا كان التطبيق المستهدف يتطلب ذلك.
الكفاءة: يدعم Playwright تشغيل صفحات/علامات تبويب متعددة بالتوازي باستخدام واجهة برمجة التطبيقات غير المتزامنة. يمكننا إنشاء صفحات متعددة باستخدام asyncio.gather لجلب عدة عناوين URL بشكل متزامن. في التنفيذ الأولي، النهج الأبسط هو الزحف بشكل تسلسلي (وهو أسهل في التنفيذ) والاعتماد على الفحص متعدد الخيوط للأداء. إذا لزم الأمر، يمكن أن يتضمن التحسين المتقدم زحفاً غير متزامن (باستخدام async with async_playwright() وانتظار مكالمات page.goto متعددة). ولكن نظراً لأن أتمتة المتصفح تستهلك موارد أكبر، فإن النهج الحذر هو الاحتفاظ بصفحة متصفح واحدة أو عدد قليل في كل مرة لتجنب إرهاق النظام.
سيقدم البرنامج قائمة تكوين سهلة الاستخدام عند بدء التشغيل، مما يسمح للمستخدم بتخصيص معلمات الفحص أو قبول الإعدادات الافتراضية. يمكن القيام بذلك عبر قائمة وحدة تحكم تفاعلية (باستخدام مطالبات input()) أو عبر وسائط سطر الأوامر (باستخدام argparse للحصول على واجهة CLI أكثر احترافية). تتضمن الخيارات:
وكيل مستخدم مخصص: يمكن للمستخدم تحديد سلسلة وكيل مستخدم مخصصة للزاحف والماسح لاستخدامها. سيتم تطبيق هذا على سياق متصفح Playwright وعلى أي طلبات HTTP مباشرة. يمكن أن يساعد استخدام وكيل مستخدم غير افتراضي في تجنب اكتشاف الروبوتات التافهة. (بشكل افتراضي، قد يستخدم Playwright شيئاً يمكن التعرف عليه؛ يمكننا تجاوزه بسهولة كما هو موضح أعلاه.) على سبيل المثال، قد يقوم المستخدم بإدخال سلسلة تعرف نفسها على أنها Chrome على Windows، والتي نمررها إلى إنشاء سياق Playwright.
مهلة الطلب: يمكن للمستخدم تعيين مهلة (بالثواني) لتحميل الصفحة وطلبات HTTP. يمنع ذلك الماسح من التعلق لفترة طويلة على نقاط النهاية غير المستجيبة. سنطبق هذا الإعداد في page.goto(timeout=...) للزحف، وفي الطلبات (على سبيل المثال، requests.get(timeout=...)) للفحص.
(اختياري) argparse – لتحليل وسائط سطر الأوامر إذا أردنا واجهة CLI بدلاً من قائمة تفاعلية. (وحدة مدمجة)
(اختياري) rich أو colorama – لإخراج وحدة تحكم ملون أو منسق لتحسين القراءة. (التثبيت: pip install rich أو pip install colorama).
إعدادات الوكيل: إذا أراد المستخدم توجيه حركة المرور عبر وكيل (للإخفاء أو للوصول إلى المضيفين الداخليين)، يمكنهم إدخال عنوان URL للوكيل (وبيانات الاعتماد إذا لزم الأمر). سيقوم البرنامج النصي بتكوين متصفح Playwright لاستخدام هذا الوكيل عند التشغيل (على سبيل المثال، browser.launch(proxy={"server": "http://<proxy_host>:<port>", "username": "...", "password": "..."}) كما هو موضح في الأمثلة). وبالمثل، بالنسبة للطلبات، سنقوم بتعيين معلمة proxies (أو متغيرات البيئة) وفقاً لذلك.
الإخراج إلى ملف: ستسأل القائمة ما إذا كان المستخدم يريد حفظ النتائج في ملف (على سبيل المثال، results.txt). إذا كانت الإجابة بنعم، سيقوم البرنامج النصي بكتابة أي نقاط نهاية ضعيفة تم اكتشافها وتفاصيلها في هذا الملف بالإضافة إلى الطباعة على الشاشة. إذا لم يكن الأمر كذلك، فستتم طباعة النتائج فقط إلى stdout. (سنظل نسجل جميع المسارات الممسوحة ضوئياً في سجل مفصل إذا لزم الأمر، لكن الملف سيسجل بشكل خاص الإيجابيات أو التقرير الكامل بناءً على تفضيل المستخدم.)
خيارات أخرى: يمكننا تضمين مفاتيح تشغيل مثل "وضع الإسهاب" لتسجيل التصحيح، أو "أقصى عمق/صفحات للزحف" إذا لزم الأمر. يمكن أن تساعد هذه المستخدم في ضبط الفحص. للنطاق الأولي، الخيارات الأربعة الرئيسية المذكورة أعلاه كافية.
سيتم تنفيذ نظام القائمة في وحدة تكوين/إعداد مخصصة. يمكن أن تكون هذه ببساطة دالة تطبع المطالبات وتجمع الإدخال، مع افتراضيات معقولة إذا ضغط المستخدم على Enter (على سبيل المثال، وكيل مستخدم افتراضي لوكيل قياسي، مهلة افتراضية = 10 ثوانٍ، بدون وكيل، بدون إخراج ملف). هذا يحافظ على وضوح التفاعل ويسمح للبرنامج النصي بالعمل بشكل غير تفاعلي أيضاً (إذا أضفنا لاحقاً وسائط سطر أوامر، يمكننا تجاوز المطالبات التفاعلية من خلال توفير جميع التكوينات اللازمة عبر الوسائط).
الأداء أمر بالغ الأهمية للماسح، خاصة إذا تم العثور على العديد من نقاط النهاية. سيوظف البرنامج النصي التزامن للسرعة، إما من خلال الخيوط المتعددة أو asyncio (أو مزيج):
الفحص متعدد الخيوط: نظراً لأن فحص المسارات المكتشفة (إرسال طلبات HTTP مع headers) هو مهمة مرتبطة بالإدخال/الإخراج، يمكننا استخدام خيوط Python بأمان للتوازي. تطلق عمليات الإدخال/الإخراج قفل المفسر العام، مما يسمح لعدة خيوط بإحراز تقدم في طلبات الشبكة بشكل متزامن. باستخدام concurrent.futures.ThreadPoolExecutor، يمكننا أن يكون لدينا مجموعة من خيوط العمل كل منها يتعامل مع مجموعة فرعية من مهام الفحص. يمكن لهذا تسريع العملية بشكل كبير: على سبيل المثال، تشغيل 5 خيوط بالتوازي يمكن أن يقلل وقت الفحص بمقدار 5 مرات تقريباً، كما هو موضح في سياقات كشط الويب الأخرى. سنسمح بأن يكون عدد الخيوط قابلاً للتكوين أو نختار افتراضياً معقولاً (مثل 10 خيوط) يوازن بين السرعة وتحميل الخادم. كل خيط سيأخذ عناوين URL من طابور مشترك لنقاط النهاية المراد اختبارها.
بديل Asyncio: بدلاً من ذلك، يمكن استخدام نهج غير متزامن، خاصة إذا تم استخدام Playwright في الوضع غير المتزامن أو httpx لطلبات HTTP. يمكننا await العديد من الطلبات في وقت واحد. على سبيل المثال، يمكن لـ httpx.AsyncClient إرسال العديد من الطلبات بشكل متزامن وجمع النتائج. هذا النهج يتجنب عبء الخيوط ويمكن أن يكون فعالاً جداً لعدد كبير من نقاط النهاية. ومع ذلك، قد يؤدي خلط asyncio مع Playwright (الذي يمكن استخدامه بشكل غير متزامن أيضاً) إلى تعقيد الأمور. الحل العملي هو استخدام الخيوط لمرحلة فحص HTTP (نظراً لأن الزحف باستخدام Playwright قد يكون أسهل في الإدارة في الوضع المتزامن).
الزحف المتزامن: يجب أن نأخذ في الاعتبار أيضاً موازاة الزحف إذا كان الموقع كبيراً. يمكن لـ Playwright فتح عدة صفحات في وقت واحد باستخدام سياق غير متزامن. قد ننفذ تزامناً محدوداً (على سبيل المثال، 2-3 صفحات في كل مرة) للزحف. على سبيل المثال، عندما نستخرج عناوين URL جديدة، يمكننا فتح صفحة جديدة لكل منها إذا كنا نستخدم asyncio. يمكن أن يكون هذا تحسيناً متقدماً إذا لزم الأمر. في البداية، الزحف أحادي الخيط أبسط ومناسب لأحجام المواقع المعتدلة، لكن التصميم يمكن أن يلاحظ هذا كنقطة تحسين.
أمان الخيوط: سنضمن معالجة آمنة للخيوط للبيانات المشتركة. يمكن معالجة قائمة عناوين URL المراد فحصها باستخدام ThreadPoolExecutor.map للبساطة، أو يمكننا استخدام طابور آمن للخيوط (queue.Queue في Python) وجعل الخيوط تسحب منه حتى يصبح فارغاً. مجموعة visited للزحف يتم الوصول إليها فقط بواسطة الزاحف (خيط واحد، ما لم نقم بالزحف المتزامن). ستقرأ خيوط الماسح فقط من قائمة عناوين URL الخاصة بهم (لا تعديل هياكل مشتركة باستثناء تسجيل النتائج، والذي يمكننا حمايته بقفل أو جمعه في قائمة آمنة للخيوط).
تحديد السرعة واللباقة: نظراً لأن هذه أداة اختبار أمان، فإن السرعة هي أولوية، لكننا قد نرغب أيضاً في تجنب إرهاق الهدف. يمكن نصح المستخدم بتعيين عدد خيوط معقول. يمكننا أيضاً تنفيذ تأخير صغير أو استخدام semaphores للحد من التزامن إذا لزم الأمر. على سبيل المثال، قد لا نطلق جميع الخيوط مرة واحدة إذا كانت شبكة المستخدم أو الخادم قد تختنق. في سيناريو متقدم، يمكن أن يستخدم النهج غير المتزامن semaphore للسماح، على سبيل المثال، بـ 5 طلبات متزامنة في كل مرة. يمكن تعديل هذه التفاصيل بناءً على اختبار أداء البرنامج النصي.
باختصار، سيتم تطبيق التزامن بشكل أساسي على مرحلة الفحص لاختبار نقاط نهاية متعددة بالتوازي. هذا يجعل الماسح أسرع بكثير دون التضحية بالدقة (نظراً لأن كل طلب مستقل). كما تشير إحدى المراجع، "يمكن أن تعطي الخيوط المتعددة مع concurrent.futures دفعة كبيرة هنا. يمكننا تنفيذ مهام الإدخال/الإخراج بشكل متزامن عبر خيوط متعددة ورؤية تسريع كبير". الخيوط المتعددة مناسبة هنا لأن المهام المرتبطة بالشبكة تستفيد منها حتى في Python.
قلب البرنامج النصي هو وحدة الفحص، التي تأخذ قائمة نقاط النهاية المكتشفة (المسارات) وتتحقق من كل منها لوجود علامات ثغرة CVE-2025-29927. ستكون العملية لكل نقطة نهاية:
x-middleware-rewrite, x-middleware-next، أو x-middleware-redirect، فهذا يشير إلى أن هذا المسار محمي بواسطة وسيطة. نتحقق أيضاً مما إذا كانت الحالة ليست 200 (مما يعني تم رفض الوصول أو إعادة التوجيه)، لأن هذه هي تلك التي من المحتمل تجاوزها. (إذا كانت الحالة بالفعل 200 ويتم تحميل المحتوى بشكل طبيعي، فإما أنها صفحة عامة أو أن الثغرة لا تنطبق؛ قد نختبرها مع ذلك، لكن الاهتمام الحقيقي هو بالصفحات المحمية.)X-Middleware-Subrequest. سنحاول مجموعة متنوعة من قيم header لضمان الكشف عبر إصدارات Next.js:قيمة عامة مثل "1" أو "true" (تشير بعض المصادر إلى أن مجرد تعيين header إلى أي قيمة يؤدي إلى التخطي).
الحمولة المحددة المستخدمة في الاستغلالات العامة، على سبيل المثال "middleware:middleware:middleware:middleware:middleware" (خمس تكرارات لـ "middleware"). يُعرف أن هذا يحفز التجاوز لأحدث الإصدارات (13+). سنقوم بتضمين هذه القيمة بالضبط.
الحمولة البديلة للمشاريع التي تستخدم دليل /src، على سبيل المثال "src/middleware:src/middleware:src/middleware:src/middleware:src/middleware"
اختيارياً، قيم أحادية المقطع مثل "middleware" أو "src/middleware" للاكتمال (قد تستخدم إصدارات Next.js الأقدم ملف _middleware في دليل الصفحات، مع حمولة مطلوبة مختلفة قليلاً، لكن الحمولات متعددة المقاطع أعلاه تغطي الحالات المعروفة إلى حد كبير).
سيتم تنفيذ كل من هذه الطلبات مع تعيين header المخصص. نضمن أيضاً استخدام نفس الطريقة (GET) وتضمين أي headers من الأساس قد تكون مطلوبة (مثل ملفات تعريف الارتباط أو رموز المصادقة إذا قدمها المستخدم لأي فحص مسجل الدخول، على الرغم من أننا عادةً نفحص بدون مصادقة).
إذا كان الأساس هو خطأ أو إعادة توجيه (على سبيل المثال، 401 غير مصرح، 403 ممنوع، أو إعادة توجيه إلى تسجيل الدخول) و إحدى الاستجابات المحقونة بـ header هي 200 OK مع نص أكبر بكثير (أو تشير بطريقة أخرى إلى تحميل الصفحة)، فهذا مؤشر قوي على الثغرة. على سبيل المثال، إذا كان /admin يعيد 403 بشكل طبيعي، ولكن مع header يعيد 200 ويحتوي على HTML لوحة التحكم الإدارية، فإننا نضع علامة عليه.
في بعض الحالات، قد يكون الفرق هو 302 مقابل 200، أو 404 مقابل 200. سنعتبر تغيير رمز الحالة من غير 200 إلى 200 علامة محتملة. أيضاً، إذا ظلت الحالة 200 لكن طول المحتوى تغير بشكل كبير، فقد يشير ذلك إلى أن header غير السلوك (أقل شيوعاً لهذا العيب المعين، لكنه احتمال إذا كانت الصفحة تقدم عادةً شيئاً وبعد header تقدم شيئاً آخر).
سننفذ فحوصات مثل: if base_status_code != 200 and test_status_code == 200: (وربما أيضاً نتأكد من أن test_body_length > base_body_length أو يحتوي على كلمة رئيسية مصادق عليها) ثم ضع علامة على أنها ضعيفة. إذا كان الأساس عبارة عن إعادة توجيه (على سبيل المثال، 307 إلى /login)، والاختبار أدى إلى 200، ضع علامة أيضاً. بشكل أساسي، "هل تم رفض الوصول سابقاً ولكن مسموح به الآن؟".
إذا كانت حالة الاستجابة مع header هي 404 أو 500 حيث كان الأساس عبارة عن إعادة توجيه، فقد يكون هذا سيناريو تسميم ذاكرة التخزين المؤقت (تجاوز إعادة توجيه الوسيطة مما تسبب في 404 في الأصل). من الصعب اكتشاف هذا السيناريو بطلب واحد فقط، لكن وجود 404 مع header عندما كان الأساس إعادة توجيه قد يتم ملاحظته أيضاً (على الرغم من أنه ليس تجاوزاً للمصادقة، إلا أنه لا يزال تأثيراً للثغرة). لكن تركيزنا مع ذلك على اكتشاف تجاوز المصادقة (وصول 200 OK).
results.txt إذا اختار المستخدم حفظ النتائج. يجب أن نصغف ذلك بوضوح، على سبيل المثال:[*] /admin -> baseline 403, with X-Middleware-Subrequest (payload X) got 200 [VULNERABLE]
يمكننا أيضاً طباعة شيء مثل طول الاستجابة أو مقتطف من الاستجابة للتأكيد (ربما الطول للاختصار، على سبيل المثال، "len: 0 -> 10240 bytes"). إذا تم تجربة عدة حمولات، يمكننا سرد أي منها نجح.
إذا بدا أن الموقع ليس تطبيق Next.js على الإطلاق (على سبيل المثال، لم نعثر على أي /_next/static/ في الصفحة الرئيسية، وهي علامة مميزة)، قد نخرج ملاحظة: "لم يتم العثور على مؤشرات Next.js، قد لا يكون الهدف يستخدم Next.js – على الأرجح غير ضعيف." لكن لا يزال بإمكاننا المتابعة بشكل عام، لأن التحقق من Next.js هو تحسين وليس ضرورة.سيتم تغليف هذا المنطق بشكل نظيف. على سبيل المثال، قد يكون لدينا دالة scan_endpoint(url, session, header_payloads) ترجع كائن نتيجة أو قاموسًا يحتوي على ما إذا كان العرضة موجودة والتفاصيل. سنقوم بتضمين فحوصات قوية لتجنب النتائج الإيجابية الخاطئة. تحديدًا، يتطلب تغيير رمز الحالة إلى 200 (أو دليل واضح آخر) لضمان أننا نضع علامة فقط على عمليات التحايل الفعلية. كما هو مذكور في تحليل ProjectDiscovery، يفحص الماسح رمز الحالة 200 عند تضمين الرأس الخاص لتأكيد الثغرة.
يجب أن يكون ناتج النص البرمجي سهل القراءة والتفسير، مع إمكانية حفظه اختياريًا في ملف. سنقوم بتنسيق مخرجات وحدة التحكم باستخدام عناوين واضحة ومسافات بادئة عند الاقتضاء. بعض الاعتبارات:
بعد الفحص، اطبع ملخص النتائج. على سبيل المثال: “اكتمل الفحص: تم العثور على 3 نقاط نهاية عرضة (من أصل 45 تم اختبارها).” ثم أدرج نقاط النهاية العرضة مع التفاصيل.
استخدم تنسيقًا ثابتًا لكل سطر نتيجة، كما هو موضح أعلاه، وربما باستخدام وسوم [VULNERABLE] لجذب الانتباه. إذا كنت تستخدم مكتبة مثل rich، فيمكننا تلوين “VULNERABLE” باللون الأحمر أو الأصفر. حتى بدون مكتبات إضافية، يمكننا استخدام رموز ANSI عبر colorama للتمييز، أو مجرد نص بأحرف كبيرة.
إذا لم يتم العثور على أي ثغرات، اذكر ذلك صراحةً: “لم يتم اكتشاف أي ثغرات لـ CVE-2025-29927.”
إذا كان سيتم حفظ النتائج، تأكد من كتابتها بتنسيق مشابه للملف. ربما بطريقة أكثر تفصيلًا أو بصيغة CSV للاستخدام البرمجي، ولكن نظرًا لأن المستخدم ذكر ملفًا نصيًا على وجه التحديد، فمن المحتمل أن نكتب نفس السطور في results.txt.
أيضًا، يمكن الإبلاغ عن أي أخطاء أو استثناءات حرجة (مثل عدم القدرة على تحميل صفحة معينة) في المخرجات بطريقة مهذبة (بدلاً من تتبع المكدس). يمكننا التقاط الاستثناءات وطباعة تحذير من سطر واحد لكل عنوان URL فاشل: على سبيل المثال، “انتهت مهلة تحميل /blog (تم التخطي)”. بهذه الطريقة، يعرف المستخدم إذا لم يتم اختبار بعض المسارات.
طوال عملية التنفيذ، قد نظهر مؤشر تقدم أو شريط تقدم (للجري لمسافات طويلة) أو على الأقل نطبع الصفحة التي يتم الزحف إليها أو نقطة النهاية التي يتم اختبارها، إذا كان الوضع المفصل قيد التشغيل. للحصول على مخرجات أنظف، قد نعرض فقط الحالات العرضة المكتشفة في النهاية، ولكن سجل التشغيل (ربما بالكتابة إلى ملف سجل منفصل) يمكن أن يساعد في الشفافية.
نظرًا للتركيز على التنسيق الواضح، قد يساعد استخدام النقاط النقطية أو تخطيط الجدول عند طباعة نتائج متعددة:
يمكننا عمل جدول كالتالي: Endpoint | Base Status | Base Length | Bypass Status | Bypass Length | HeaderValueUsed | Result
ومع ذلك، قد يكون نموذج الجملة البسيط أكثر قابلية للقراءة لمجموعة واسعة من المستخدمين. سنضمن أن كل نتيجة في سطر جديد وموسومة بوضوح.
من خلال توفير كل من المخرجات على الشاشة وحفظ الملف الاختياري، تكون الأداة مفيدة لكل من الاستخدام التفاعلي والفحص الآلي (حيث يمكن للمستخدم مراجعة الملف لاحقًا أو دمجه في التقارير).
لجعل النص البرمجي قابلًا للصيانة وبجودة احترافية، سنقوم بتنظيم الكود في وحدات، كل منها يتعامل مع جانب مميز من الوظائف. هيكل مشروع محتمل:
crawler.py: يحتوي على منطق الزحف باستخدام Playwright. ستحتوي على دوال مثل crawl_site(start_url, config) -> List[str] ترجع قائمة بالمسارات الداخلية المكتشفة. ستتعامل هذه الوحدة مع تشغيل المتصفح، استرجاع الصفحات، استخراج الروابط، وفرض عوامل التصفية (النطاق، استبعاد الملفات الثابتة). يمكنها أيضًا استضافة منطق مساعد لتطبيع عناوين URL (على سبيل المثال، إزالة أجزاء URL، معالجة المسارات النسبية عبر urllib.parse.urljoin).
scanner.py: يحتوي على منطق فحص الثغرة. ستشمل دوال مثل scan_paths(url_list, config) -> List[ScanResult]. سيتولى هذا إدارة إنشاء طلبات HTTP (باستخدام requests.Session أو عميل httpx)، تطبيق الرؤوس، مقارنة الاستجابات، وجمع النتائج. إذا تم استخدام تعدد الخيوط، فستقوم هذه الوحدة بإنشاء ThreadPool وإدارة المهام. قد تحدد فئة بيانات صغيرة ScanResult لحفظ معلومات حول كل مسار (المسار، vulnerable: bool، التفاصيل).
config.py (أو settings.py): يحتوي على كود القائمة والتكوين للمستخدم. على سبيل المثال، دالة get_user_config() تتفاعل مع المستخدم وتعيد كائن/قاموس تكوين يحتوي على جميع الإعدادات المختارة (user_agent، timeout، proxy، علامة output_file، إلخ). إذا تم استخدام وسائط سطر الأوامر، يمكن لهذه الوحدة بدلاً من ذلك تحليل argparse.ArgumentParser. بشكل أساسي، يعزل هذا الجزء جميع مدخلات المستخدم ومعالجة التكوين.
utils.py: دوال مساعدة، مثل طباعة الشعارات، تنسيق سلاسل المخرجات، معالجة المخرجات الملونة، أو مساعد شائع مثل is_static_resource(url) (للتحقق مما إذا كان عنوان URL يشير على الأرجح إلى ملف ثابت). أيضًا، يمكن تضمين دالة للإغلاق المهذب (يتم استدعاؤها على SIGINT).
main.py: البرنامج النصي نقطة الدخول الذي يربط كل شيء معًا. سيقوم بما يلي:
config.py).main مجرد أسفل ملف واحد، ولكن من أجل النظافة، يفضل الفصل.سيتم تصميم كل وحدة لتكون معيارية وقابلة لإعادة الاستخدام. على سبيل المثال، يمكن للمرء إعادة استخدام crawler.py للحصول على روابط الموقع لأغراض أخرى، أو إعادة استخدام scanner.py لاختبار هذه الثغرة على قائمة معينة من عناوين URL (حتى بدون الزحف).
معالجة الاستثناءات والإغلاق المهذب: سنقوم بتنفيذ معالجة استثناءات قوية:
أحط عمليات الشبكة بـ try/except (التقاط انتهاء المهلة، أخطاء الاتصال، إلخ). إذا فشل الزحف إلى الصفحة، سجله واستمر مع الآخرين. إذا فشل طلب الفحص (على سبيل المثال، خطأ وكيل)، ضع علامة على نقطة النهاية تلك كخطأ ولكن استمر في فحص الباقي.
استخدم كتل finally أو مديري السياق لضمان تنظيف الموارد. على سبيل المثال، استخدم سياق async_playwright() أو تأكد من استدعاء browser.close() في نهاية الزحف. وبالمثل، تأكد من إغلاق مقابض الملفات بعد الكتابة.
معالجة KeyboardInterrupt (Ctrl+C): يمكننا اعتراض KeyboardInterrupt في الحلقة الرئيسية وبدء إغلاق مهذب – على سبيل المثال، اطبع “جارٍ الإيقاف والتنظيف…”، أوقف الخيوط (ربما باستخدام ThreadPoolExecutor.shutdown(wait=False) لوقف تشغيل المهام الجديدة)، وأغلق المتصفح. هذا يمنع العمليات اليتيمة أو الملفات المقفلة إذا ألغى المستخدم.
استخدم التسجيل لرسائل التصحيح (ربما عبر مكتبة logging الخاصة بلغة Python). في أداة احترافية، سيكون لديك مستويات تسجيل؛ على سبيل المثال، يمكن أن تتضمن سجلات التصحيح كل طلب تم إجراؤه، بينما يعرض مستوى المعلومات فقط التقدم عالي المستوى. يمكن للمستخدم تعيين علامة verbose لتبديل ذلك. افتراضيًا، قد نسجل حدًا أدنى من المعلومات حتى لا نطغى على المخرجات.
جودة الكود: سنلتزم بأفضل ممارسات البرمجة:
اتبع إرشادات نمط PEP8 من أجل قابلية القراءة.
استخدم أسماء دوال ومتغيرات ذات مغزى.
أضف docstrings للدوال تشرح الغرض منها واستخدامها.
استخدم تلميحات النوع لتوقيعات الدوال (تعليقات نوع Python 3) لجعل الكود أسهل في الفهم وللقبض على مشاكل النوع مبكرًا.
نمطية الثوابت (مثل قائمة حمولات الرأس، قوائم امتدادات الملفات الثابتة لتجاهلها، إلخ) في الأعلى أو في تكوين، بحيث يمكن تحديثها بسهولة. على سبيل المثال، HEADER_PAYLOADS = ["middleware:middleware:...","src/middleware:..."] إلخ، معرفة في مكان واحد.
ربما تضمين اختبارات وحدة لبعض الدوال المساعدة (إذا كان هذا مشروعًا أكبر، على الرغم من أنه بالنسبة لأداة برنامج نصي واحد قد يتم تخطي ذلك؛ ومع ذلك، فإن التصميم مع وضع قابلية الاختبار في الاعتبار مفيد).
تحسينات بمستوى احترافي: لجعل النص البرمجي أكثر متانة وجاهزية للإنتاج، يمكننا أيضًا النظر في:
دعم المصادقة: السماح للمستخدم بتوفير الكوكيز أو بيانات الاعتماد إذا كانوا يرغبون في مسح قسم مصادق عليه من الموقع (على الرغم من أن الثغرة تتعلق بتجاوز المصادقة، قد يكون هناك سيناريوهات حيث تحتاج إلى تسجيل الدخول أولاً للوصول إلى روابط معينة ثم اختبار التحايل عليها – على الرغم من أن التحايل يعمل على الأرجح دون مصادقة صالحة، ولكن هذا يمكن أن يساعد في الزحف إلى الروابط العميقة غير العامة).
ملف التكوين: بدلاً من (أو بالإضافة إلى) الإدخال التفاعلي، السماح بقراءة الخيارات من ملف تكوين أو متغيرات بيئة، وهو مفيد للنشر الآلي للماسح.
تنسيقات المخرجات: توفير مخرجات بصيغ متعددة مثل JSON أو CSV للتكامل مع أدوات أخرى. على سبيل المثال، يمكن لعلم --json تفريغ النتائج كـ JSON قابل للقراءة آليًا.
التكامل مع الأطر الحالية: يمكن دمج المنطق في إطار مسح أكبر (على سبيل المثال، تحويله إلى وحدة لـ OWASP ZAP أو التكامل مع Nuclei الخاص بـ ProjectDiscovery عن طريق إخراج تقرير متوافق). على الأقل، تأكد من أن ناتج البرنامج النصي يحدد بوضوح الثغرة وعناوين URL المتأثرة بحيث يمكن استخدامه في التقارير.
جلسات المتصفح المتوازية: إذا كان الهدف تطبيقات كبيرة جدًا، فكر في تشغيل سياقات متصفح متعددة بالتوازي للزحف إلى أقسام مختلفة في وقت واحد. يمكن لـ Playwright التعامل مع سياقات متعددة (كل سياق معزول، يشبه ملفات تعريف المتصفح المنفصلة). هذا يمكن أن يسرع الزحف بشكل كبير على حساب استخدام أعلى للموارد.
التدهور المهذب: إذا فشل Playwright (على سبيل المثال، تفتقر البيئة إلى شاشة عرض أو تثبيت مناسب)، يمكن أن يتراجع البرنامج النصي إلى زحف أبسط قائم على الطلبات (قد يفوت بعض الروابط ولكنه أفضل من لا شيء). هذا يجعل الأداة أكثر متانة في بيئات مختلفة. وبالمثل، إذا تم تعيين التزامن على مستوى عالٍ جدًا وتسبب في مشاكل، فالتقطها واقترح على المستخدم خفض عدد الخيوط.
باتباع هيكل نظيف وهذه الممارسات الجيدة، سيكون البرنامج النصي أسهل في الصيانة والتوسيع. يمكن العمل على كل مكون بشكل مستقل – على سبيل المثال، تحسين قدرة الزاحف على تحليل التنقل المعتمد على JavaScript، أو تحديث الماسح بتغيرات جديدة لحمولات الرأس إذا وجد بحث مستقبلي أنماط استغلال إضافية.
في الختام، يوضح هذا التصميم نهجًا شاملاً للكشف عن CVE-2025-29927 في تطبيقات الويب. يستخدم متصفحًا بدون رأس للزحف العميق، وتعدد الخيوط للمسح الفعال، وممارسات برمجة قوية للموثوقية. من خلال مقارنة الاستجابات مع وبدون الرأس الخاص، يمكنه تحديد نقاط النهاية العرضة بشكل موثوق حيث يتم تجاوز برنامج وسيط Next.js. والنتيجة هي أداة بمستوى احترافي تساعد مهندسي الأمن والمطورين في العثور بسرعة على هذه الثغرة الحرجة ومعالجتها في تطبيقاتهم.