एक छोटी वेबसाइट के व्हाइट-बॉक्स सुरक्षा ऑडिट में क्या मिला: tarasovvitalii.com पर आठ सुधार

एक पोर्टफ़ोलियो साइट को सुरक्षा जाँच की ज़रूरत क्यों पड़ी

पोर्टफ़ोलियो सबसे सुरक्षित तरह की वेबसाइट लगती है: काम के कुछ पेज और एक संपर्क फ़ॉर्म। लेकिन VITON13 के संस्थापक की साइट tarasovvitalii.com इससे कहीं ज़्यादा है। उस पर VITON ID पर चलने वाली चैट है, जो Firebase Authentication और Firestore पर बनी है, Node पर एक छोटा API है जो संपर्क के संदेश सहेजता है और ईमेल भेजता है, Docker में nginx सर्वर है, और /demos/ के नीचे पंद्रह कॉन्सेप्ट साइटों की कॉपियाँ हैं। जो विज़िटर संदेश लिखने के लिए साइन इन करता है, वह इन सभी हिस्सों पर एक साथ भरोसा करता है।

28 सितंबर 2026 को VITON13 Studio ने साइट को ठीक वैसे ही जाँचा, जैसे वह लॉन्च से पहले किसी क्लाइंट की साइट जाँचता। हर हिस्से के लिए सवाल एक हमलावर का सवाल था: बाहर का कोई व्यक्ति इसके साथ क्या कर सकता है, और इसकी क़ीमत मालिक को क्या चुकानी पड़ेगी? कोई ख़ामी तभी गिनी गई जब उसे दोहराकर देख लिया गया, और कोई सुधार तभी गिना गया जब वही हमला उस पर नाकाम रहा।

तरीक़ा: पहले सोर्स कोड, फिर लोकल कॉपी पर हमले

व्हाइट-बॉक्स वेबसाइट सुरक्षा ऑडिट अंदर से शुरू होता है। जाँच करने वालों ने हर API रूट और साइन-इन टोकन को वेरिफ़ाई करने वाला कोड पढ़ा, और साथ ही Firestore के नियम और उनके 39 एमुलेटर टेस्ट, nginx और Docker Compose का कॉन्फ़िगरेशन, साइट और API की npm डिपेंडेंसी, चैट इंटरफ़ेस और सभी पंद्रह डेमो का कोड भी।

लाइव सर्वर को टटोलने के बजाय स्टूडियो ने वही कंटेनर लोकल चलाए, यानी प्रोडक्शन सेटिंग्स के साथ nginx और API, और हर हमला वहीं आज़माया। इससे लाइव साइट और उसके विज़िटर प्रयोग से बाहर रहते हैं, और एक ही रिक्वेस्ट को सुधार से पहले और बाद में दोबारा चलाकर बदलाव साबित किया जा सकता है। लाइव पते पर सिर्फ़ अंतिम नतीजा, यानी हेडर और रीडायरेक्ट, दोबारा जाँचा गया।

हर पक्की ख़ामी को फिर एक जोखिम स्तर दिया गया। ज़्यादा जोखिम का मतलब था कि बाहर का व्यक्ति किसी और के सेशन के अंदर कुछ कर सकता है या निजी डेटा तक पहुँच सकता है; मध्यम का मतलब था सुरक्षा की ऐसी परत का न होना जो छोटे बग को बड़ा बना दे; कम का मतलब था ऐसी कमज़ोरी जिसके लिए असामान्य हालात चाहिए या जिससे बहुत कम जानकारी लीक होती है। नीचे की सूची इसी क्रम में है, और हर बिंदु में दर्ज है कि सुधार से पहले हमले ने क्या किया और सुधार के बाद वही रिक्वेस्ट क्या करती है।

Oriva डेमो में स्क्रिप्ट इंजेक्शन: सबसे गंभीर ख़ामी

सबसे गंभीर समस्या ख़ुद पोर्टफ़ोलियो में नहीं, बल्कि उसके एक डेमो में थी। Oriva स्टोर कॉन्सेप्ट पते से ?cat= पैरामीटर पढ़ता था और उसे HTML के रूप में पेज में डाल देता था। इसलिए ख़ास तरह से बनाया गया लिंक tarasovvitalii.com पर स्क्रिप्ट चला सकता था। OWASP बग की इस श्रेणी, क्रॉस-साइट स्क्रिप्टिंग, को ऐसी साइट में स्क्रिप्ट घुसाने के रूप में बताता है जिस पर पीड़ित भरोसा करता है, और यहाँ ठीक यही बात इसे ख़तरनाक बनाती थी।

डेमो चैट के साथ एक ही ओरिजिन, यानी एक ही डोमेन, साझा करते हैं, और चैट उसी ओरिजिन पर ब्राउज़र में अपना Firebase सेशन रखती है। साइट के मालिक का ऐसे लिंक पर एक क्लिक इनबॉक्स और मालिक के अकाउंट को उजागर कर सकता था। मिल जाने के बाद सुधार आसान है: डेमो अब सिर्फ़ जानी-पहचानी कैटेगरी और सॉर्ट वैल्यू स्वीकार करता है और बाक़ी सब अनदेखा कर देता है। बाक़ी चौदह डेमो में भी यही पैटर्न जाँचा गया, और वे पते के पैरामीटर की सिर्फ़ तय वैल्यू से तुलना करते हैं।

/demos/ के लिए CSP और पिन की गई स्क्रिप्ट

मध्यम जोखिम वाली ख़ामी सुरक्षा की कई परतों से जुड़ी थी। /demos/ सेक्शन कोई Content-Security-Policy नहीं भेजता था, यानी वह हेडर जो ब्राउज़र को बताता है कि पेज किन स्रोतों से स्क्रिप्ट, स्टाइल और डेटा लोड कर सकता है। इसके ऊपर, 52 डेमो पेज मैप लाइब्रेरी Leaflet को एक सार्वजनिक CDN से बिना इंटीग्रिटी हैश के लोड करते थे। अगर वह CDN कभी हैक हो जाता, या कोई भी स्क्रिप्ट घुसा दी जाती, तो कुछ भी यह सीमित नहीं करता कि वह कहाँ तक पहुँच सकती है।

अब /demos/ की अपनी पॉलिसी है: रिक्वेस्ट सिर्फ़ साइट को ही, स्क्रिप्ट सिर्फ़ साइट से और पिन की गई लाइब्रेरी से, और कोई प्लगइन नहीं। Leaflet को Subresource Integrity हैश से पिन किया गया है, इसलिए अगर फ़ाइल का एक भी बाइट बदलता है तो ब्राउज़र उसे ठुकरा देता है। headless Chrome में सभी 119 डेमो पेज नई पॉलिसी के तहत शून्य उल्लंघनों के साथ लोड हुए।

सर्वर रीडायरेक्ट में हेडर इंजेक्शन

जो nginx नियम /demos/<id> को /demos/<id>/ पर रीडायरेक्ट करता था, वह डिकोड किया गया पाथ ज्यों का त्यों Location हेडर में लौटा देता था। इसलिए %0d%0a, यानी एन्कोड की गई लाइन ब्रेक, वाला लिंक जवाब में अपना एक हेडर जोड़ सकता था, जैसे Set-Cookie। OWASP इसे CRLF इंजेक्शन की श्रेणी में रखता है: कैरिज रिटर्न और लाइन फ़ीड को चुपके से उस जगह डाल देना जहाँ सर्वर हेडर बनाता है।

अब रीडायरेक्ट सिर्फ़ अक्षर, अंक, हाइफ़न और अंडरस्कोर स्वीकार करता है और लक्ष्य पता ख़ुद बनाता है। जिस रिक्वेस्ट को पहले घुसाई गई कुकी के साथ 301 मिलता था, उसे अब सादा 404 मिलता है, लोकल कॉपी पर भी और लाइव साइट पर भी।

मेल, सीमाओं और सर्वर से जुड़े पाँच छोटे सुधार

कम जोखिम वाली तीन ख़ामियाँ संदेश सिस्टम से जुड़ी थीं। me@x.com?bcc=…&body=… जैसा ईमेल पता वैलिडेशन पार कर जाता था, इसलिए मालिक के इनबॉक्स में Reply लिंक किसी छिपे हुए कॉपी पाने वाले और पहले से भरे टेक्स्ट के साथ खुल सकता था; अब ऐसे पते अस्वीकार किए जाते हैं और mailto: लिंक में हर पता एन्कोड होता है। नामों में टेक्स्ट की दिशा पलटने वाले अक्षर हो सकते थे, जो टेक्स्ट को छिपा देते हैं; अब वे हटा दिए जाते हैं। सीमाएँ सिर्फ़ हर IP पते पर थीं, इसलिए पते बदल-बदलकर डिस्क भरी जा सकती थी; अब उनके ऊपर सहेजे जाने वाले सबमिशन की 500 की कुल दैनिक सीमा है।

बाक़ी सर्वर की सेटिंग्स थीं। संदेश API root के रूप में, लिखे जा सकने वाले फ़ाइल सिस्टम पर चलता था; अब वह बिना विशेष अधिकारों वाले यूज़र के रूप में, सिर्फ़ पढ़ने लायक़ फ़ाइल सिस्टम पर, Linux की सभी capabilities हटाकर चलता है। हर जवाब nginx का सटीक वर्ज़न दिखाता था, वह भी ऐसी ब्रांच का जिसे अब सुधार नहीं मिलते; वर्ज़न छिपा दिया गया है और कंटेनर मौजूदा स्टेबल लाइन पर चलता है। HSTS, वह हेडर जो ब्राउज़र को HTTPS पर बनाए रखता है, मुख्य डोमेन पर भेजा जाता था लेकिन www पर नहीं; अब यह www और सबडोमेन को भी कवर करता है।

साइट के वे हिस्से जो बिना बदलाव के पास हुए

जो ऑडिट सिर्फ़ समस्याएँ गिनाता है, वह अपनी आधी क़ीमत छिपा लेता है। जाँच ने यह भी पक्का किया कि क्या पहले से अच्छी तरह किया गया था: साइन-इन टोकन वेरिफ़िकेशन सिर्फ़ RS256 स्वीकार करता है, key id माँगता है और audience, issuer और expiry जाँचता है; Firestore के नियम किसी को भी दूसरे व्यक्ति की बातचीत पढ़ने या मालिक के नाम से लिखने नहीं देते; ईमेल टेम्पलेट हर वैल्यू को एस्केप करते हैं; लॉग में कोई टोकन, ईमेल पता या IP पता नहीं होता; और चैट विज़िटर का टेक्स्ट कभी HTML के रूप में नहीं डालती।

सुधारों के बाद API का टेस्ट सूट नए नियमों को कवर करते हुए 48 में से 48 पास करता है, और साइट या API की डिपेंडेंसी में npm audit को कोई ज्ञात कमज़ोरी नहीं मिलती।

उसी दिन लाइव पते पर रिस्पॉन्स हेडर एक बार फिर जाँचे गए: किसी भी जवाब में सर्वर का वर्ज़न नहीं, बिना www वाले डोमेन और www दोनों पर सबडोमेन सहित HSTS, /demos/ पर डेमो पॉलिसी, और हेडर इंजेक्शन वाली रिक्वेस्ट का जवाब सादा 404। लाइव साइट पर Oriva कैटलॉग अब कैटेगरी को इस्तेमाल करने से पहले अपनी तय सूची से मिलाता है, और मैप लाइब्रेरी अपने इंटीग्रिटी हैश के साथ लोड होती है।

जब साइट का अपना स्टूडियो ऑडिट करे: इसकी सीमाएँ

यह स्टूडियो की अपनी साइट है, जिसे स्टूडियो ने ही जाँचा। यह न तो स्वतंत्र पेनिट्रेशन टेस्ट है और न ही कोई सर्टिफ़िकेट, और यह उसी कोड पर लागू होता है जो 28 सितंबर 2026 को था। नए कोड, नई डिपेंडेंसी या नए डेमो को फिर से वैसी ही जाँच चाहिए, इसीलिए सुरक्षा जाँच की जगह रिलीज़ प्रक्रिया में है, किसी एक बार के प्रोजेक्ट में नहीं।

एक ढाँचागत जोखिम सोच-समझकर छोड़ा गया है: डेमो अब भी साइट का ओरिजिन साझा करते हैं। नई पॉलिसी सीमित करती है कि घुसाया गया कोड कहाँ तक पहुँच सकता है, लेकिन डेमो को पूरी तरह अलग सिर्फ़ किसी अलग डोमेन पर ले जाकर ही किया जा सकता है। छोटे बिज़नेस के लिए सबक़ व्यावहारिक है: कोड की सबसे ख़तरनाक लाइन अक्सर लॉगिन फ़ॉर्म में नहीं, बल्कि भुला दिए गए किसी अतिरिक्त पेज में होती है।