पेज स्रोत देखें, कुंजी कॉपी करें, सब कुछ अपने नाम करें

एक सुरक्षा शोधकर्ता clickup.com पर गए। पेज का स्रोत खोला। JavaScript में हार्डकोड की गई एक API कुंजी मिली। उसे कॉपी किया। एक GET अनुरोध भेजा।

बदले में मिले 959 ईमेल पते और 3,165 आंतरिक फ़ीचर फ़्लैग। कर्मचारी Home Depot, Fortinet, Autodesk, Tenable, Rakuten, Mayo Clinic — इन कंपनियों से।

एक स्ट्रिंग। एक अनुरोध। सब कुछ।

यह होता कैसे है

किसी को फ्रंटएंड से एक API को कॉल करना था। API को प्रमाणीकरण चाहिए था। तो उन्होंने कुंजी JavaScript में डाल दी। शिप करो, आगे बढ़ो, अगला स्प्रिंट।

यह कोई परिष्कृत हमला नहीं है। इसमें न कोई एक्सप्लॉइट है, न कोई ज़ीरो-डे, न कोई सोशल इंजीनियरिंग। इसमें सिर्फ़ view-source: और curl है। एक ब्राउज़र और एक टर्मिनल। ऐसा काम जो कोई जिज्ञासु इंटर्न अपने पहले दिन करता है।

उस कुंजी पर कोई स्कोप नहीं था — वह API जो कुछ भी उजागर करता था, सब कुछ उस तक पहुँच में था। कोई रेट सीमा नहीं — एक अनुरोध ने सब कुछ लौटा दिया। कोई समाप्ति तिथि नहीं — कुंजी तब तक काम करती रही जब तक किसी ने ध्यान नहीं दिया। कोई दूसरा कारक नहीं — स्ट्रिंग का आपके पास होना ही एकमात्र द्वार था।

पैसे का पहलू

लोग डेटा के उजागर होने की बात करते हैं। आइए बात करें कि यह डेटा कितने का है।

फॉर्च्यून 500 कंपनियों के 959 कॉर्पोरेट ईमेल पते। यह वह स्पीयर-फ़िशिंग लक्ष्य सूची है जिसके लिए खतरा पैदा करने वाले समूह पैसे देते हैं। नाम, पद, और यह तथ्य कि ये कंपनियाँ ClickUp इस्तेमाल करती हैं — यह वह सोशल इंजीनियरिंग संदर्भ है जिससे फ़िशिंग काम करती है।

3,165 आंतरिक फ़ीचर फ़्लैग। यह एक रोडमैप है। यह प्रतिस्पर्धियों को बताता है कि ClickUp क्या बना रहा है, क्या आज़मा रहा है, किस चीज़ के पीछे एक गेट लगा है। यह हमलावरों को बताता है कि कौन-सी सुविधाएँ अधूरी हैं और संभवतः कमज़ोर हैं।

यह कोई गोपनीयता संबंधी घटना नहीं है। यह एक बिज़नेस इंटेलिजेंस रिसाव है।

यह बार-बार क्यों होता है

यह इस महीने हमने स्रोत में मौजूद क्रेडेंशियल की जिस घटना पर लिखा है, वह चौथी है। Bitwarden के CLI से क्रेडेंशियल इसलिए निकाले गए क्योंकि वे सादे टेक्स्ट फ़ाइलों में थे। Vercel के एनवायरनमेंट वेरिएबल इसलिए डिक्रिप्ट हो सके क्योंकि "संवेदनशील" फ़्लैग डिफ़ॉल्ट नहीं था। एक डेवलपर के 634 Chrome पासवर्ड इसलिए गए क्योंकि डिक्रिप्शन कुंजी उसी डिस्क पर थी।

ढाँचा हमेशा एक जैसा होता है: कोई क्रेडेंशियल एक स्ट्रिंग के रूप में मौजूद होता है — किसी फ़ाइल में, किसी वेरिएबल में, पेज के स्रोत में — और कुछ उसे पढ़ लेता है। वह "कुछ" बदलता रहता है। ढाँचा नहीं बदलता।

JavaScript में API कुंजियाँ इसका सबसे खराब रूप हैं क्योंकि यहाँ किसी हमले की ज़रूरत ही नहीं है। कुंजी प्रकाशित है। वह हर आगंतुक को भेजी जाती है। ब्राउज़र उसे डाउनलोड करता है, रेंडर करता है, और किसी भी व्यक्ति को दिखा देता है जो राइट-क्लिक करे।

क्या अलग होना चाहिए था

इस API कॉल को क्लाइंट की तरफ़ से कभी भी किसी स्थिर कुंजी से प्रमाणित नहीं किया जाना चाहिए था। विकल्प:

• बैकएंड प्रॉक्सी। फ्रंटएंड आपके अपने बैकएंड को कॉल करता है, जो कुंजी सर्वर की तरफ़ रखता है और API कॉल को प्रॉक्सी करता है। कुंजी कभी ब्राउज़र तक नहीं पहुँचती।
• सत्र-सीमित टोकन। प्रमाणीकरण के बाद फ्रंटएंड को एक अल्पकालिक, संकरे स्कोप वाला टोकन मिलता है। वह समाप्त हो जाता है। वह केवल वही कर सकता है जो प्रमाणित उपयोगकर्ता को अनुमति है। यह कोई मास्टर कुंजी नहीं है।
• कोई कुंजी बिल्कुल नहीं। यदि डेटा सार्वजनिक है, तो उसे बिना प्रमाणीकरण के परोसिए। यदि सार्वजनिक नहीं है, तो उसे बिना प्रमाणित JavaScript को मत परोसिए।

क्लाइंट-साइड कोड में API कुंजी हार्डकोड करना यानी अपने घर की चाबी दरीचे के नीचे रखना और अपना पता सार्वजनिक कर देना।

क्रेडेंशियल के जीवनचक्र की समस्या

यह ClickUp कुंजी शायद एक बार बनी, एक JavaScript फ़ाइल में पेस्ट की गई, किसी रेपो में कमिट हुई, प्रोडक्शन में डिप्लॉय हुई, और फिर कभी उस पर विचार नहीं किया गया। किसी ने उसे रोटेट नहीं किया। किसी ने उसका स्कोप तय नहीं किया। किसी ने कोई समाप्ति तिथि नहीं रखी। किसी ने यह नहीं देखा कि वह क्या-क्या एक्सेस कर रही है।

ज़्यादातर संगठनों की ज़्यादातर API कुंजियों का जीवनचक्र यही है। जल्दबाज़ी में बनाई गईं, जहाँ ज़रूरत थी वहाँ पेस्ट की गईं, भुला दी गईं। वे कोडबेस, कॉन्फ़िग फ़ाइलों, CI/CD पाइपलाइनों और — जाहिर है — पेज के स्रोत में जमा होती जाती हैं; हर एक वह दरवाज़ा है जो कभी बंद नहीं होता।

सवाल यह नहीं है कि आपके संगठन में ऐसी कोई कुंजी है या नहीं। सवाल यह है कि ऐसी कितनी हैं, और अगर आज किसी ने एक कॉपी कर ली, तो क्या आपको पता भी चलेगा।