यहां तक कि अगर आप केवल हैकर समूहों के बेनामी और लल्ज़सेक की घटनाओं का अनुसरण करते हैं, तो शायद आपने बदनाम सोनी हैक की तरह वेब साइटों और सेवाओं के हैक होने के बारे में सुना होगा। क्या आपने कभी सोचा है कि वे ऐसा कैसे करते हैं?
ऐसे कई उपकरण और तकनीकें हैं जिनका उपयोग ये समूह करते हैं, और जब हम आपको ऐसा करने के लिए मैन्युअल देने की कोशिश नहीं कर रहे हैं, तो यह समझना उपयोगी है कि क्या हो रहा है। उन हमलों में से दो, जिनके बारे में आप लगातार सुन रहे हैं कि वे "(वितरित) सेवा से वंचित हैं" (DDoS) और "SQL इंजेक्शन" (SQLI)। यहां बताया गया है कि वे कैसे काम करते हैं
द्वारा छवि xkcd
सर्विस अटैक से इनकार
यह क्या है?
एक "सेवा से वंचित" (कभी-कभी "सेवा का वितरित नाम" या DDoS कहा जाता है) हमला तब होता है जब एक सिस्टम, इस मामले में एक वेब सर्वर, एक समय में इतने सारे अनुरोध प्राप्त करता है कि सर्वर संसाधन अतिभारित होते हैं सिस्टम बस लॉक हो जाता है और बन्द हो गया। एक सफल DDoS हमले का लक्ष्य और परिणाम यह है कि लक्ष्य सर्वर पर वेबसाइटें वैध ट्रैफ़िक अनुरोधों के लिए अनुपलब्ध हैं।
यह कैसे काम करता है?
एक DDoS हमले के रसद को एक उदाहरण द्वारा सबसे अच्छा समझाया जा सकता है।
कल्पना कीजिए कि एक लाख लोग (हमलावर) अपने कॉल सेंटर को बंद करके कंपनी X के व्यवसाय में बाधा डालने के लक्ष्य के साथ मिल जाते हैं। हमलावर समन्वय करते हैं ताकि मंगलवार को सुबह 9 बजे वे सभी कंपनी एक्स के फोन नंबर पर कॉल करेंगे। सबसे अधिक संभावना है, कंपनी एक्स का फोन सिस्टम एक बार में एक लाख कॉल को संभालने में सक्षम नहीं होगा, इसलिए आने वाली सभी लाइनें हमलावरों द्वारा बंधेगी। इसका परिणाम यह होता है कि वैध ग्राहक कॉल (यानी जो हमलावर नहीं होते हैं) के माध्यम से नहीं मिलते हैं क्योंकि फोन सिस्टम हमलावरों से कॉल को संभालने के लिए बंधा हुआ है। इसलिए संक्षेप में, कंपनी X संभावित अनुरोधों के कारण व्यापार खो रही है, जिसके माध्यम से प्राप्त करने में असमर्थ है।
वेब सर्वर पर DDoS का हमला ठीक उसी तरह से काम करता है। क्योंकि वास्तव में यह जानने का कोई तरीका नहीं है कि वेब सर्वर द्वारा अनुरोध को संसाधित करने तक वैध अनुरोधों बनाम हमलावरों से ट्रैफ़िक को कैसे रोका जाता है, इस प्रकार का हमला आमतौर पर बहुत प्रभावी होता है।
हमले का पर्दाफाश
DDoS हमले की "जानवर बल" प्रकृति के कारण, आपको एक ही समय में सभी कंप्यूटरों पर हमला करने के लिए समन्वित होना चाहिए। हमारे कॉल सेंटर के उदाहरण को फिर से देखते हुए, इसके लिए सभी हमलावरों को सुबह 9 बजे कॉल करना होगा और वास्तव में उस समय कॉल करना होगा। हालांकि यह सिद्धांत निश्चित रूप से काम करेगा जब यह एक वेब सर्वर पर हमला करने की बात आती है, यह काफी आसान हो जाता है जब ज़ोंबी कंप्यूटर, वास्तविक मानवयुक्त कंप्यूटरों के बजाय, उपयोग किए जाते हैं।
जैसा कि आप शायद जानते हैं, मैलवेयर और ट्रोजन के बहुत सारे वेरिएंट हैं, जो एक बार आपके सिस्टम पर, निर्देशों के लिए निष्क्रिय और कभी-कभी "फोन होम" पर झूठ बोलते हैं। इन निर्देशों में से एक, उदाहरण के लिए, कंपनी एक्स के वेब सर्वर पर सुबह 9 बजे बार-बार अनुरोध भेजने के लिए हो सकता है। तो संबंधित मैलवेयर के घर के स्थान के लिए एक एकल अपडेट के साथ, एक एकल हमलावर बड़े पैमाने पर DDoS हमले करने के लिए सैकड़ों हजारों समझौता किए गए कंप्यूटरों को तुरंत समन्वयित कर सकता है।
ज़ोंबी कंप्यूटरों के उपयोग की सुंदरता न केवल इसकी प्रभावशीलता में है, बल्कि इसके गुमनामी में भी है क्योंकि हमलावर को वास्तव में हमले को अंजाम देने के लिए अपने कंप्यूटर का उपयोग नहीं करना पड़ता है।
एसक्यूएल इंजेक्शन हमला
यह क्या है?
एक "SQL इंजेक्शन" (SQLI) हमला एक शोषण है जो खराब वेब विकास तकनीकों का लाभ उठाता है और आमतौर पर, दोषपूर्ण डेटाबेस सुरक्षा के साथ संयुक्त होता है। एक सफल हमले का परिणाम किसी उपयोगकर्ता खाते को संबंधित डेटाबेस या सर्वर के पूर्ण समझौते से लेकर हो सकता है। DDoS हमले के विपरीत, यदि कोई वेब एप्लिकेशन उचित प्रोग्राम किया जाता है, तो SQLI हमला पूरी तरह से और आसानी से रोका जा सकता है।
हमले का पर्दाफाश
जब भी आप किसी वेब साइट पर लॉगिन करते हैं और अपना उपयोगकर्ता नाम और पासवर्ड दर्ज करते हैं, तो अपने क्रेडेंशियल्स का परीक्षण करने के लिए वेब एप्लिकेशन निम्नलिखित की तरह एक क्वेरी चला सकता है:
उपयोगकर्ता से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'myuser' और पासवर्ड = 'mypass';
नोट: SQL क्वेरी में स्ट्रिंग मान एकल उद्धरणों में संलग्न होना चाहिए, यही कारण है कि वे उपयोगकर्ता द्वारा दर्ज किए गए मानों के आसपास दिखाई देते हैं।
तो उपयोगकर्ता के नाम (myuser) और पासवर्ड (mypass) के संयोजन को उपयोगकर्ता तालिका में एक प्रविष्टि से मेल खाना चाहिए ताकि उपयोगकर्ता आईडी को लौटाया जा सके। यदि कोई मेल नहीं है, तो कोई उपयोगकर्ता नाम वापस नहीं किया गया है, इसलिए लॉगिन क्रेडेंशियल अमान्य हैं। हालांकि एक विशेष कार्यान्वयन अलग हो सकता है, यांत्रिकी बहुत मानक हैं।
तो अब आइए एक टेम्प्लेट ऑथेंटिकेशन क्वेरी पर नज़र डालते हैं, जिसे हम उन मूल्यों को स्थानापन्न कर सकते हैं, जो उपयोगकर्ता वेब फॉर्म पर दर्ज करता है:
उपयोगकर्ताओं से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = '[user]' और पासवर्ड = '[pass]'
पहली नज़र में यह उपयोगकर्ताओं को आसानी से मान्य करने के लिए एक सीधा और तार्किक कदम की तरह लग सकता है, हालांकि अगर उपयोगकर्ता द्वारा दर्ज किए गए मूल्यों का एक सरल प्रतिस्थापन इस टेम्पलेट पर किया जाता है, तो यह SQLI हमले के लिए अतिसंवेदनशील है।
उदाहरण के लिए, मान लें कि "myuser’-" उपयोगकर्ता नाम फ़ील्ड में दर्ज किया गया है और पासवर्ड में "गलतपास" दर्ज किया गया है। हमारे टेम्पलेट क्वेरी में सरल प्रतिस्थापन का उपयोग करते हुए, हमें यह मिलेगा:
उपयोगकर्ताओं से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'myuser' - 'और पासवर्ड =' गलत है '
इस कथन की एक कुंजी दो डैश का समावेश है
(--)
। यह एसक्यूएल बयानों के लिए शुरुआती टिप्पणी टोकन है, इसलिए दो डैश (समावेशी) के बाद दिखाई देने वाली किसी भी चीज को अनदेखा किया जाएगा। आवश्यक रूप से, उपरोक्त क्वेरी डेटाबेस द्वारा निष्पादित की जाती है:
उपयोगकर्ता से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'myuser'
यहां चमकता हुआ चूक पासवर्ड चेक की कमी है। उपयोगकर्ता फ़ील्ड के भाग के रूप में दो डैश को शामिल करके, हमने पूरी तरह से पासवर्ड चेक की स्थिति को दरकिनार कर दिया और संबंधित पासवर्ड को जाने बिना "myuser" के रूप में लॉगिन करने में सक्षम थे। अनपेक्षित परिणामों का उत्पादन करने के लिए क्वेरी में हेरफेर करने का यह कार्य एक SQL इंजेक्शन हमला है।
क्या नुकसान हो सकता है?
SQL इंजेक्शन का हमला लापरवाह और गैर-जिम्मेदाराना एप्लिकेशन कोडिंग के कारण होता है और यह पूरी तरह से रोके जाने योग्य है (जिसे हम एक पल में कवर कर देंगे), हालांकि जो नुकसान हो सकता है वह डेटाबेस सेटअप पर निर्भर करता है। बैकएंड डेटाबेस के साथ संचार करने के लिए एक वेब एप्लिकेशन के लिए, एप्लिकेशन को डेटाबेस में लॉगिन की आपूर्ति करनी चाहिए (ध्यान दें, यह वेब साइट के लिए एक उपयोगकर्ता लॉगिन से अलग है)। वेब एप्लिकेशन के लिए किन अनुमतियों की आवश्यकता होती है, इस पर निर्भर करते हुए, इस संबंधित डेटाबेस खाते को मौजूदा डेटाबेस में केवल पूर्ण डेटाबेस तक पहुंच को पढ़ने / लिखने की अनुमति से कुछ भी चाहिए। यदि यह अभी स्पष्ट नहीं है, तो कुछ उदाहरणों को कुछ स्पष्टता प्रदान करने में मदद करनी चाहिए।
उपरोक्त उदाहरण के आधार पर, आप देख सकते हैं कि प्रवेश करके, उदाहरण के लिए,
"youruser '-", "admin' -"
या किसी अन्य उपयोगकर्ता नाम से, हम तुरंत उस साइट पर उस उपयोगकर्ता के रूप में लॉगिन कर सकते हैं, जो पासवर्ड को जाने बिना। एक बार जब हम सिस्टम में होते हैं तो हमें नहीं पता होता है कि हम वास्तव में वह उपयोगकर्ता नहीं हैं, इसलिए हमारे पास संबंधित खाते तक पूरी पहुंच है। डेटाबेस अनुमतियां इसके लिए सुरक्षा जाल प्रदान नहीं करेंगी, क्योंकि आमतौर पर, एक वेब साइट को अपने संबंधित डेटाबेस तक कम से कम पढ़ने / लिखने की सुविधा होनी चाहिए।
अब मान लेते हैं कि वेब साइट पर अपने संबंधित डेटाबेस का पूर्ण नियंत्रण है, जो रिकॉर्ड्स को हटाने, तालिकाओं को जोड़ने / हटाने, नए सुरक्षा खातों को जोड़ने आदि की क्षमता देता है, यह ध्यान रखना महत्वपूर्ण है कि कुछ वेब अनुप्रयोगों को इस प्रकार की अनुमति की आवश्यकता हो सकती है, इसलिए स्वचालित रूप से एक बुरी बात नहीं है कि पूर्ण नियंत्रण प्रदान किया जाता है।
तो इस स्थिति में होने वाली क्षति को स्पष्ट करने के लिए, हम उपयोगकर्ता नाम क्षेत्र में निम्नलिखित दर्ज करके ऊपर कॉमिक में दिए गए उदाहरण का उपयोग करेंगे:
"रॉबर्ट '; DROP टेबल उपयोगकर्ता; -"।
सरल प्रतिस्थापन के बाद प्रमाणीकरण क्वेरी बन जाती है:
उपयोगकर्ताओं से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'रॉबर्ट' है; DROP TABLE उपयोगकर्ता; - 'और पासवर्ड =' गलत '
नोट: अर्धविराम एक SQL क्वेरी में है जिसका उपयोग किसी विशेष कथन के अंत और एक नए कथन की शुरुआत को दर्शाने के लिए किया जाता है।
जिसे डेटाबेस द्वारा निष्पादित किया जाता है:
उपयोगकर्ता से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'रॉबर्ट' हैड्रॉप टेबल उपयोगकर्ता
तो बस ऐसे ही, हमने पूरे उपयोगकर्ता तालिका को हटाने के लिए एक SQLI हमले का उपयोग किया है।
बेशक, बहुत बदतर के रूप में किया जा सकता है, अनुमति एसक्यूएल अनुमतियों के आधार पर, हमलावर मानों को बदल सकता है, डंप टेबल (या पूरे डेटाबेस को ही) एक पाठ फ़ाइल में, नए लॉगिन खाते बना सकता है या पूरे डेटाबेस की स्थापना को भी हाईजैक कर सकता है।
SQL इंजेक्शन हमले को रोकना
जैसा कि हमने पहले कई बार उल्लेख किया है, SQL इंजेक्शन का हमला आसानी से रोका जा सकता है। वेब विकास के कार्डिनल नियमों में से एक है आप कभी भी उपयोगकर्ता इनपुट पर आंख मूंदकर भरोसा नहीं करते हैं जैसा कि हमने ऊपर टेम्प्लेट क्वेरी में सरल प्रतिस्थापन करते समय किया था।
एक SQLI हमले को आसानी से आपके इनपुट्स को सैनिटाइजिंग (या भागने) कहा जाता है। सैनिटाइज़ प्रक्रिया वास्तव में काफी तुच्छ है क्योंकि यह अनिवार्य रूप से किसी भी इनलाइन एकल उद्धरण (such) वर्णों को उचित रूप से संभालती है ताकि उन्हें SQL कथन के अंदर एक स्ट्रिंग को समय से पहले समाप्त करने के लिए उपयोग नहीं किया जा सके।
उदाहरण के लिए, यदि आप डेटाबेस में "O’neil" देखना चाहते हैं, तो आप सरल प्रतिस्थापन का उपयोग नहीं कर सकते क्योंकि O के बाद एकल उद्धरण स्ट्रिंग को समय से पहले समाप्त कर देगा। इसके बजाय आप संबंधित डेटाबेस के भागने चरित्र का उपयोग करके इसे साफ करते हैं। आइए एक इनलाइन एकल उद्धरण के लिए भागने के चरित्र को मान लें कि प्रत्येक उद्धरण को एक \ _ प्रतीक के साथ रखा गया है। तो "ओ'नील" को "ओ" नील के रूप में पवित्र किया जाएगा।
स्वच्छता का यह सरल कार्य एक SQLI हमले को रोकता है। उदाहरण के लिए, हमारे पिछले उदाहरणों को फिर से देखें और उपयोगकर्ता इनपुट के संचित होने पर परिणामी क्वेरी को देखें।
MyUser '-
/
wrongpass
:
उपयोगकर्ताओं से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'myuser \' - 'और पासवर्ड =' गलत '
क्योंकि माईसर बच जाने के बाद एकल उद्धरण (मतलब इसे लक्ष्य मान का हिस्सा माना जाता है), डेटाबेस वस्तुतः यूजरनेम के लिए खोज करेगा
"MyUser '-"।
इसके अतिरिक्त, क्योंकि डैश को स्ट्रिंग मान के भीतर शामिल किया गया है न कि SQL स्टेटमेंट के रूप में, उन्हें SQL टिप्पणी के रूप में व्याख्या किए जाने के बजाय लक्ष्य मान का हिस्सा माना जाएगा।
रॉबर्ट '; ड्रॉप टेबल उपयोगकर्ता;
/
wrongpass
:
उपयोगकर्ता से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = 'रॉबर्ट \'; DROP TABLE उपयोगकर्ता; - 'और पासवर्ड =' गलत '
केवल रॉबर्ट के बाद एकल उद्धरण से बचकर, अर्धविराम और डैश दोनों UserName खोज स्ट्रिंग के भीतर समाहित हैं, इसलिए डेटाबेस शाब्दिक रूप से खोजेगा
"रॉबर्ट '; DROP टेबल उपयोगकर्ता? -"
टेबल डिलीट को निष्पादित करने के बजाय।
संक्षेप में
जबकि वेब हमले विकसित होते हैं और अधिक परिष्कृत हो जाते हैं या प्रवेश के एक अलग बिंदु पर ध्यान केंद्रित करते हैं, यह कोशिश करना और सच्चे हमलों से बचाने के लिए याद रखना महत्वपूर्ण है जो उनके शोषण के लिए कई स्वतंत्र रूप से उपलब्ध "हैकर टूल" की प्रेरणा रहे हैं।
कुछ प्रकार के हमलों, जैसे डीडीओएस, को आसानी से टाला नहीं जा सकता है, जबकि अन्य, जैसे कि SQLI, कर सकते हैं। हालांकि, इस प्रकार के हमलों से जो क्षति हो सकती है, वह कहीं भी बरती जाने वाली असुविधा से लेकर आपदाओं तक के आधार पर हो सकती है।
