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