इन समूहों का उपयोग करने वाले कई टूल और तकनीकें हैं, और जब हम आपको यह करने के लिए मैन्युअल देने की कोशिश नहीं कर रहे हैं, तो यह समझना उपयोगी है कि क्या हो रहा है। "(वितरित) सेवा अस्वीकार" (डीडीओएस) और "एसक्यूएल इंजेक्शन" (एसक्यूएलआई) का उपयोग करके आप लगातार उन दो हमलों के बारे में सुनते हैं। यहां बताया गया है कि वे कैसे काम करते हैं।
द्वारा छवि xkcd
सर्विस अटैक से इनकार
यह क्या है?
एक "सेवा से इनकार" (कभी-कभी "सेवा का वितरित अस्वीकार" या डीडीओएस) हमला होता है जब एक सिस्टम, इस मामले में एक वेब सर्वर, एक बार में इतने सारे अनुरोध प्राप्त करता है कि सर्वर संसाधनों को अधिभारित किया जाता है, सिस्टम बस लॉक हो जाता है और बंद हो जाता है। एक सफल डीडीओएस हमले का लक्ष्य और परिणाम लक्ष्य सर्वर पर वेबसाइट वैध यातायात अनुरोधों के लिए अनुपलब्ध हैं।
यह कैसे काम करता है?
एक डीडीओएस हमले की रसद एक उदाहरण से सबसे अच्छी तरह से समझाया जा सकता है।
कल्पना करें कि एक लाख लोग (हमलावर) कंपनी कॉल के कारोबार को बाधित करके कंपनी एक्स के कारोबार में बाधा डालने के लक्ष्य के साथ मिलकर मिलते हैं। हमलावर समन्वय करते हैं ताकि मंगलवार को सुबह 9 बजे वे सभी कंपनी एक्स के फोन नंबर पर कॉल करेंगे। सबसे अधिक संभावना है कि कंपनी एक्स का फोन सिस्टम एक लाख कॉलों को एक साथ संभालने में सक्षम नहीं होगा, इसलिए सभी आने वाली लाइनें हमलावरों द्वारा बंधी जाएंगी। इसका नतीजा यह है कि वैध ग्राहक कॉल (यानी वे हमलावर नहीं हैं) इस माध्यम से नहीं निकलते हैं क्योंकि फोन सिस्टम हमलावरों से कॉल को संभालने में बंधे हैं। तो संक्षेप में कंपनी एक्स संभावित रूप से वैध अनुरोधों के कारण व्यापार खो रहा है क्योंकि इससे गुजरने में असमर्थता है।
एक वेब सर्वर पर एक डीडीओएस हमला बिल्कुल वही काम करता है। क्योंकि वेब सर्वर अनुरोध के संसाधित होने तक वैध अनुरोध बनाम हमलावरों से यातायात को कैसे प्राप्त किया जाता है, इस बारे में जानने का कोई तरीका नहीं है, इस प्रकार का हमला आमतौर पर बहुत प्रभावी होता है।
हमले का निष्पादन
एक डीडीओएस हमले की "क्रूर बल" प्रकृति के कारण, आपको एक ही समय में हमला करने के लिए समन्वयित सभी कंप्यूटरों की आवश्यकता होती है। हमारे कॉल सेंटर उदाहरण की समीक्षा कर रहे हैं, इसके लिए सभी हमलावरों को 9 बजे कॉल करने और वास्तव में उस समय कॉल करने की आवश्यकता होगी। जब यह सिद्धांत निश्चित रूप से काम करेगा जब वेब सर्वर पर हमला करने की बात आती है, तो यह वास्तविक रूप से आसान हो जाता है जब वास्तविक मानव कंप्यूटर के बजाय ज़ोंबी कंप्यूटर का उपयोग किया जाता है।
जैसा कि आप शायद जानते हैं, मैलवेयर और ट्रोजन के कई प्रकार हैं जो आपके सिस्टम पर एक बार निष्क्रिय और कभी-कभी निर्देशों के लिए "फोन होम" झूठ बोलते हैं। इनमें से एक निर्देश, उदाहरण के लिए, 9 बजे कंपनी एक्स के वेब सर्वर को दोहराए गए अनुरोध भेज सकता है। इसलिए संबंधित मैलवेयर के घर के स्थान पर एक ही अपडेट के साथ, एक ही हमलावर बड़े पैमाने पर डीडीओएस हमले करने के लिए हजारों समझौता कंप्यूटरों को तुरंत समन्वयित कर सकता है।
ज़ोंबी कंप्यूटरों का उपयोग करने की सुंदरता न केवल इसकी प्रभावशीलता में है, बल्कि इसकी गुमनामता में भी है क्योंकि हमलावर को वास्तव में हमले को निष्पादित करने के लिए अपने कंप्यूटर का उपयोग नहीं करना पड़ता है।
एसक्यूएल इंजेक्शन अटैक
यह क्या है?
एक "एसक्यूएल इंजेक्शन" (एसक्यूएलआईआई) हमला एक शोषण है जो खराब वेब विकास तकनीकों का लाभ उठाता है और आम तौर पर दोषपूर्ण डेटाबेस सुरक्षा के साथ संयुक्त होता है। सफल हमले का नतीजा किसी उपयोगकर्ता खाते को संबंधित डेटाबेस या सर्वर के पूर्ण समझौता करने के लिए प्रतिरूपण करने से हो सकता है। डीडीओएस हमले के विपरीत, यदि कोई वेब एप्लिकेशन उचित रूप से प्रोग्राम किया गया है तो एक एसक्यूएलआई हमला पूरी तरह से और आसानी से रोकथाम योग्य है।
हमले का निष्पादन
जब भी आप किसी वेब साइट पर लॉगिन करते हैं और अपना उपयोगकर्ता नाम और पासवर्ड दर्ज करते हैं, तो अपने क्रेडेंशियल्स का परीक्षण करने के लिए वेब एप्लिकेशन निम्न की तरह एक क्वेरी चला सकता है:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
नोट: SQL क्वेरी में स्ट्रिंग मान एकल कोट्स में संलग्न होना चाहिए, यही कारण है कि वे उपयोगकर्ता द्वारा दर्ज मूल्यों के चारों ओर दिखाई देते हैं।
इसलिए उपयोगकर्ता आईडी को वापस करने के लिए दर्ज उपयोगकर्ता नाम (myuser) और पासवर्ड (mypass) का संयोजन उपयोगकर्ता तालिका में एक प्रविष्टि से मेल खाना चाहिए। यदि कोई मिलान नहीं है, तो कोई उपयोगकर्ता आईडी वापस नहीं किया जाता है, इसलिए लॉगिन प्रमाण-पत्र अमान्य हैं। जबकि एक विशेष कार्यान्वयन भिन्न हो सकता है, यांत्रिकी बहुत मानक हैं।
तो आइए अब एक टेम्पलेट प्रमाणीकरण क्वेरी देखें, जिसे हम वेब फॉर्म पर दर्ज मानों को प्रतिस्थापित कर सकते हैं:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
पहली नज़र में यह आसानी से उपयोगकर्ताओं को मान्य करने के लिए एक सीधा और तार्किक कदम प्रतीत हो सकता है, हालांकि यदि इस टेम्पलेट पर उपयोगकर्ता द्वारा दर्ज मूल्यों का एक सरल प्रतिस्थापन किया जाता है, तो यह एक एसक्यूएलआई हमले के लिए अतिसंवेदनशील है।
उदाहरण के लिए, मान लीजिए कि "myuser'-" उपयोगकर्ता नाम फ़ील्ड में दर्ज किया गया है और पासवर्ड में "गलतपास" दर्ज किया गया है। हमारी टेम्पलेट क्वेरी में सरल प्रतिस्थापन का उपयोग करके, हम यह प्राप्त करेंगे:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
इस कथन की कुंजी दो डैश को शामिल करना है
(--)
। यह SQL कथन के लिए प्रारंभिक टिप्पणी टोकन है, इसलिए दो डैश (समावेशी) के बाद दिखाई देने वाली कुछ भी अनदेखा कर दी जाएगी। अनिवार्य रूप से, उपर्युक्त क्वेरी डेटाबेस द्वारा निष्पादित की जाती है:
SELECT UserID FROM Users WHERE UserName='myuser'
यहां चमकदार चूक पासवर्ड की कमी की कमी है।उपयोगकर्ता फ़ील्ड के हिस्से के रूप में दो डैश को शामिल करके, हमने पासवर्ड की स्थिति को पूरी तरह से छोड़ दिया और संबंधित पासवर्ड जानने के बिना "myuser" के रूप में लॉगिन करने में सक्षम थे। अनपेक्षित परिणामों का उत्पादन करने के लिए क्वेरी में हेरफेर करने का यह कार्य एक एसक्यूएल इंजेक्शन हमला है।
क्या नुकसान किया जा सकता है?
एक एसक्यूएल इंजेक्शन हमला लापरवाही और गैर जिम्मेदार अनुप्रयोग कोडिंग के कारण होता है और पूरी तरह से रोकथाम योग्य होता है (जिसे हम एक पल में कवर करेंगे), हालांकि नुकसान की सीमा जो डेटाबेस सेटअप पर निर्भर करती है। बैकएंड डेटाबेस के साथ संवाद करने के लिए वेब एप्लिकेशन के लिए, एप्लिकेशन को डेटाबेस में लॉगिन की आवश्यकता होनी चाहिए (नोट, यह वेब साइट पर उपयोगकर्ता लॉगिन से अलग है)। वेब एप्लिकेशन की कौन सी अनुमतियों के आधार पर, इस संबंधित डेटाबेस खाते को केवल मौजूदा डेटाबेस पहुंच में मौजूदा टेबल में पढ़ने / लिखने की अनुमति से कुछ भी चाहिए। यदि यह अब स्पष्ट नहीं है, तो कुछ उदाहरणों को कुछ स्पष्टता प्रदान करने में मदद करनी चाहिए।
उपर्युक्त उदाहरण के आधार पर, आप देख सकते हैं कि प्रवेश करके, उदाहरण के लिए,
'youruser'--', 'admin'--'
या कोई अन्य उपयोगकर्ता नाम, हम पासवर्ड को बिना पासवर्ड के तुरंत उस साइट पर लॉग इन कर सकते हैं। एक बार जब हम सिस्टम में हों तो पता नहीं है कि हम वास्तव में उस उपयोगकर्ता नहीं हैं, इसलिए हमारे पास संबंधित खाते तक पूर्ण पहुंच है। डेटाबेस अनुमतियां इसके लिए सुरक्षा नेट प्रदान नहीं करेंगी, आमतौर पर, एक वेबसाइट को कम से कम अपने संबंधित डेटाबेस तक पहुंच / लिखना होगा।
अब आइए मान लें कि वेब साइट पर अपने संबंधित डेटाबेस का पूरा नियंत्रण है जो रिकॉर्ड्स को हटाने, टेबल जोड़ने / हटाने, नए सुरक्षा खाते आदि को जोड़ने की क्षमता देता है। यह ध्यान रखना महत्वपूर्ण है कि कुछ वेब अनुप्रयोगों को इस प्रकार की अनुमति की आवश्यकता हो सकती है स्वचालित रूप से एक बुरी चीज नहीं है जो पूर्ण नियंत्रण प्रदान की जाती है।
तो इस स्थिति में किए जा सकने वाले नुकसान को स्पष्ट करने के लिए, हम उपरोक्त कॉमिक में दिए गए उदाहरण का उपयोग उपयोगकर्ता नाम फ़ील्ड में निम्नलिखित दर्ज करके करेंगे:
'Robert'; DROP TABLE Users;--'.
सरल प्रतिस्थापन के बाद प्रमाणीकरण क्वेरी बन जाती है:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
नोट: अर्धविराम एक SQL क्वेरी में है किसी विशेष कथन के अंत और नए कथन की शुरुआत को इंगित करने के लिए उपयोग किया जाता है।
जो डेटाबेस द्वारा निष्पादित किया जाता है:
SELECT UserID FROM Users WHERE UserName='Robert'
ड्रोप टेबल उपयोगकर्ता
तो इसी तरह, हमने संपूर्ण उपयोगकर्ता तालिका को हटाने के लिए एक एसक्यूएलआई हमले का उपयोग किया है।
बेशक, एसक्यूएल अनुमतियों की अनुमति के अनुसार, बहुत खराब किया जा सकता है, हमलावर मूल्य बदल सकता है, टेबल फ़ाइल (या संपूर्ण डेटाबेस स्वयं) को टेक्स्ट फ़ाइल में बदल सकता है, नए लॉगिन खाते बना सकता है या यहां तक कि संपूर्ण डेटाबेस स्थापना को हाइजैक भी कर सकता है।
एसक्यूएल इंजेक्शन हमले को रोकना
जैसा कि हमने पहले कई बार उल्लेख किया था, एक एसक्यूएल इंजेक्शन हमला आसानी से रोकथाम योग्य है। वेब विकास के मुख्य नियमों में से एक यह है कि आपने कभी भी उपयोगकर्ता इनपुट पर भरोसा नहीं किया है जैसा हमने किया था जब हमने उपरोक्त हमारे टेम्पलेट क्वेरी में सरल प्रतिस्थापन किया था।
एक एसक्यूएलआई हमला आसानी से आपके इनपुट को sanitizing (या भागने) कहा जाता है द्वारा विफल कर दिया जाता है। Sanitize प्रक्रिया वास्तव में काफी मामूली है क्योंकि यह अनिवार्य रूप से किसी भी इनलाइन सिंगल कोट (') अक्षरों को उचित रूप से संभालता है जैसे कि उन्हें SQL कथन के अंदर एक स्ट्रिंग को समय-समय पर समाप्त करने के लिए उपयोग नहीं किया जा सकता है।
उदाहरण के लिए, यदि आप डेटाबेस में "ओनील" देखना चाहते हैं, तो आप सरल प्रतिस्थापन का उपयोग नहीं कर सके क्योंकि ओ के बाद एकल उद्धरण स्ट्रिंग को समय-समय पर समाप्त कर देगा। इसके बजाय आप संबंधित डेटाबेस के बचने वाले चरित्र का उपयोग कर इसे स्वच्छ कर दें। आइए मान लें कि एक इनलाइन सिंगल कोट के लिए एस्केप कैरेक्टर प्रत्येक उद्धरण को प्रतीक के साथ प्रीफेसिंग कर रहा है। तो "ओ'नील" को "ओ 'नील" के रूप में स्वच्छ किया जाएगा।
स्वच्छता का यह सरल कार्य एक एसक्यूएलआई हमले से काफी रोकता है। उदाहरण के लिए, आइए हमारे पिछले उदाहरणों पर फिर से जाएं और परिणामी प्रश्न देखें जब उपयोगकर्ता इनपुट संचरित हो।
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
चूंकि myuser के बाद एकल उद्धरण बच निकला है (जिसका अर्थ है कि इसे लक्ष्य मान का हिस्सा माना जाता है), डेटाबेस सचमुच उपयोगकर्ता नाम की खोज करेगा
'myuser'--'.
इसके अतिरिक्त, क्योंकि डैश को स्ट्रिंग मान के भीतर शामिल किया गया है, न कि SQL कथन स्वयं, एसक्यूएल टिप्पणी के रूप में व्याख्या किए जाने के बजाय उन्हें लक्ष्य मान का हिस्सा माना जाएगा।
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
रॉबर्ट के बाद एकल उद्धरण से बचकर, अर्धविराम और डैश दोनों उपयोगकर्ता नाम खोज स्ट्रिंग के भीतर निहित हैं, इसलिए डेटाबेस सचमुच खोज करेगा
'Robert'; DROP TABLE Users;--'
तालिका को निष्पादित करने के बजाय हटाएं।
संक्षेप में
जबकि वेब हमले विकसित होते हैं और अधिक परिष्कृत हो जाते हैं या प्रवेश के एक अलग बिंदु पर ध्यान केंद्रित करते हैं, लेकिन प्रयासों और सच्चे हमलों के खिलाफ सुरक्षा करना याद रखना महत्वपूर्ण है, जो उन्हें मुक्त करने के लिए डिज़ाइन किए गए कई स्वतंत्र रूप से उपलब्ध "हैकर टूल्स" की प्रेरणा रही हैं।
डीडीओएस जैसे कुछ प्रकार के हमलों को आसानी से टाला नहीं जा सकता है जबकि अन्य, जैसे एसक्यूएलआई, कर सकते हैं। हालांकि, इन प्रकार के हमलों से किए जा सकने वाले नुकसान को सावधानी बरतने के आधार पर आपदाजनक की असुविधा से कहीं भी हो सकता है।
