मैंने अपने साइड प्रोजेक्ट्स का सुरक्षा ऑडिट किया — यहाँ वह सब है जो मुझे मिला
मैंने हाल ही में अपने सभी साइड प्रोजेक्ट्स का ऑडिट किया। मैंने अपने FastAPI बैकएंड, Telegram बॉट्स और वेब ऐप्स की जाँच की। मुझे लगा था कि मैं सावधान था।
मैं गलत था।
मुझे वास्तविक बग्स मिले जिन्हें मैंने वास्तव में प्रोडक्शन में भेज दिया था। ये कोई सैद्धांतिक समस्याएँ नहीं हैं। ये वे गलतियाँ हैं जो मैंने तेज़ी से काम करने की कोशिश में की थीं।
यहाँ वे मुख्य समस्याएँ हैं जो मुझे मिलीं और उन्हें ठीक करने के तरीके दिए गए हैं:
- कंडीशनल ऑथेंटिकेशन (Conditional Authentication) मैंने ऐसा कोड लिखा था जो API कीज़ की जाँच केवल तभी करता था जब कोई सीक्रेट मौजूद हो। यदि मैं अपने एनवायरनमेंट में सीक्रेट सेट करना भूल जाता, तो जाँच पूरी तरह से स्किप हो जाती थी। इससे मेरा API सभी के लिए खुला रह जाता था।
- समाधान: ऑथेंटिकेशन को कभी भी कंडीशनल न बनाएं। यदि सीक्रेट गायब है, तो ऐप को एरर देना चाहिए और रुक जाना चाहिए।
- Git हिस्ट्री में कीज़ का लीक होना मुझे अपनी Git हिस्ट्री में पुरानी API कीज़ मिलीं। मैंने बाद में उन्हें .env फाइलों में स्थानांतरित कर दिया था, लेकिन Git आपके कोड के हर पुराने वर्ज़न को हमेशा के लिए सुरक्षित रखता है।
- समाधान: Git में कमिट की गई किसी भी की (key) को compromised मानें। उसे तुरंत रद्द (revoke) कर दें। अपनी हिस्ट्री साफ़ करने के लिए
git-filter-repoजैसे टूल्स का उपयोग करें।
- बचे हुए डिबग एंडपॉइंट्स (Debug Endpoints) मैंने प्रोडक्शन में ऐसे एंडपॉइंट्स छोड़ दिए थे जो मेरे डेटाबेस कॉन्फ़िगरेशन और सिस्टम सेटिंग्स दिखाते थे। ये डेवलपमेंट के दौरान मददगार होते हैं लेकिन वास्तविक उपयोग में खतरनाक हैं।
- समाधान: अपने डिप्लॉयमेंट चेकलिस्ट में डिबग एंडपॉइंट हटाने का विकल्प जोड़ें।
- विस्तृत एरर मैसेज (Verbose Error Messages) मैं यूजर को सीधे सिस्टम एरर वापस भेज रहा था। ये एरर आपके फ़ाइल पाथ, डेटाबेस प्रकार और लाइब्रेरी वर्ज़न का खुलासा करते हैं। एक हमलावर आपके सिस्टम को निशाना बनाने के लिए इस डेटा का उपयोग कर सकता है।
- समाधान: अपने लिए आंतरिक रूप से (internally) पूरा एरर लॉग करें। क्लाइंट को एक सामान्य "Internal Server Error" मैसेज वापस भेजें।
- innerHTML के माध्यम से XSS
मैंने अपने फ्रंटएंड में यूजर डेटा रेंडर करने के लिए
innerHTMLका उपयोग किया था। यह हमलावरों को आपकी साइट में स्क्रिप्ट इंजेक्ट करने की अनुमति देता है।
- समाधान: हमेशा डेटा को सैनिटाइज़ (sanitize) करें या
innerHTMLके बजायtextContentका उपयोग करें।
- रेट लिमिटिंग की कमी मेरे पास ऐसे एंडपॉइंट्स थे जो बिना किसी सीमा के महंगे AI मॉडल को कॉल करते थे। एक यूजर कुछ ही मिनटों में भारी बिल बना सकता था।
- समाधान: ऑथेंटिकेशन अनधिकृत (unauthorized) यूजर्स को रोकता है। रेट लिमिटिंग अधिकृत (authorized) यूजर्स को आपके सिस्टम का दुरुपयोग करने से रोकती है। आपको दोनों की आवश्यकता है।
- ढीली CORS सेटिंग्स (Permissive CORS Settings)
मैंने अपने मिडलवेयर में
allow_origins=["*"]का उपयोग किया था। यह किसी भी वेबसाइट को आपके API पर रिक्वेस्ट भेजने की अनुमति देता है।
- समाधान: प्रोडक्शन में केवल अपने विशिष्ट डोमेन को ही अनुमति दें।
- फ़ाइल लीकेज मैंने ऐसा कोड लिखा था जो अस्थायी फ़ाइलें बनाता था, लेकिन यदि प्रक्रिया क्रैश हो जाती थी, तो वे उन्हें हटाने में विफल रहता था। ये फ़ाइलें आपके सर्वर पर हमेशा के लिए रह जाती हैं।
- समाधान: यह सुनिश्चित करने के लिए कि त्रुटि होने पर भी फ़ाइलें हटाई जाएँ, try-finally ब्लॉक का उपयोग करें।
सुरक्षा संबंधी समस्याएँ शायद ही कभी जानबूझकर होती हैं। वे "मैं इसे बाद में ठीक कर दूँगा" कहने का परिणाम होती हैं। वह "बाद" कभी नहीं आता।
पहले दिन से ही अपने वर्कफ़्लो में सुरक्षा को शामिल करें। कोड को कमिट करने और डिप्लॉय करने से पहले उसकी जाँच करें।
स्रोत: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb