चिपकाने से पहले अपने रहस्य रिडैक्ट करें
किसी रहस्य को रिडैक्ट करना टेक्स्ट के साझा होने से पहले उसके अंदर के क्रेडेंशियल — एक API कुंजी, टोकन, पासवर्ड या निजी कुंजी — को एक चिह्न से बदल देना है, ताकि जानकारी एक्सेस के बिना यात्रा करे। यह इसलिए मायने रखता है क्योंकि रहस्यों के लीक होने का सबसे आम तरीका हमला नहीं, एक चिपकाना है: एक सहायता टिकट में लॉग, एक चैट में कॉन्फ़िग फ़ाइल, एक फ़ोरम पोस्ट में डिबग कमांड। यह लेख बताता है कि वे चिपकाइयाँ पूर्ववत करना इतना कठिन क्यों है, सीक्रेट रिडैक्टर जैसा स्कैनर क्या पकड़ सकता है और क्या नहीं, और वह प्रवाह — स्थानीय रूप से रिडैक्ट करें, रिडैक्ट की हुई प्रति साझा करें, जो कुछ पहले ही निकल गया है उसे रोटेट करें — जो एक मददगार चिपकाने को घटना बनने से रोकता है।
रहस्य टिकटों, चैट और लॉग में क्यों पहुँचते हैं
कोई भी रहस्य जानबूझकर नहीं चिपकाता। वे रहस्य के आसपास की चीज़ चिपकाते हैं: वह त्रुटि लॉग जिसमें संयोग से अनुरोध हेडर शामिल हैं, वह कॉन्फ़िग फ़ाइल जो संयोग से तीन खंड नीचे डेटाबेस पासवर्ड रखती है, वह curl कमांड जो एक टर्मिनल से कॉपी किया गया जहाँ टोकन एक Authorization हेडर में बैठा है। समस्या-समाधान संदर्भ पर चलता है, और क्रेडेंशियल संदर्भ के अंदर रहते हैं — यही कारण है कि सहायता डेस्क, चैट चैनल और इश्यू ट्रैकर चुपचाप जीवित कुंजियाँ, सत्र टोकन और निजी कुंजियाँ जमा करते हैं, जो जल्दबाज़ी में सावधान लोगों द्वारा लिखे गए हैं जो त्रुटि संदेश को देख रहे थे, उसके ऊपर के हेडर को नहीं।
फिर प्राप्त करने वाली प्रणाली उस चिपकाने को उन तरीकों से स्थायी बना देती है जिन्हें भेजने वाला कभी नहीं देखता। टिकट खोज के लिए अनुक्रमित किए जाते हैं, विक्रेताओं को अग्रेषित किए जाते हैं, रिपोर्ट में निर्यात किए जाते हैं और वर्षों तक रखे जाते हैं; चैट संदेश फ़ोन पर सूचनाओं के रूप में धकेले जाते हैं, थ्रेड में उद्धृत किए जाते हैं और बॉट द्वारा सारांशित किए जाते हैं; लॉग अपने स्वयं के प्रतिधारण और अपनी स्वयं की एक्सेस सूचियों वाले एग्रीगेटर को भेजे जाते हैं। ऐसी प्रणाली में एक रहस्य एक स्थान पर नहीं है — वह प्रणाली द्वारा उत्पन्न हर प्रति, बैकअप, पूर्वावलोकन और सूचना में है, जिनमें से अधिकांश को भेजने वाला न तो गिन सकता है, न ही हटा सकता है। यह विषमता — चिपकाने के लिए एक सेकंड, वापस लेने का कोई विश्वसनीय तरीका नहीं — ही वह संपूर्ण कारण है कि रिडैक्शन चिपकाने के बाद सफ़ाई के रूप में नहीं, बल्कि चिपकाने से पहले, भेजने वाले की मशीन पर होना चाहिए।
एक स्कैनर क्या पकड़ सकता है: आकार, चेकसम और संरचना
अच्छी खबर यह है कि असली क्रेडेंशियल अत्यधिक पैटर्नयुक्त होते हैं, और पैटर्न स्कैनिंग निर्धारणात्मक है: वही टेक्स्ट हमेशा वही निष्कर्ष उत्पन्न करता है, बीच में कोई मॉडल अंदाज़ा नहीं लगाता। प्रदाता कुंजियों के प्रकाशित आकार होते हैं — उपसर्ग, निश्चित लंबाइयाँ, प्रतिबंधित वर्णमालाएँ — इसलिए एक AWS एक्सेस कुंजी, एक GitHub टोकन, एक Stripe कुंजी या एक Slack टोकन को एक नज़र में पहचाना जा सकता है, जैसे कोई व्यक्ति एक अनुच्छेद में फ़ोन नंबर पहचानता है। निजी कुंजियाँ अपनी BEGIN और END कवच पंक्तियों से स्वयं की घोषणा करती हैं, और JSON Web Token की एक कठोर तीन-खंड संरचना होती है जिसके पहले दो खंड हमेशा एक ही तरह से शुरू होते हैं, क्योंकि वे हमेशा एक ही प्रकार का JSON एन्कोड करते हैं।
दो जाँचें पैटर्न परत को ईमानदार रखती हैं। कार्ड नंबर केवल तभी चिह्नित होते हैं जब वे Luhn चेकसम पास करते हैं, एक अंकगणितीय परीक्षण जो हर असली कार्ड नंबर में अंतर्निहित है, जो असली कार्डों को लंबे नंबरों की कहीं बड़ी आबादी — ऑर्डर, चालान, टाइमस्टैम्प — से अलग करता है जो केवल उनके समान दिखते हैं। और जहाँ आकार ओवरलैप होते हैं, विशिष्ट पैटर्न सामान्य पैटर्नों को हराते हैं, ताकि एक वेरिएबल को सौंपी गई ज्ञात प्रदाता कुंजी एक बार, उसके असली प्रकार के तहत, सही रोटेशन निर्देशों के साथ रिपोर्ट की जाए। नीचे पहला स्रोत, GitHub की स्वयं की सीक्रेट स्कैनिंग, प्लेटफ़ॉर्म पैमाने पर उसी सिद्धांत पर काम करती है: साझेदार अपने टोकन प्रारूप प्रकाशित करते हैं, और प्लेटफ़ॉर्म उनका ठीक-ठीक मिलान करता है। एक स्थानीय स्कैनर वही विचार है, उस अंतिम क्षण में निष्पादित जब वह अभी भी मदद कर सकता है — आपका ब्राउज़र, आपके भेजें दबाने से पहले।
एक स्कैनर क्या नहीं पकड़ सकता: एंट्रॉपी और संदर्भ
प्रदाता आकारों से परे, पहचान संभाव्य हो जाती है। एक सामान्य नियम असाइनमेंट खोज सकता है — password या api_key जैसा नाम एक मान के बगल में — और माँग कर सकता है कि मान यादृच्छिक दिखे, शैनन एंट्रॉपी से मापा गया। यह एक वेरिएबल को सौंपी गई उत्पन्न कुंजी को पकड़ता है और एक वाक्य में password शब्द को नज़रअंदाज़ करता है, लेकिन सीमा संख्या के भेष में एक निर्णय है: एक मज़बूत मानव पासवर्ड और एक कमज़ोर मशीन कुंजी एक ही पैमाने पर रहते हैं, एक वाक्यांश के रूप में लिखा गया असली रहस्य कम स्कोर करता है, और प्लेसहोल्डर शब्दावली के बिना एक यादृच्छिक-दिखने वाला बिल्ड हैश उच्च स्कोर करता है। एंट्रॉपी आपको बताती है कि एक स्ट्रिंग आश्चर्यजनक है; यह आपको नहीं बता सकती कि वह स्ट्रिंग एक क्रेडेंशियल है।
संदर्भ बड़ा अंधा स्थान है, क्योंकि किसी मान को ख़तरनाक बनाने वाली लगभग हर चीज़ मान के बाहर है। एक सत्र कुकी केवल अक्षर और अंक है, जब तक आप यह न जानें कि वह किस सेवा को खोलती है। एक डेटाबेस पासवर्ड तीन परिवेश वेरिएबल में बँटे कनेक्शन स्ट्रिंग के अंदर हानिरहित दिखता है, और एक एकबारगी कोड केवल दस मिनट के लिए संवेदनशील होता है। स्कैनर संरचना के आर-पार भी नहीं देख सकते: दो लॉग पंक्तियों में लिपटा एक रहस्य, एक ब्लॉब के अंदर base64-एन्कोड किया गया, या एक छवि में फ़ोटोग्राफ़ किया गया, टेक्स्ट पैटर्न के लिए अदृश्य है, वे कितने भी अच्छे क्यों न हों। ईमानदार सारांश यह है कि एक स्कैनर दस्तावेज़ित, अच्छी तरह बने बहुमत को विश्वसनीय रूप से पकड़ता है — और वह पूर्वावलोकन जो यह आपको दिखाता है, हिट उनके स्थान पर हाइलाइट किए हुए, फिर भी आपकी अपनी दस-सेकंड की नज़र के योग्य है, क्योंकि आपकी आँखें वह संदर्भ जानती हैं जो पैटर्न नहीं जान सकते।
एक और वर्ग है जिसके प्रति स्कैनर जानबूझकर अंधा है, और वह एक जाल के ठीक बगल में है: प्लेसहोल्डर। दस्तावेज़ मान — example, test, dummy या your- जैसे शब्दों वाले — बाहर रखे गए हैं ताकि मैनुअल और ट्यूटोरियल निष्कर्ष तालिका को न जलाएँ। लेकिन हर बहिष्करण एक द्वार है: एक असली कुंजी जिसमें संयोग से उन शब्दों में से एक हो, या एक प्लेसहोल्डर-जैसे मान पर रखा गया एक आलसी असली पासवर्ड, चुपचाप निकल जाता है। बहिष्करण सूची को शोर नियंत्रण के रूप में मानें, कभी गारंटी के रूप में नहीं, और एक स्कैनर को चुप कराने के लिए असली क्रेडेंशियल को प्लेसहोल्डर शब्दावली से कभी न चिह्नित करें।
विहित नकली उदाहरण समस्या
हर प्रदाता उदाहरण क्रेडेंशियल प्रकाशित करता है, और सबसे प्रसिद्ध — AKIAIOSFODNN7EXAMPLE के आसपास बना AWS दस्तावेज़ युग्म — ठीक एक असली कुंजी के आकार का है, क्योंकि एक उदाहरण जो असली न दिखता, वह कुछ नहीं सिखाता। तब स्कैनर एक ऐसे दोराहे का सामना करते हैं जिसका कोई अच्छा डिफ़ॉल्ट नहीं है। विहित उदाहरणों को चिह्नित करें, और हर ट्यूटोरियल, पाठ्यपुस्तक और प्रशिक्षण लॉग एक झूठा अलार्म बन जाता है, जो पाठकों को निष्कर्षों को प्रतिवर्त रूप से खारिज करना सिखाता है — अलार्म थकान अपने आप में एक भेद्यता है। उन्हें श्वेतसूची में डालें, और आपने उन स्ट्रिंगों की एक सूची प्रकाशित कर दी है जिनकी कोई स्कैनर कभी रिपोर्ट नहीं करेगा, जो छिपने की जगह चाहने वाले किसी के लिए निमंत्रण है: एक असली कुंजी उदाहरण के बराबर नहीं हो सकती, लेकिन एक असली कुंजी के आसपास की टिप्पणी, फ़ाइल नाम या आवरण उदाहरण के छद्मावरण को उधार ले सकता है।
व्यावहारिक उत्तर वह है जो सीक्रेट रिडैक्टर लेता है: आकार को चिह्नित करें, और निष्कर्ष तालिका को बातचीत शुरू करने दें। विहित उदाहरण स्वयं कुंजी के अंदर example शब्द रखता है, फिर भी उसे AWS कुंजी के रूप में चिह्नित किया जाता है, क्योंकि एक प्रदाता-आकार की स्ट्रिंग हर बार एक मानवीय नज़र की हकदार है — नज़र सस्ती है, और विकल्प उसी आकार की हर चीज़ के लिए एक मौन मुक्त मार्ग है। जब आप दस्तावेज़ लिखते हैं, तो अपने पाठकों के स्कैनर और अपने स्वयं के स्कैनर की भी मदद करें: स्पष्ट रूप से कृत्रिम मानों का उपयोग करें, उन्हें आसपास के असाइनमेंट में प्लेसहोल्डर शब्दावली से चिह्नित करें, और कभी भी एक असली कुंजी को दस्तावेज़ में चिपकाकर कुछ वर्ण संपादित न करें — आंशिक रूप से संपादित असली कुंजी अतिरिक्त कदमों के साथ एक क्रेडेंशियल लीक बनी रहती है, और स्कैनर भी उसे असली वस्तु से अलग नहीं कर सकते।
हटाएँ ही नहीं, रोटेट करें — और सुरक्षित रूप से साझा करें
यदि एक असली रहस्य पहले ही बिना रिडैक्ट किए चिपकाया जा चुका है, तो कार्य क्रम मायने रखता है और हटाना अंत में आता है, यदि आए तो। मान लें कि मान की प्रतिलिपि बन चुकी है — एक अनुक्रमणिका, एक सूचना, एक स्क्रीनशॉट, एक सहकर्मी के उद्धरण द्वारा — और उसे सार्वजनिक मानें: पहले प्रदाता के पास जाएँ और क्रेडेंशियल को रोटेट करें, पुराने को रद्द करते हुए, ताकि लीक हुई स्ट्रिंग जहाँ भी जीवित रहे, काम करना बंद कर दे। केवल तब मूल संदेश को हटाएँ या संपादित करें, मरम्मत के रूप में नहीं, स्वच्छता के रूप में। नीचे सूचीबद्ध OWASP रहस्य प्रबंधन मार्गदर्शन और gitleaks प्रोजेक्ट, इस सबक के दो हिस्सों के लिए मौजूद हैं: रहस्यों का प्रबंधन करना ताकि वे अल्पकालिक और सीमित दायरे के हों, और इस धारणा पर रिपॉज़िटरी और इतिहास स्कैन करना कि चिपकाइयाँ पहले ही हो चुकी हैं। ब्राउज़र कैप्चर के लिए साथी समस्या उस HAR फ़ाइल को भेजने से पहले में चलाई गई है।
सुरक्षित साझा प्रवाह आदत बनने के लिए पर्याप्त छोटा है। पहला, स्थानीय रूप से रिडैक्ट करें, एक ऐसे उपकरण में जो मूल को कभी अपलोड नहीं करता — स्कैन आपके डिवाइस का है, क्योंकि कच्चा टेक्स्ट एक दूरस्थ रिडैक्टर को भेजना लीक को रोकने के कार्य में ही लीक को दोहराएगा। दूसरा, रिडैक्ट की हुई प्रति टिकट या चैट में साझा करें, जहाँ वह वह सब कुछ ले जाती है जो एक समस्या-समाधानकर्ता को चाहिए — एंडपॉइंट, समय, त्रुटि आकार — एक्सेस को छोड़कर। तीसरा, जब दूसरे पक्ष को वास्तव में स्वयं क्रेडेंशियल की आवश्यकता हो, तो उसे एक सीक्रेट मैनेजर या समाप्त होने वाले, एकल-दृश्य साझा लिंक के माध्यम से, चर्चा से अलग चैनल में भेजें, और टिकट में ऐसा कहें ताकि कोई उसे वापस न चिपकाए। जो टीमें इन तीन कदमों को अपनाती हैं, वे सतर्कता पर निर्भर रहना बंद कर देती हैं, वह एकमात्र नियंत्रण जो अंततः हमेशा विफल होता है, और एक दिनचर्या पर निर्भर होना शुरू करती हैं — और दिनचर्याएँ ही वह हैं जो रहस्यों को थके हुए शुक्रवार की चिपकाई में उतनी ही विश्वसनीयता से टिकटों से बाहर रखती हैं जितनी सावधान सोमवार की चिपकाई में।