OWASP टॉप 10. A1: 2017 से कमजोरियां - इंजेक्शन (भाग 1)

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

इस श्रृंखला में, हम OWASP टॉप 10 से कमजोरियों का विश्लेषण करना शुरू करेंगे, और मैं एक परीक्षण मैदान के रूप में इस तरह के जानबूझकर कमजोर अनुप्रयोग का उपयोग करूंगा। मेरे मामले में यह OWASP Mutillidae II होगा। यह सबसे अच्छा विकल्प नहीं है, लेकिन इसमें कमजोरियां शैक्षिक उद्देश्यों के लिए आवश्यक रूप से संरचित हैं।



अपना हाथ दो

तो, पहली भेद्यता इंजेक्शन है। OWASP Mutillidae II कई विकल्प प्रस्तुत करता है, और हम सबसे सरल "SQLi एक्सट्रेक्ट डेटा"> "उपयोगकर्ता जानकारी (SQL)" के साथ शुरू करेंगे।
हमसे पहले सामान्य प्रमाणीकरण विंडो है - आप प्रतिदिन क्या बातचीत करते हैं:



हमारे पास उपयोगकर्ता नाम या पासवर्ड नहीं है - कुछ भी नहीं। ठीक है, तो इस साइट पर पंजीकरण करें। मैं एक उपयोगकर्ता के नाम से बनाऊंगा जिसका नाम नीपरमो 273 और पासवर्ड 123 है:



बहुत बढ़िया! हमने एक खाता बनाया, एकमात्र शिलालेख "1 पंक्तियाँ सम्मिलित" संकेत हैं कि एक पंक्ति को जाहिरा तौर पर तालिका में जोड़ा गया है, क्योंकि बड़ी संख्या में खातों को डीबीएमएस में संग्रहीत करना सबसे आसान है।

अब सिस्टम में हमारे नए खाते के साथ लॉग इन करें। सफल, महान।
जब हम एक वेब पेज के साथ काम करते हैं, तो हमें हमेशा याद रखना चाहिए कि हमारी बातचीत पेज की सामग्री तक सीमित नहीं है। उदाहरण के लिए, एक पता पट्टी भी है। जिसमें हम बहुत सी रोचक बातें नोटिस कर सकते हैं:

http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details 

उदाहरण के लिए, हम देखते हैं कि पासवर्ड स्पष्ट पाठ में प्रेषित है। यह बुरा है, क्योंकि यातायात को बाधित किया जा सकता है। लेकिन शायद ऐसी कोई आपदा नहीं है - यातायात टीएलएस में लपेटा जाएगा।
आइए लाइन में सही पासवर्ड बदलने की कोशिश करें, उदाहरण के लिए, यह टुकड़ा:

 username=belowzero273&password=123 

पर

 username=belowzero273&password=12345 

बेशक, पासवर्ड अब गलत है, और हमें इसी त्रुटि मिली: और यह खराब है। यह बुरा है, क्योंकि टीएचसी-हाइड्रा की मदद से, जिसके बारे में मैंने यहां बात की थी, हम इस पासवर्ड को बिना किसी फॉर्म के इस लाइन में प्रतिस्थापित करके चुन सकते हैं। लेकिन यह हमेशा स्वीकार्य अवधि में सकारात्मक परिणाम नहीं ला सकता है।

हमारे पास इतना समय नहीं है, तो चलिए कुछ और कोशिश करते हैं। हमारे गलत पासवर्ड में एक एपॉस्ट्रॉफ़ साइन जोड़ें:

 username=belowzero273&password=123 

पर

 username=belowzero273&password=12345' 

अब हमें एक पूर्ण त्रुटि मिली:



गलतियों में कुछ भी गलत नहीं है। यदि हम आवेदन से प्रतिक्रिया नहीं देखते हैं तो खराबी का निदान कैसे करें? लेकिन ऐसी त्रुटियां उपयोगकर्ताओं और हमलावरों को दिखाई नहीं देनी चाहिए।

अब हम देखते हैं कि वास्तव में, जब हम पृष्ठभूमि में "भेजें" बटन पर क्लिक करते हैं, तो निम्नलिखित अनुरोध निष्पादित किया जाता है:

 SELECT * FROM accounts WHERE username='belowzero273' AND password='12345' 

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

कृपया ध्यान दें कि अनुरोध में फ़ंक्शन और फ़ंक्शन शामिल हैं, अर्थात, दोनों चर सही होने चाहिए, क्योंकि यह लॉगिन और पासवर्ड का संयोजन है। तार्किक है।

आइए इस प्रश्न पर एक नज़र डालें:

 SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1 

हमने एक शर्त जोड़ी है जो हमेशा संतुष्ट रहती है: 1 = 1। और अनुरोध दो मामलों में निष्पादित किया जाएगा: या तो हमने उपयोगकर्ता नाम और पासवर्ड के संयोजन का अनुमान लगाया, या 1 = 1। यानी इसे हमेशा अंजाम दिया जाएगा।

यह पता चला है कि निम्नलिखित को पासवर्ड के रूप में निर्दिष्ट किया जा सकता है:

 ' or 1='1 

लाइन के अंत में एपोस्ट्रोफ की अब आवश्यकता नहीं है, वेब एप्लिकेशन का तर्क हमारे लिए डाल देगा। बूम! और हमें सभी खातों के साथ डेटाबेस से चयन मिला:



कूल, अब हमारे पास सभी के लॉगिन और पासवर्ड हैं जो इस एप्लिकेशन में पंजीकृत हैं। और इससे भी बदतर, यहाँ पासवर्ड स्पष्ट में हैं।

इसमें गलत क्या है? और यह तथ्य कि ज्यादातर लोग सभी साइटों के लिए एक ही उपयोगकर्ता नाम और पासवर्ड का उपयोग करते हैं। और एक असुरक्षित साइट पर इस तरह से पंजीकृत होने के बाद, वे अपनी सभी साइटों तक पहुंच खो सकते हैं।

आप इस भेद्यता के साथ भी प्रयोग कर सकते हैं, उदाहरण के लिए, व्यवस्थापक पासवर्ड की तलाश करें। ऐसा करने के लिए, लॉगिन को प्रतिस्थापित करें:

 admin' or 1='1 

यही है, हम डेटाबेस में एक प्रविष्टि की तलाश कर रहे हैं जहां उपयोगकर्ता नाम व्यवस्थापक है, और पासवर्ड कोई भी है।

   ! 

पासवर्ड हमेशा स्पष्ट पाठ में संग्रहीत नहीं होते हैं, लेकिन इसका मतलब यह नहीं है कि प्रमाणीकरण सुरक्षित रूप से किया जाता है। आइए OWASP Mutillidae II "SQLi Bypass Authentication"> "लॉगिन" में दूसरा उदाहरण देखें।

इसी अनुरोध को जेनरेट करके प्रमाणीकरण को दरकिनार किया जा सकता है। अभी हाल ही में, हमने नीचे एक खाता बनाया हैzero273, और अब एक लॉगिन के रूप में निर्दिष्ट करते हैं:

 ' or ('a' = 'a' and username='belowzero273') -- 

यहाँ हम स्पष्ट रूप से सही स्थिति की जाँच करते हैं - a = a, और लॉगिन - नीपरोडोम 273, और "-" की मदद से अनुरोध भाग को भी काट देते हैं।

हिट दर्ज करें और सफलतापूर्वक इस तथ्य के बावजूद सिस्टम में लॉग इन करें कि हमने आपका पासवर्ड कहीं भी निर्दिष्ट नहीं किया है।

इतना आसान है

कभी-कभी ग्राहक पूछते हैं कि क्या हमारी साइट पर प्रमाणीकरण को बायपास करना वास्तव में इतना आसान है? आमतौर पर मैं इस सवाल का जवाब सवाल से देता हूं: "क्या आप सुनिश्चित हैं कि यह पहले से ही नहीं हुआ है?" OWASP रेटिंग के शीर्ष पर इंजेक्शन आकस्मिक रूप से नहीं हैं, क्योंकि इन भेद्यताओं को, एक नियम के रूप में, लागू होने पर विनाशकारी परिणाम होते हैं।

व्यवहार में, निश्चित रूप से, इन उदाहरणों की तुलना में सब कुछ कुछ अधिक जटिल है। लेकिन यह ऐसे बुनियादी उदाहरणों पर है कि गहरी समस्याओं की समझ आकार लेने लगती है। हम अगली बार जारी रखेंगे।

इस लिंक पर लेखक का ब्लॉग पढ़ें।