समवर्ती लॉगिन सुरक्षा
असीमित लॉगिन गंभीर बिजनेस लॉजिक खामियों को छिपा सकते हैं।
एक उपयोगकर्ता लैपटॉप पर लॉगिन करता है। कुछ सेकंड बाद, वही अकाउंट एक अलग ब्राउज़र पर लॉगिन करता है। फिर एक मोबाइल डिवाइस पर। फिर एक API क्लाइंट पर। सब कुछ बिल्कुल ठीक काम करता है।
यह ठीक लगता है क्योंकि कई ऐप्स कई डिवाइस का समर्थन करते हैं। लेकिन आपको पूछना चाहिए: क्या हर एप्लिकेशन को असीमित सत्रों (sessions) की अनुमति देनी चाहिए?
कुछ सिस्टम में, कई सत्र एक फीचर होते हैं। अन्य में, यह एक खामी है जिसका उपयोग हमलावर छिपे रहने के लिए करते हैं। यह एक बिजनेस लॉजिक भेद्यता (vulnerability) है। कोड डिज़ाइन के अनुसार काम करता है, लेकिन डिज़ाइन ही कमजोर है।
अंतर: • पारंपरिक बग कोडिंग की गलतियों का फायदा उठाते हैं। • बिजनेस लॉजिक बग डिज़ाइन संबंधी निर्णयों का फायदा उठाते हैं।
एक मूवी स्ट्रीमिंग सेवा के बारे में सोचें। यदि एक सब्सक्रिप्शन दस लोगों को एक साथ देखने की अनुमति देता है, तो लॉगिन सिस्टम तो काम करता है, लेकिन बिजनेस नियम विफल हो जाता है।
यह बैंकिंग, एडमिन पैनल और SaaS उत्पादों पर लागू होता है।
इसकी जांच कैसे करें:
- ब्राउज़र A के माध्यम से लॉगिन करें और इसे सक्रिय रखें।
- ब्राउज़र B में एक इनकॉग्निटो (incognito) विंडो खोलें।
- उन्हीं क्रेडेंशियल्स के साथ लॉगिन करें।
- जांचें कि क्या पहला सत्र अभी भी काम कर रहा है।
- जांचें कि क्या आप दोनों पर संवेदनशील कार्य कर सकते हैं।
उच्च-सुरक्षा वाले ऐप्स अक्सर इन नियमों को लागू करते हैं:
- प्रति अकाउंट एक सक्रिय सत्र।
- नया लॉगिन होने पर पुराने सत्रों को लॉग आउट करना।
- डिवाइस प्रबंधित करने के लिए नियंत्रण।
- नए लॉगिन के लिए अलर्ट।
यदि कोई हमलावर क्रेडेंशियल्स चुरा लेता है, तो यदि आप असीमित सत्रों की अनुमति देते हैं, तो वे हमेशा के लिए लॉगिन रह सकते हैं। वे तब तक सक्रिय रहते हैं जब तक वास्तविक उपयोगकर्ता सक्रिय रहता है। दोनों में से किसी को भी घुसपैठिए का पता नहीं चलता।
संदर्भ ही सब कुछ है। वे ऐप्स जिन्हें कई सत्रों की आवश्यकता होती है:
- मैसेजिंग ऐप्स।
- सोशल मीडिया।
- ईमेल सेवाएं।
वे ऐप्स जिन्हें सख्त नियंत्रण की आवश्यकता होती है:
- बैंकिंग सिस्टम।
- एडमिन डैशबोर्ड।
- हेल्थकेयर प्लेटफॉर्म।
इसे कैसे ठीक करें:
- डेटाबेस में सक्रिय सत्र आईडी (session IDs) स्टोर करें।
- जब नया लॉगिन हो, तो पुराने सत्र को समाप्त कर दें।
- उपयोगकर्ताओं को सक्रिय डिवाइस और स्थान देखने दें।
- "सभी डिवाइस से लॉग आउट करें" बटन जोड़ें।
- नए लॉगिन के लिए ईमेल या SMS अलर्ट भेजें।
केवल SQL इंजेक्शन जैसे कोड बग्स की तलाश न करें। इस बात के बीच के अंतर को देखें कि आपका ऐप क्या करता है और आपके व्यवसाय की क्या आवश्यकता है।
आज ही अपनी सत्र नीति (session policy) की समीक्षा करें। आपका सबसे बड़ा जोखिम टूटा हुआ कोड नहीं, बल्कि टूटा हुआ लॉजिक हो सकता है।