कैसे तेजी से विकास प्रौद्योगिकियां अप्रिय कमजोरियों का स्रोत बन सकती हैं

वास्तविक जीवन के उदाहरणों के साथ सुरक्षा हमेशा अधिक दिलचस्प होती है।

एक पैठ परीक्षक के रूप में, मुझे पसंद है जब रैपिड डेवलपमेंट फ्रेमवर्क पर आधारित परियोजनाएं आती हैं, जैसे कि रूबी-ऑन-रेल, Django, AdonisJs, एक्सप्रेस और इसी तरह। वे आपको इस तथ्य के कारण बहुत तेज़ी से एक सिस्टम बनाने की अनुमति देते हैं कि क्लाइंट मॉडल सहित सभी स्तरों पर व्यावसायिक मॉडल तुरंत कूदते हैं। मॉडल (डेटाबेस में व्यावसायिक वस्तुओं के मॉडल) और ViewModel (ग्राहक संपर्क अनुबंध) ऐसे फ्रेमवर्क को अक्सर मॉडल से ViewModel में अनावश्यक स्थानांतरण से बचने के लिए एक साथ जोड़ा जाता है और इसके विपरीत; बाकी सेवाएं स्वचालित रूप से उत्पन्न होती हैं। विकास के दृष्टिकोण से, आप बस सर्वर पर एक व्यापार मॉडल विकसित कर सकते हैं, और फिर इसे तुरंत क्लाइंट पर उपयोग कर सकते हैं, जो निस्संदेह विकास की गति को बढ़ाता है।

एक बार फिर, मैं यह नहीं कह रहा हूँ कि उपर्युक्त रूपरेखाएँ खराब हैं, या उनके साथ कुछ गलत है, उनके पास उचित सुरक्षा के साधन और उपकरण हैं, यह सिर्फ इतना है कि डेवलपर्स उनके साथ सबसे अधिक गलतियाँ करते हैं। यह एक ASP.NET MVC प्रोजेक्ट में भी देखा गया था, जिसमें डेवलपर्स ने ViewModels के बजाय मॉडल को उजागर करके समान भेद्यता बनाई थी ...

भेद्यता: ग्राहक से आने वाले मॉडल के क्षेत्रों के कमजोर सत्यापन के कारण, उन क्षेत्रों को इंजेक्ट करना संभव है जो कार्यक्षमता द्वारा प्रदान नहीं किए गए हैं, लेकिन व्यवसाय मॉडल में हैं। उदाहरण के लिए, एक ऐसी विधि है जो आपको केवल उपयोगकर्ता नाम बदलने की अनुमति देती है, और उपयोगकर्ता प्रोफ़ाइल ऑब्जेक्ट लौटाती है। क्या होगा यदि मैं लौटी हुई वस्तु की प्रतिलिपि बनाता हूं, इसमें सभी गुण बदल दें और इसे फिर से इनपुट पर भेजें? यह पता चल सकता है कि आप मानक वर्कफ़्लो को दरकिनार करके ऑब्जेक्ट (पासवर्ड, भूमिका) की किसी भी संपत्ति को बदल सकते हैं।

सुरक्षा के लिए हमने जिन विभिन्न परियोजनाओं का परीक्षण किया, उनमें से मैं वास्तविक उदाहरण दूंगा। इन सभी समस्या क्षेत्रों को ठीक कर दिया गया है, और स्क्रीनशॉट में कोई भी अतिरिक्त जानकारी छिपी हुई है।

प्रणाली 1

इस प्रणाली पर, केवल उपयोगकर्ता नाम को प्रोफ़ाइल में बदला जा सकता है। लेकिन दूसरे ईमेल को प्रतिस्थापित करते हुए, मैं उपयोगकर्ता के लॉगिन को बदलने में सक्षम था। इसके अलावा, अन्य उपयोगकर्ताओं को निमंत्रण अब इस साबुन से निकल गया।



प्रणाली 2

इस उदाहरण में, एक साधारण उपयोगकर्ता भूमिकाओं के क्षेत्र को जोड़कर व्यवस्थापक की भूमिका बदलने में कामयाब रहा, और url / व्यवस्थापक द्वारा सभी लेनदेन, उपयोगकर्ताओं, रिपोर्टों और इसी तरह से सिस्टम व्यवस्थापक पैनल को खोलें।



प्रणाली 3

इस प्रणाली में, अनिश्चित अवधि के लिए मुफ्त सदस्यता को नवीनीकृत करना संभव था। यह स्पष्ट है कि मानक दृष्टिकोण की आवश्यकता है कि भुगतान हो।



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



प्रणाली 4

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



इस फ़ील्ड के लिए मेटाडेटा में सर्वर कोड में छिपाएँ, इससे प्रतिक्रिया में क्लाइंट के लिए इस फ़ील्ड को वापस नहीं करना संभव हो गया, लेकिन इनपुट में समस्याओं के बिना इस फ़ील्ड को संसाधित किया गया।



संदेश:

1. कभी भी उपयोगकर्ताओं के आने वाले डेटा पर भरोसा न करें, वे उनके साथ कुछ भी कर सकते हैं
2. उन प्रणालियों से सावधान रहें जिनके पास एक अलग ViewModel-s परत नहीं है, और सीधे आधार मॉडल के साथ काम करते हैं
3. अपने ढांचे के प्रस्तावों को और अधिक विस्तार से देखें।

उपरोक्त जानकारी केवल शैक्षिक और शैक्षिक उद्देश्यों के लिए प्रदान की जाती है, कि उनके सिस्टम को कैसे करना आवश्यक नहीं है।

डेनिस कोलोस्को, पेनेट्रेशन टेस्टर, CISSP