clickswave/vuln_appsيشغّل أسطولًا من تطبيقات الويب/API المعرّضة للثغرات عن قصد في حِزم Docker معزولة لاختبار الاختراق المحلي والتحقق من نتائج الماسحات الضوئية باستخدام كتالوجات ثغرات مرجعية موثوقة (ground-truth).
أسطول من التطبيقات المعرّضة للثغرات عمدًا لتوجيه أدوات الأمان إليها (crossfyre، Burp، ZAP، nuclei، وما إلى ذلك). لا يحتوي هذا المجلد على أي كود مصدري للتطبيقات، فقط تعريفات هيكلية ومدير صغير. يعمل كل تطبيق كحزمة حاويات معزولة خاصة به، فلا يحدث أي تعارض.
كل شيء هنا معرّض للثغرات عمدًا. للاختبار المحلي فقط. لا تعرّض هذه التطبيقات للإنترنت أو لشبكة غير موثوقة. جميع المنافذ ترتبط بـ
127.0.0.1.
docker compose up يشغّل حاوية واحدة: vuln_apps_manager (لوحة التحكم). وهو لا يشغّل أي تطبيق من تطبيقات الثغرات بمفرده.apps/<name>/ (ملف بيان app.yml + ملف compose.yml) ويُشغَّله المدير كمشروع docker compose منفصل خاص به.127.0.0.1. قواعد البيانات والطبقات الداخلية لا تُربط بالمضيف أبدًا. كما تنضم خدمة الويب لكل تطبيق إلى شبكة مشتركة vuln-net، بحيث يمكن لماسح ضوئي يعمل داخل حاوية الوصول إليها بالاسم (مثل http://dvwa) دون أي منفذ مضيف إطلاقًا.cd vuln_apps
./vam start --all # ONE command: builds the manager, starts every light app,
# and runs each app's first-time setup automatically
./vam status # what's running + URLs
./vam stop --all # stop everything
ينفّذ الأمر الواحد ./vam start --all أيضًا الإعداد لمرة واحدة الذي يحتاجه كل تطبيق (إنشاء قاعدة بيانات DVWA، تثبيت bWAPP، بذر VAmPI)، لذا يكون كل تطبيق قابلًا للاستخدام فور إبلاغه عن حالة running — دون أي نقرات يدوية على /setup.php أو /install.php.
هل تريد أن يبقى المدير نشطًا كمراقب حالة مباشر؟ شغّل docker compose up -d أولًا، ثم استخدم ./vam ... كما هو موضح أعلاه.
./vam <cmd> هو مجرد غلاف. نفس الأمر تمامًا بدونه:
docker compose run --rm vuln_apps_manager start --all
docker compose run --rm vuln_apps_manager status
| الأمر | الوظيفة |
|---|---|
./vam list | يسرد كل التطبيقات وحالتها وعنوان URL |
./vam start <app...> | --all [--heavy] | تشغيل تطبيق (تطبيقات). يتخطى --all التطبيقات الثقيلة ما لم يُمرَّر --heavy |
./vam stop <app...> | --all | إيقاف تطبيق (تطبيقات) |
./vam restart <app...> | --all | إعادة تشغيل تطبيق (تطبيقات) |
./vam status | جدول حالة الأسطول |
./vam logs <app> [-f] | متابعة سجلات تطبيق |
./vam pull <app...> | --all | سحب الصور مسبقًا |
./vam ports | خريطة منافذ المضيف + فحص التعارض |
./vam doctor | فحوصات سلامة البيئة والمنافذ |
أمثلة: ./vam start juice-shop dvwa، ./vam start crapi --heavy، ./vam logs webgoat -f.
جميع العناوين هي http://127.0.0.1:<port> (عبر الحلقة المحلية فقط).
| التطبيق | المنفذ | الحزمة التقنية | ملاحظات |
|---|---|---|---|
| juice-shop | 7001 | Node / Angular | تطبيق SPA حديث + REST |
| dvwa | 7002 | PHP / MariaDB | قاعدة البيانات تُنشأ تلقائيًا عند التشغيل؛ تسجيل الدخول admin/password |
| webgoat | 7003 | Java | + WebWolf على 7004 (لالتقاط اتصالات خارج النطاق OOB) |
| vampi | 7005 | Python / Flask | OWASP API Top 10 |
| dvga | 7006 | Python / GraphQL | /graphql |
| bwapp | 7007 | PHP | يُثبَّت تلقائيًا عند التشغيل؛ تسجيل الدخول bee/bug |
| log4shell | 7009 | Java / Spring | تنفيذ أوامر عن بُعد أعمى -> OAST |
| crapi | 7010 | Node/Java/Python | ثقيل؛ mailhog على 7011 |
| faultline | 8088 | SvelteKit/Rust/PG/Redis | يُجلب من GitHub (انظر أدناه) |
كتلة منافذ المضيف المحجوزة: 7001-7099. يعرض ./vam ports الخريطة المباشرة ويشير إلى أي تعارض.
ضع مجلدًا تحت apps/:
apps/<name>/
app.yml # name, description, category, stack, url
compose.yml # the container(s): image, ports (127.0.0.1 only), any DB
setup.sh # optional: one-time init run after start (see below)
القواعد التي تحافظ على نظافة الأسطول:
127.0.0.1:<منفذ 70xx حر>.[vuln-net] فقط. لا تُضف شبكة لكل مشروع — فهذا يحافظ على تجمع عناوين Docker (فالكثير من الشبكات يجعل Docker يفشل برسالة "all predefined address pools have been fully subnetted").[default, vuln-net] وقاعدة البيانات على [default] فقط (خاصة، دون ربط بالمضيف). امنح كل تطبيق خدمة قاعدة بيانات خاصة به وحجم تخزين خاصًا به (لا تشاركهما). صرّح عن vuln-net بأنها external: true.apps/<name>/setup.sh. يشغّله المدير بعد start، من داخل حاوية المدير (الموجودة على vuln-net وفيها curl)، ليتمكن من الوصول إلى التطبيق باسم الخدمة، مثل curl http://<service>/install.php.هذا كل شيء. يلتقطه المدير تلقائيًا (./vam list).
بالنسبة لتطبيق مصدره في مستودع git (مثل faultline)، تخطَّ compose.yml وضع بدلًا من ذلك repo: (رابط الاستنساخ) وcompose: (مسار compose داخل ذلك المستودع) في app.yml. يستنسخه المدير إلى apps/<name>/src/ (مستثنى من git) عند أول تشغيل، فلا يُضمَّن أي كود مصدري هنا.
يحتوي vulns/ على "مفتاح إجابة" لكل تطبيق (ما يُفترض أن يكون كل هدف معرّضًا له من الثغرات)، بحيث يمكنك التحقق من نتائج الماسح الضوئي مقابل الحقيقة المرجعية. انظر vulns/README.md. توجد كتالوجات محلية مفصّلة لكل من faultline وcrapi؛ بينما تشير التطبيقات الأصلية إلى مفاتيح الإجابة المعتمدة الخاصة بها.
يشغّل crAPI قواعد بيانات Postgres + Mongo وثلاث طبقات تطبيق (حوالي 2 غيغابايت)، لذا يتخطاه --all. شغّله صراحةً: ./vam start crapi --heavy. أول إقلاع بطيء؛ تصل رسائل رمز OTP للتسجيل ورسائل إعادة التعيين إلى mailhog على http://127.0.0.1:7011.
faultline هو هدف full-stack الخاص بـ Clickswave. مصدره غير مضمّن هنا؛ يستنسخه المدير من github.com/clickswave/faultline عند أول تشغيل:
./vam start faultline # clones the repo into apps/faultline/src/, then builds + runs it
أول تشغيل يبنيه (Rust؛ بطيء). حدّث النسخة لاحقًا عبر ./vam pull faultline. ثم افتح http://127.0.0.1:8088. بيانات دخول تجريبية: [email protected] / password، [email protected] / admin.
docker compose down يوقف المدير فقط. أوقف التطبيقات أولًا عبر ./vam stop --all (فهي مشاريع منفصلة).