एक्सपोज़र-संरक्षित सुरक्षा स्कैनिंग के लिए कंटेंट-ब्लाइंड रिवर्स प्रॉक्सी
कंटेंट-ब्लाइंड सुरक्षा स्कैनिंग के लिए एक स्थानीय रिवर्स प्रॉक्सी।
Go · स्थानीय HTTPS · HTTP और WebSocket · Tor / SOCKS5
तर्क / यह कैसे काम करता है / त्वरित शुरुआत / प्रमाणपत्र / Tor / CAPTCHA / प्रमाण / विकास
सुरक्षा परीक्षण एक व्यवहारिक अनुशासन है। कोई एप्लिकेशन क्या करता है -- इनपुट को कैसे संभालता है, कौन से नियंत्रण लागू करता है, क्या वापस दर्शाता है, कैसे विफल होता है -- यही मायने रखता है। उस विश्लेषण के लिए पहचान अप्रासंगिक होनी चाहिए।
AI-सहायता प्राप्त सुरक्षा उपकरण ऐसे काम नहीं करते। वे लक्ष्य को देखते हैं -- उसका डोमेन, उसका ब्रांड, उसका संगठन -- और राय बना लेते हैं। वे प्रसिद्ध सेवाओं के लिए निष्कर्षों को नरम कर देते हैं। वे इस आधार पर जाँच करने से इनकार कर देते हैं कि लक्ष्य कौन है। वे उन पथों का परीक्षण करने से मना कर देते हैं जिन्हें वे किसी विशेष विक्रेता से जोड़ते हैं। AI ऐसे निर्णय ले रहा है जो ऑपरेटर के हैं, और वह उन्हें संदर्भ के आधार पर ले रहा है, व्यवहार के आधार पर नहीं।
यह गलत अक्ष है। ऑपरेटर दायरे को अधिकृत करता है। उपकरण व्यवहार का मूल्यांकन करता है। ये अलग-अलग जिम्मेदारियाँ हैं और इन्हें एक में नहीं समाहित होना चाहिए। लेकिन आज, प्रत्येक AI-सहायता प्राप्त उपकरण में लक्ष्य की पूरी पहचान उसके प्रत्येक निर्णय में जुड़ी हुई है -- क्या परीक्षण करना है, कितना दबाव डालना है, रिपोर्ट करना है या नहीं।
Blinder एक शुरुआती बिंदु है: एक व्यावहारिक उपकरण, लेकिन यह भी एक दृष्टिकोण कि परीक्षण को संदर्भ से अलग किया जाना चाहिए। यह इस विचार को सामने लाने का एक प्रारंभिक प्रयास है। यदि यह दृष्टिकोण उपयुक्त लगता है, तो हम बेहतर कार्यान्वयन, योगदान, या बस इस बातचीत का स्वागत करेंगे कि रेखा कहाँ होनी चाहिए।
पहचान हटाने का मतलब कंटेंट हटाना नहीं है। यहीं अधिकांश भोले दृष्टिकोण टूट जाते हैं। भेद्यताएँ प्रतिक्रिया कंटेंट में परिवर्तन के रूप में देखी जा सकती हैं -- त्रुटि संदेश, प्रतिबिंबित इनपुट, वह डेटा जिस तक सत्र नहीं पहुँचना चाहिए, परिकलित परिणाम जो सर्वर-साइड मूल्यांकन को उजागर करते हैं। यदि कोई प्रॉक्सी इस कंटेंट को हटा दे, तो वह उस प्रमाण को छिपा देगा जिसकी परीक्षक को तलाश है।
आवश्यकता सर्जिकल है: पहचान हटाएँ जबकि व्यवहारिक संकेत संरक्षित रखें। एक पृष्ठ जो किसी का नहीं है लेकिन मूल की तरह ही व्यवहार करता है -- जिसमें तब भी शामिल है जब वह बुरी तरह व्यवहार करता है।
Blinder एक स्थानीय HTTPS रिवर्स प्रॉक्सी है जो AI स्कैनर (या ब्राउज़र) और लक्ष्य के बीच बैठती है। यह पहचान को फिर से लिखती है -- डोमेन, ब्रांड, संगठन के नाम, ईमेल, IP पते -- जबकि एप्लिकेशन के कार्यात्मक व्यवहार को संरक्षित रखती है: उसकी त्रुटियाँ, उसके प्रतिबिंब, उसके सुरक्षा नियंत्रण, उसके स्टेटस कोड, उसकी कंटेंट संरचना।
डाउनस्ट्रीम AI के लिए, लक्ष्य https://127.0.0.1:8099 पर एक अनाम स्थानीय रूप से होस्ट किया गया एप्लिकेशन है। पहचानने के लिए कोई ब्रांड नहीं। राय बनाने के लिए कोई डोमेन नहीं। AI परीक्षण करता है कि एप्लिकेशन क्या करता है, यह नहीं कि वह कौन है।
यह कंटेंट-ब्लाइंड स्कैनिंग है: ऑपरेटर नियंत्रित करता है कि लक्ष्य कौन है; AI इस पर ध्यान केंद्रित करता है कि वह क्या करता है।
प्रतिस्थापन कंटेंट शुद्धता का हिस्सा है: प्रदर्शन के लिए तटस्थ भराव, एप्लिकेशन डेटा के लिए प्रतिवर्ती मान, और संरक्षित निदान और नियंत्रण व्यवहार। उत्पन्न हटाने की सूचनाएँ पृष्ठों में नहीं होनी चाहिए।
| कंटेंट स्क्रबिंग | प्रदर्शन पाठ को तटस्थ गद्य भराव से बदला जाता है; इंटरैक्टिव तत्व (बटन, लेबल, फ़ॉर्म नियंत्रण) और नैदानिक कंटेंट (त्रुटि संदेश, स्टैक ट्रेस, प्रतिबिंबित मार्कअप) संरक्षित रहते हैं। पहचान टोकन, डोमेन संदर्भ और कुकी मान HTTP बॉडी, हेडर और WebSocket टेक्स्ट में फिर से लिखे जाते हैं। --preserve-content केवल-पहचान स्क्रबिंग के लिए मूल प्रदर्शन पाठ रखता है। |
| संसाधन अखंडता | मूल SRI प्रति संदर्भ सत्यापित और फिर से लिखे गए संसाधनों के लिए पुनर्गणना की जाती है, संबंधित CSP हैश का अनुवाद किया जाता है। संस्करणित संदर्भ परोसी गई बाइट्स को बाँधते हैं; बाहरी संसाधन अखंडता संरक्षित रहती है। |
| प्रतिक्रिया कैश | अलग अपस्ट्रीम/डाउनस्ट्रीम कैश सत्यापनकर्ता। 304 पुनःसत्यापन सुरक्षा-नीति हेडर को मर्ज करता है। Vary-जागरूक निष्कासन। |
| सत्र प्रबंधन | प्रति-मान स्क्रबिंग के साथ प्रतिवर्ती कुकी नाम। --extra-origin के माध्यम से बहु-मूल रूटिंग नियतात्मक उपनाम होस्टनाम, Host-हेडर रूटिंग और CORS मूल अनुवाद के साथ। |
| CAPTCHA रिले | ऑपरेटर-उन्मुख चुनौती कतार और अलग प्रदाता मूल। Tor-रूटेड संसाधन प्रदाता कुकी, CSP और CORS को लक्ष्य और ऑपरेटर से अलग रखते हैं। |
| निजी रूटिंग | रिमोट होस्टनाम रिज़ॉल्यूशन के साथ Tor SOCKS5 के माध्यम से अपस्ट्रीम HTTP और WebSocket। Tor विफलताएँ कठोर त्रुटियाँ हैं, कभी भी मौन फ़ॉलबैक नहीं। |
| स्थानीय HTTPS | 90-दिन के जीवनकाल और स्वचालित नवीनीकरण के साथ स्थानीय CA; सत्र लीफ प्रमाणपत्र तुरंत हस्ताक्षरित होते हैं। CA पर एक बार भरोसा करें -- मूल जोड़ने या उपनाम बदलने पर कभी पुनः भरोसा करने की आवश्यकता नहीं। एफेमेरल मोड उपलब्ध। |
| प्रमाण | जर्नल-आधारित दृढ़ता के साथ प्री-स्क्रब HAR, प्रति-अनुरोध स्क्रब/लीक गणना के साथ अनुरोध मैनिफ़ेस्ट, डोमेन मैपिंग और स्क्रब रिपोर्ट। युग्मित प्रतिक्रिया तुलना बाइट-आकार निष्ठा और क्या कंटेंट/स्टेटस परिवर्तन मास्किंग से बचते हैं, की जाँच करती है। सिग्नल-संरक्षण जाँच सत्यापित व्यवहार और शेष दोष रिकॉर्ड करती है। |
कार्यान्वयन स्थिति और ज्ञात सीमाओं के लिए समर्थित व्यवहार और डिलीवरी गेट देखें।
Go 1.26+ के साथ बनाएँ। बाइनरी में कोई बाहरी रनटाइम निर्भरता नहीं है।
git clone https://github.com/Splinters-io/blinder.git
cd blinder
make build
./blinder --preflight
OS-विशिष्ट प्रमाणपत्र सलाह का पालन करें, फिर एक सत्र शुरू करें:
capture_dir=$(mktemp -d)
./blinder --target https://your-authorized-target.example \
--identity YourOrganisation \
--har "$capture_dir/session.har" \
--output "$capture_dir/output"
अपने ब्राउज़र या स्कैनर को https://127.0.0.1:8099 पर इंगित करें। बार-बार --identity फ़्लैग के साथ कई पहचान टोकन जोड़ें। सत्र प्रमाण सहेजने के लिए Ctrl-C से रोकें।
YAML फ़ाइल से डिफ़ॉल्ट लोड करने के लिए --config (-c) का उपयोग करें। CLI फ़्लैग फ़ाइल को ओवरराइड करते हैं।
# blinder.yaml
listen: "127.0.0.1:9443"
target: "https://example.com"
alias: "target-001.local"
identity:
- "ExampleCorp"
- "example.com"
output: "/tmp/blinder-output"
captcha_config: "captcha.yaml"
no_verify_tls: true
tor:
enabled: false
addr: "127.0.0.1:9050"
har:
path: "/tmp/session.har"
max_body: 10485760
./blinder -c blinder.yaml
# override the listen port from the file:
./blinder -c blinder.yaml --listen 127.0.0.1:7777
Blinder पहली बार चलने पर एक स्थानीय CA (Certificate Authority) उत्पन्न करता है और इसका उपयोग सत्र-विशिष्ट लीफ प्रमाणपत्रों पर हस्ताक्षर करने के लिए करता है। CA पर एक बार भरोसा करें; सभी वर्तमान और भविष्य के एंडपॉइंट -- जिसमें बाद में जोड़े गए अतिरिक्त मूल भी शामिल हैं -- सेटअप दोबारा चलाए बिना स्वचालित रूप से विश्वसनीय हो जाते हैं।
| प्लेटफ़ॉर्म | सेटअप |
|---|---|
| macOS | मुद्रित --trust-cert कमांड चलाएँ, CA फ़िंगरप्रिंट की समीक्षा करें और उपयोगकर्ता Keychain विश्वास को स्वीकृत करें। एक-बार का सेटअप। |
| Ubuntu / Linux | मुद्रित curl --cacert कमांड का उपयोग करें या अपने ब्राउज़र/स्कैनर के ट्रस्ट स्टोर में CA प्रमाणपत्र इंस्टॉल करें। |