भले ही आप केवल घटनाओं के प्रति शिथिल होंहैकर समूहों बेनामी और लल्ज़सेक के बारे में, आपने शायद बदनाम सोनी हैक की तरह, वेब साइटों और सेवाओं के हैक होने के बारे में सुना होगा। क्या आपने कभी सोचा है कि वे ऐसा कैसे करते हैं?
वहाँ कई उपकरण और तकनीकें हैंये समूह उपयोग करते हैं, और जब हम आपको ऐसा करने के लिए मैन्युअल देने की कोशिश नहीं कर रहे हैं, तो यह समझना उपयोगी है कि क्या हो रहा है। उन हमलों में से दो, जिनके बारे में आप लगातार सुनते हैं कि वे "(वितरित) सेवा से वंचित हैं" (DDoS) और "SQL इंजेक्शन" (SQLI)। यहां बताया गया है कि वे कैसे काम करते हैं
द्वारा छवि xkcd
सर्विस अटैक से इनकार
यह क्या है?
"सेवा से वंचित" (कभी-कभी कहा जाता है"वितरित इनकार सेवा" या DDoS) हमला तब होता है जब एक सिस्टम, इस मामले में एक वेब सर्वर, एक समय में इतने सारे अनुरोध प्राप्त करता है कि सर्वर संसाधन ओवरलोड हो जाते हैं सिस्टम बस लॉक हो जाता है और बंद हो जाता है। एक सफल DDoS हमले का लक्ष्य और परिणाम यह है कि लक्ष्य सर्वर पर वेबसाइटें वैध ट्रैफ़िक अनुरोधों के लिए अनुपलब्ध हैं।
यह कैसे काम करता है?
एक DDoS हमले का रसद एक उदाहरण द्वारा सबसे अच्छा समझाया जा सकता है।
एक लाख लोगों (हमलावरों) की कल्पना करोसाथ में उनके कॉल सेंटर को कम करके कंपनी X के व्यवसाय में बाधा डालने के लक्ष्य के साथ। हमलावर समन्वय करते हैं ताकि मंगलवार सुबह 9 बजे वे सभी कंपनी एक्स के फोन नंबर पर कॉल करेंगे। सबसे अधिक संभावना है, कंपनी एक्स का फोन सिस्टम एक बार में एक लाख कॉल को संभालने में सक्षम नहीं होगा, इसलिए आने वाली सभी लाइनें हमलावरों द्वारा बंधेगी। इसका परिणाम यह होता है कि वैध ग्राहक कॉल (यानी जो हमलावर नहीं होते हैं) के माध्यम से नहीं मिलते हैं क्योंकि फोन सिस्टम हमलावरों से कॉल को संभालने के लिए बंधा हुआ है। इसलिए संक्षेप में, कंपनी X संभावित अनुरोधों के कारण व्यापार खो रही है, जिसके माध्यम से प्राप्त करने में असमर्थ है।
एक वेब सर्वर पर एक DDoS हमला बिल्कुल काम करता हैउसी तरह। क्योंकि वेब सर्वर द्वारा अनुरोध को संसाधित करने तक वैध अनुरोधों बनाम हमलावरों से ट्रैफ़िक के बारे में जानने का कोई तरीका नहीं है, इस प्रकार का हमला आमतौर पर बहुत प्रभावी होता है।
हमले का पर्दाफाश
DDoS हमले की प्रकृति "जानवर बल" के कारण,आपको एक ही समय में सभी कंप्यूटरों पर हमला करने के लिए समन्वित होना चाहिए। हमारे कॉल सेंटर के उदाहरण को फिर से देखते हुए, इसके लिए सभी हमलावरों को सुबह 9 बजे कॉल करना होगा और वास्तव में उस समय कॉल करना होगा। हालांकि यह सिद्धांत निश्चित रूप से काम करेगा जब यह एक वेब सर्वर पर हमला करने की बात आती है, यह काफी आसान हो जाता है जब ज़ोंबी कंप्यूटर, वास्तविक मानवयुक्त कंप्यूटरों के बजाय, उपयोग किए जाते हैं।
जैसा कि आप शायद जानते हैं, बहुत सारे संस्करण हैंमैलवेयर और ट्रोजन, जो एक बार आपके सिस्टम पर, निर्देशों के लिए निष्क्रिय और कभी-कभी "फोन होम" पर झूठ बोलते हैं। इन निर्देशों में से एक, उदाहरण के लिए, कंपनी एक्स के वेब सर्वर पर सुबह 9 बजे बार-बार अनुरोध भेजने के लिए हो सकता है। तो संबंधित मैलवेयर के घर के स्थान के लिए एक एकल अद्यतन के साथ, एक एकल हमलावर बड़े पैमाने पर DDoS हमले करने के लिए सैकड़ों हज़ारों समझौता किए गए कंप्यूटरों को तुरंत समन्वयित कर सकता है।
ज़ोंबी कंप्यूटरों के उपयोग की सुंदरता न केवल इसकी प्रभावशीलता में है, बल्कि इसके गुमनामी में भी है क्योंकि हमलावर को वास्तव में हमले को अंजाम देने के लिए अपने कंप्यूटर का उपयोग नहीं करना पड़ता है।
SQL इंजेक्शन हमला
यह क्या है?
एक "SQL इंजेक्शन" (SQLI) हमला एक शोषण हैयह खराब वेब विकास तकनीकों का लाभ उठाता है और आमतौर पर, दोषपूर्ण डेटाबेस सुरक्षा के साथ संयुक्त होता है। एक सफल हमले का परिणाम उपयोगकर्ता खाते को संबंधित डेटाबेस या सर्वर के पूर्ण समझौते से लेकर हो सकता है। DDoS हमले के विपरीत, यदि कोई वेब एप्लिकेशन उचित रूप से प्रोग्राम किया गया है, तो SQLI हमला पूरी तरह से और आसानी से रोका जा सकता है।
हमले का पर्दाफाश
जब भी आप किसी वेब साइट पर लॉगिन करते हैं और अपना उपयोगकर्ता नाम और पासवर्ड दर्ज करते हैं, तो अपने क्रेडेंशियल्स का परीक्षण करने के लिए वेब एप्लिकेशन निम्नलिखित की तरह एक क्वेरी चला सकता है:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
नोट: SQL क्वेरी में स्ट्रिंग मान एकल उद्धरणों में संलग्न होना चाहिए, यही वजह है कि वे उपयोगकर्ता द्वारा दर्ज किए गए मानों के आसपास दिखाई देते हैं।
तो दर्ज उपयोगकर्ता नाम का संयोजन(myuser) और पासवर्ड (mypass) उपयोगकर्ता तालिका में उपयोगकर्ता के प्रवेश के लिए एक प्रविष्टि से मेल खाना चाहिए। यदि कोई मेल नहीं है, तो कोई उपयोगकर्ता नाम वापस नहीं किया गया है, इसलिए लॉगिन क्रेडेंशियल अमान्य हैं। हालांकि एक विशेष कार्यान्वयन अलग हो सकता है, यांत्रिकी बहुत मानक हैं।
तो अब एक टेम्प्लेट ऑथेंटिकेशन क्वेरी पर नजर डालते हैं, जिसे हम उन मूल्यों को स्थानापन्न कर सकते हैं, जिन्हें उपयोगकर्ता वेब फॉर्म में दर्ज करता है:
उपयोगकर्ताओं से उपयोगकर्ता का चयन करें जहां उपयोगकर्ता नाम = '[उपयोगकर्ता]' और पासवर्ड = '[पास]'
पहली नज़र में यह एक तरह लग सकता हैउपयोगकर्ताओं को आसानी से मान्य करने के लिए सीधा और तार्किक कदम, हालांकि अगर उपयोगकर्ता का एक साधारण प्रतिस्थापन इस टेम्पलेट पर प्रदर्शन किया जाता है, तो यह SQLI हमले के लिए अतिसंवेदनशील होता है।
उदाहरण के लिए, मान लें कि "myuser’-" उपयोगकर्ता नाम फ़ील्ड में दर्ज किया गया है और पासवर्ड में "गलतपास" दर्ज किया गया है। हमारे टेम्पलेट क्वेरी में सरल प्रतिस्थापन का उपयोग करते हुए, हम इसे प्राप्त करेंगे:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
इस कथन की एक कुंजी दो डैश का समावेश है (--)। यह एसक्यूएल बयानों के लिए शुरुआती टिप्पणी टोकन है, इसलिए दो डैश (समावेशी) के बाद दिखाई देने वाली किसी भी चीज को अनदेखा किया जाएगा। आवश्यक रूप से, उपरोक्त क्वेरी को डेटाबेस द्वारा निष्पादित किया जाता है:
SELECT UserID FROM Users WHERE UserName='myuser'
यहाँ चमकती कमी का अभाव हैपासवर्ड चेक। उपयोगकर्ता फ़ील्ड के भाग के रूप में दो डैश को शामिल करके, हमने पूरी तरह से पासवर्ड चेक की स्थिति को दरकिनार कर दिया और संबंधित पासवर्ड को जाने बिना "myuser" के रूप में लॉगिन करने में सक्षम थे। अनजाने परिणामों का उत्पादन करने के लिए क्वेरी में हेरफेर करने का यह कार्य एक SQL इंजेक्शन हमला है।
क्या नुकसान हो सकता है?
SQL इंजेक्शन का हमला लापरवाही के कारण होता है औरगैर-जिम्मेदाराना एप्लिकेशन कोडिंग और पूरी तरह से रोके जाने योग्य है (जिसे हम एक पल में कवर कर देंगे), हालांकि जो नुकसान हो सकता है वह डेटाबेस सेटअप पर निर्भर करता है। बैकएंड डेटाबेस के साथ संचार करने के लिए एक वेब एप्लिकेशन के लिए, एप्लिकेशन को डेटाबेस में लॉगिन की आपूर्ति करनी चाहिए (ध्यान दें, यह वेब साइट के लिए एक उपयोगकर्ता लॉगिन से अलग है)। वेब एप्लिकेशन को किन अनुमतियों की आवश्यकता होती है, इस पर निर्भर करते हुए, इस संबंधित डेटाबेस खाते को मौजूदा डेटाबेस में केवल पूर्ण डेटाबेस तक पहुँचने के लिए पढ़ने / लिखने की अनुमति से कुछ भी चाहिए। यदि यह अभी स्पष्ट नहीं है, तो कुछ उदाहरणों को कुछ स्पष्टता प्रदान करने में मदद करनी चाहिए।
उपरोक्त उदाहरण के आधार पर, आप देख सकते हैं कि प्रवेश करके, उदाहरण के लिए, "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'
ड्रॉप टेबल उपयोगकर्ता
तो बस ऐसे ही, हमने पूरे उपयोगकर्ता तालिका को हटाने के लिए एक SQLI हमले का उपयोग किया है।
बेशक, बहुत बुरा के रूप में किया जा सकता है, निर्भर करता हैSQL अनुमतियों की अनुमति देता है, हमलावर मानों को बदल सकता है, डंप टेबल (या पूरे डेटाबेस को स्वयं) को एक टेक्स्ट फ़ाइल में बदल सकता है, नए लॉगिन अकाउंट बना सकता है या पूरे डेटाबेस की स्थापना को भी हाईजैक कर सकता है।
SQL इंजेक्शन के हमले को रोकना
जैसा कि हमने पहले कई बार उल्लेख किया है, एक एसक्यूएलइंजेक्शन का हमला आसानी से रोका जा सकता है। वेब विकास के कार्डिनल नियमों में से एक है आप कभी भी उपयोगकर्ता के इनपुट पर आंख मूंदकर भरोसा नहीं करते हैं जैसा कि हमने ऊपर टेम्प्लेट क्वेरी में सरल प्रतिस्थापन करते समय किया था।
SQLI का हमला आसानी से होता हैआपके इनपुट्स को सैनिटाइजिंग (या बचना) कहा जाता है। स्वच्छता प्रक्रिया वास्तव में काफी तुच्छ है क्योंकि यह अनिवार्य रूप से किसी भी इनलाइन एकल उद्धरण (is) वर्णों को उचित रूप से संभालती है, ताकि उन्हें समय से पहले SQL कथन के अंदर एक स्ट्रिंग को समाप्त करने के लिए उपयोग नहीं किया जा सके।
उदाहरण के लिए, यदि आप "O’neil" देखना चाहते हैंएक डेटाबेस, आप साधारण प्रतिस्थापन का उपयोग नहीं कर सकते क्योंकि O के बाद एकल उद्धरण स्ट्रिंग को समय से पहले समाप्त कर देगा। इसके बजाय आप संबंधित डेटाबेस के बच चरित्र का उपयोग करके इसे पवित्र करते हैं। मान लें कि एक इनलाइन एकल उद्धरण के लिए भागने का चरित्र प्रत्येक उद्धरण को प्रतीक के साथ पूर्ववर्ती कर रहा है। इसलिए "ओ'नील" को "ओ'नील" के रूप में पवित्र किया जाएगा।
स्वच्छता का यह सरल कार्य एक SQLI हमले को रोकता है। उदाहरण के लिए, हमारे पिछले उदाहरणों को फिर से देखें और उपयोगकर्ता इनपुट के संचित होने पर परिणामी क्वेरी को देखें।
myuser'-- / wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
क्योंकि माईसर के बच जाने के बाद एकल उद्धरण (मतलब इसे लक्ष्य मान का हिस्सा माना जाता है), डेटाबेस सचमुच यूजरनेम के लिए खोज करेगा "myuser'--". इसके अतिरिक्त, क्योंकि डैश स्ट्रिंग मान के भीतर शामिल हैं न कि एसक्यूएल स्टेटमेंट के रूप में, उन्हें एसक्यूएल टिप्पणी के रूप में व्याख्या किए जाने के बजाय लक्ष्य मूल्य का हिस्सा माना जाएगा।
Robert'; DROP TABLE Users;-- / wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
केवल रॉबर्ट के बाद एकल उद्धरण से बचकर, अर्धविराम और डैश दोनों UserName खोज स्ट्रिंग के भीतर समाहित हैं, इसलिए डेटाबेस शाब्दिक रूप से खोज करेगा "Robert'; DROP TABLE Users;--" टेबल डिलीट करने के बजाय निष्पादित करें।
संक्षेप में
जबकि वेब हमले अधिक विकसित होते हैंपरिष्कृत या प्रवेश के एक अलग बिंदु पर ध्यान केंद्रित करने के लिए, यह कोशिश करना और सच्चे हमलों से बचाने के लिए याद रखना महत्वपूर्ण है जो कई स्वतंत्र रूप से उपलब्ध "हैकर टूल्स" की प्रेरणा रहे हैं ताकि उनका शोषण किया जा सके।
कुछ प्रकार के हमले, जैसे कि DDoS, नहीं हो सकतेदूसरों से आसानी से बचा जा सकता है, जैसे कि SQLI, कर सकते हैं। हालाँकि, इस प्रकार के हमलों से जो नुकसान हो सकता है, वह कहीं भी बरती जाने वाली असुविधा से लेकर तबाही के आधार पर हो सकती है।
