clickswave/vuln_appsजानबूझकर असुरक्षित वेब/API ऐप्स का एक बेड़ा पृथक Docker स्टैक में चलाता है, जो स्थानीय पेनेट्रेशन टेस्टिंग और ग्राउंड-ट्रुथ भेद्यता कैटलॉग के साथ स्कैनर परिणामों को मान्य करने के लिए उपयोग किया जाता है।
सुरक्षा टूलिंग (crossfyre, Burp, ZAP, nuclei, आदि) को निशाना बनाने के लिए जानबूझकर कमज़ोर ऐप्स का एक बेड़ा। इस फ़ोल्डर में कोई ऐप स्रोत नहीं है, केवल स्केलेटन परिभाषाएँ और एक छोटा मैनेजर है। प्रत्येक ऐप अपने स्वयं के पृथक कंटेनर स्टैक के रूप में चलता है, इसलिए कोई टकराव नहीं होता।
यहाँ सब कुछ जानबूझकर कमज़ोर है। केवल स्थानीय परीक्षण। इन्हें इंटरनेट या अविश्वसनीय नेटवर्क पर एक्सपोज़ न करें। सभी पोर्ट
127.0.0.1से बंधते हैं।
docker compose up एक कंटेनर शुरू करता है: vuln_apps_manager (कंट्रोल प्लेन)। यह अपने आप कोई vuln ऐप शुरू नहीं करता।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 का create-database, bWAPP का install, VAmPI का seed), इसलिए जिस क्षण यह 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
| Command | यह क्या करता है |
|---|---|
./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 | इमेज pre-pull करें |
./vam ports | होस्ट-पोर्ट मैप + टकराव जाँच |
./vam doctor | पर्यावरण + पोर्ट सैनिटी जाँचें |
उदाहरण: ./vam start juice-shop dvwa, ./vam start crapi --heavy, ./vam logs webgoat -f।
सभी URL http://127.0.0.1:<port> हैं (केवल loopback)।
| App | Port | Stack | Notes |
|---|---|---|---|
| juice-shop | 7001 | Node / Angular | आधुनिक SPA + REST |
| dvwa | 7002 | PHP / MariaDB | आरंभ पर DB स्वतः निर्मित; लॉगिन admin/password |
| webgoat | 7003 | Java | + 7004 पर WebWolf (OOB कैचर) |
| vampi | 7005 | Python / Flask | OWASP API Top 10 |
| dvga | 7006 | Python / GraphQL | /graphql |
| bwapp | 7007 | PHP | आरंभ पर स्वतः इंस्टॉल; लॉगिन bee/bug |
| log4shell | 7009 | Java / Spring | blind-RCE -> OAST |
| crapi | 7010 | Node/Java/Python | heavy; 7011 पर mailhog |
| 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)
नियम जो बेड़े को स्वच्छ रखते हैं:
[vuln-net] पर रखें। प्रति-प्रोजेक्ट नेटवर्क न जोड़ें - इससे Docker का एड्रेस पूल संरक्षित रहता है (बहुत सारे नेटवर्क होने पर Docker "all predefined address pools have been fully subnetted" त्रुटि के साथ विफल हो जाता है)।[default, vuln-net] पर और DB को केवल [default] पर रखें (निजी, कोई होस्ट बाइंडिंग नहीं)। प्रत्येक ऐप को उसकी अपनी DB सेवा और वॉल्यूम दें (साझा न करें)। vuln-net को external: true घोषित करें।apps/<name>/setup.sh जोड़ें। मैनेजर इसे start के बाद, मैनेजर कंटेनर के अंदर से चलाता है (जो vuln-net पर है और जिसमें curl है), ताकि यह सेवा नाम से ऐप तक पहुँच सके, जैसे curl http://<service>/install.php।बस इतना ही। मैनेजर इसे स्वचालित रूप से पहचान लेता है (./vam list)।
उस ऐप के लिए जिसका स्रोत git repo में रहता है (जैसे faultline), compose.yml छोड़ें और इसके बजाय app.yml में repo: (क्लोन URL) और compose: (उस repo के अंदर compose पथ) रखें। मैनेजर पहली बार start करने पर इसे apps/<name>/src/ (gitignored) में क्लोन करता है, इसलिए यहाँ कोई स्रोत वेंडर नहीं किया गया है।
vulns/ में प्रति-ऐप "answer key" (उत्तर कुंजी) होती है (प्रत्येक टारगेट किसके प्रति कमज़ोर माना जाता है), ताकि आप स्कैनर के निष्कर्षों को ग्राउंड ट्रुथ के विरुद्ध जाँच सकें। vulns/README.md देखें। faultline और crapi के लिए विस्तृत स्थानीय कैटलॉग मौजूद हैं; अपस्ट्रीम ऐप अपनी स्वयं की आधिकारिक उत्तर कुंजियों की ओर इंगित करते हैं।
crAPI Postgres + Mongo + तीन ऐप टियर (~2 GB) चलाता है, इसलिए --all इसे छोड़ देता है। इसे स्पष्ट रूप से शुरू करें: ./vam start crapi --heavy। पहला बूट धीमा है; साइन-अप OTP और रीसेट मेल http://127.0.0.1:7011 पर mailhog में जाते हैं।
faultline Clickswave का अपना फुल-स्टैक टारगेट है। इसका स्रोत यहाँ नहीं वेंडर किया गया है; मैनेजर पहली बार start करने पर इसे github.com/clickswave/faultline से क्लोन करता है:
./vam start faultline # clones the repo into apps/faultline/src/, then builds + runs it
पहला start इसे बिल्ड करता है (Rust; धीमा)। बाद में ./vam pull faultline से चेकआउट अपडेट करें। फिर http://127.0.0.1:8088 खोलें। डेमो लॉगिन: [email protected] / password, [email protected] / admin।
docker compose down केवल मैनेजर को रोकता है। पहले ऐप्स को ./vam stop --all से रोकें (वे अलग प्रोजेक्ट हैं)।