SQL इंजेक्शन SQLi
एक वेब हमला, जिसमें कोई व्यक्ति फ़ॉर्म या वेब पते में डेटाबेस के कमांड लिख देता है। वेबसाइट उन्हें चला देती है और वह डेटा दिखा देती है, बदल देती है या मिटा देती है जिसे उसे सुरक्षित रखना चाहिए।
इसे इस नाम से भी जाना जाता है SQLi SQL Injection SQL इंजेक्शन अटैक SQL कोड इंजेक्शन डेटाबेस इंजेक्शन इंजेक्शन हमला
परिभाषा
SQL इंजेक्शन क्या है
आप एक ऑनलाइन दुकान चलाते हैं। एक विज़िटर सर्च बॉक्स में कुछ अजीब सा लिखता है, Enter दबाता है, और पेज उसे आपके सारे ग्राहकों के नाम, फ़ोन नंबर और ऑर्डर का इतिहास दिखा देता है। किसी ने पासवर्ड नहीं चुराया। उसने सही शब्द गलत जगह पर लिखे, और बाकी काम आपकी वेबसाइट ने कर दिया। यही SQL इंजेक्शन है।
ज़्यादातर वेबसाइटें अपनी जानकारी एक डेटाबेस में रखती हैं: तालिकाओं का एक व्यवस्थित भंडार, कुछ हद तक स्प्रेडशीट के एक सेट जैसा। इस जानकारी को पढ़ने या बदलने के लिए वेबसाइट SQL (Structured Query Language) नाम की भाषा बोलती है। वह जो भी अनुरोध भेजती है, उसे क्वेरी कहते हैं, जैसे "वह ग्राहक ढूँढ़ो जिसका ईमेल यह है"।
SQL इंजेक्शन तब होता है जब वेबसाइट विज़िटर का लिखा हुआ टेक्स्ट लेकर सीधे इनमें से किसी क्वेरी में चिपका देती है। अगर विज़िटर सामान्य टेक्स्ट की जगह SQL लिख दे, तो डेटाबेस फ़र्क नहीं पहचान पाता और हमलावर के कमांड को ऐसे मानता है जैसे वेबसाइट ने खुद लिखा हो। लोग इसे अक्सर छोटा करके SQLi कहते हैं।
SQL इंजेक्शन हमला कैसे काम करता है
एक बैंक क्लर्क के बारे में सोचिए जो ग्राहक की दी हुई हर पर्ची को शब्दशः तिजोरी वाले कर्मचारियों तक पहुँचा देता है। सामान्य पर्ची कहती है "मेरा बैलेंस दिखाइए"। चालाकी वाली पर्ची कहती है "मेरा बैलेंस दिखाइए, और सारी तिजोरियाँ भी खोल दीजिए"। अगर क्लर्क पहले कभी पर्ची नहीं पढ़ता, तो तिजोरी वाले कर्मचारी वही कर देते हैं।
वेबसाइट पर कदम आम तौर पर ऐसे होते हैं:
- हमलावर ऐसी जगह ढूँढ़ता है जो डेटाबेस को टेक्स्ट भेजती है: लॉगिन फ़ॉर्म, सर्च बॉक्स, संपर्क फ़ॉर्म, या खुद वेब पता, जैसे किसी प्रोडक्ट पेज का पता जो "?id=25" पर खत्म होता है।
- वह सामान्य टेक्स्ट की जगह SQL का एक छोटा सा टुकड़ा लिखता है। एक जाना माना उदाहरण है लॉगिन फ़ॉर्म के पासवर्ड वाले खाने में ' OR '1'='1 लिखना।
- वेबसाइट उस टेक्स्ट को बिना जाँचे अपनी क्वेरी में जोड़ देती है। अब क्वेरी कुछ ऐसा पूछती है: "इस व्यक्ति को अंदर आने दो अगर पासवर्ड सही है, या अगर 1 बराबर है 1 के"।
- क्योंकि 1 हमेशा 1 के बराबर होता है, डेटाबेस हाँ कह देता है, और हमलावर बिना कोई पासवर्ड जाने लॉगिन हो जाता है।
कुछ हमले ज़्यादा चुपचाप होते हैं। ब्लाइंड SQL इंजेक्शन में पेज कोई डेटा नहीं दिखाता, इसलिए हमलावर डेटाबेस से हाँ या ना वाले सवाल पूछता है और देखता है कि पेज कैसी प्रतिक्रिया देता है या लोड होने में कितना समय लेता है। हाथ से यह धीमा काम है, इसीलिए हमलावर मुफ़्त ऑटोमैटिक टूल से यह काम करवाते हैं।
हमलावर इससे क्या कर सकता है
जब डेटाबेस उसके कमांड मानने लगता है, तो नुकसान इस पर निर्भर करता है कि वेबसाइट के डेटाबेस अकाउंट को क्या करने की अनुमति है। अक्सर यह वेबसाइट की ज़रूरत से कहीं ज़्यादा होती है। हमलावर ये कर सकता है:
- निजी डेटा पढ़ना, जैसे ग्राहकों के नाम, पते, ईमेल, ऑर्डर का इतिहास, मेडिकल रिकॉर्ड या सेव किए गए पासवर्ड
- किसी दूसरे यूज़र के नाम से लॉगिन करना, एडमिन के नाम से भी
- डेटा बदलना, जैसे दाम, बैलेंस या ऑर्डर का स्टेटस
- पूरी तालिकाएँ मिटाना, या पूरा डेटाबेस
- कुछ सेटअप में खुद सर्वर तक पहुँचना और उस पर हानिकारक फ़ाइलें रख देना
यह आपके कारोबार के लिए क्यों मायने रखता है
SQL इंजेक्शन सबसे पुराने वेब हमलों में से एक है, और यह आज भी मौजूद है। OWASP एक खुला समुदाय है जो वेब एप्लिकेशन के खतरों की मशहूर सूची OWASP Top 10 प्रकाशित करता है, और उसने इंजेक्शन को सालों से इस सूची में रखा है। इसे आज़माना आसान है, और कई वेबसाइटों में अब भी कोई भूला हुआ फ़ॉर्म होता है जो इसके लिए खुला रहता है।
कारोबार के मालिक के लिए असली नुकसान शायद ही कभी तकनीकी होता है। यह लीक हुई ग्राहक सूची हो सकती है, गलत दाम पर सामान बेचती दुकान, एक हफ़्ते की अपॉइंटमेंट गँवा देने वाला बुकिंग सिस्टम, या वह संदेश जो आपको ग्राहकों को भेजना पड़े कि उनका डेटा उजागर हो गया। कई देशों में GDPR जैसे डेटा सुरक्षा कानून भी आपसे उम्मीद करते हैं कि आप निजी डेटा की रक्षा करें और लीक की सूचना दें।
क्या आपकी वेबसाइट का हर फ़ॉर्म इस खतरे को ध्यान में रखकर बनाया गया था? जो वेबसाइटें पुराने प्लगइन से जल्दी में बनाई गईं, या सालों में कई हाथों से बदली गईं, उनमें कोई कमज़ोर जगह छिपी होने की संभावना ज़्यादा होती है।
वेबसाइट को SQL इंजेक्शन से कैसे बचाएँ
मुख्य उपाय सबको पता है, और यह काम करता है। ज़्यादातर सुरक्षा इस बात में है कि वेबसाइट कैसे बनाई गई है, इसलिए ये सवाल आपको अपने डेवलपर या सेवा देने वाले से पूछने चाहिए।
- प्रिपेयर्ड स्टेटमेंट। इन्हें पैरामीटर वाली क्वेरी भी कहते हैं। वेबसाइट क्वेरी और विज़िटर का टेक्स्ट अलग अलग भेजती है, इसलिए डेटाबेस उस टेक्स्ट को हमेशा सिर्फ़ डेटा मानता है, कभी कमांड नहीं। यही मुख्य बचाव है। Laravel जैसे आधुनिक फ़्रेमवर्क यह अपने आप करते हैं, जब डेवलपर उनके बने बनाए डेटाबेस टूल इस्तेमाल करते हैं।
- इनपुट की जाँच। फ़ोन नंबर वाले खाने में सिर्फ़ अंक आने चाहिए, और तारीख वाले खाने में सिर्फ़ तारीख। अजीब इनपुट को शुरू में ही मना कर देने से कई दरवाज़े बंद हो जाते हैं।
- कम से कम अधिकार। वेबसाइट जिस अकाउंट से डेटाबेस तक पहुँचती है, उसके पास सिर्फ़ उतने ही अधिकार होने चाहिए जितने उसे चाहिए। एक सार्वजनिक सर्च पेज के पास तालिकाएँ मिटाने की कोई वजह नहीं है।
- कम बोलने वाले एरर मैसेज। स्क्रीन पर डेटाबेस की विस्तृत गलती हमलावर को नक्शा थमा देती है। विज़िटर को छोटा और सरल संदेश दिखाएँ, और ब्योरा निजी लॉग में रखें।
- अपडेट। प्लेटफ़ॉर्म, प्लगइन और लाइब्रेरी को अपडेट रखें, क्योंकि पुराने वर्ज़न में अक्सर जानी मानी खामियाँ होती हैं।
- वेब एप्लिकेशन फ़ायरवॉल। यह वेबसाइट के सामने लगा एक फ़िल्टर है जो कई जाने पहचाने हमलों को आपके कोड तक पहुँचने से पहले रोक देता है। यह मदद करता है, लेकिन असुरक्षित कोड को ठीक नहीं करता।
- नियमित टेस्ट। पेनिट्रेशन टेस्ट (विशेषज्ञों का किया सुरक्षित और योजनाबद्ध हमला) और वल्नरेबिलिटी स्कैन कमज़ोर जगहों को हमलावर से पहले ढूँढ़ लेते हैं।
रोज़ की आदतों की तुलना कुछ ऐसी है:
| जोखिम भरी आदत | ज़्यादा सुरक्षित आदत |
|---|---|
| विज़िटर का टेक्स्ट सीधे क्वेरी में जोड़ना | हर क्वेरी के लिए प्रिपेयर्ड स्टेटमेंट इस्तेमाल करना |
| हर काम के लिए पूरे अधिकारों वाला एक ही डेटाबेस अकाउंट | वेबसाइट के हर हिस्से के लिए सीमित अकाउंट |
| पेज पर डेटाबेस की पूरी गलतियाँ दिखाना | विज़िटर के लिए छोटा संदेश, ब्योरा निजी लॉग में |
| महीनों तक बिना अपडेट के पड़े प्लगइन | नियमित अपडेट और इंस्टॉल की गई चीज़ों की साफ़ सूची |
| सिर्फ़ यह जाँचना कि फ़ीचर चल रहे हैं | यह भी जाँचना कि कोई हानिकारक चीज़ लिखे तो क्या होता है |
लोग कौन सी गलतियाँ करते हैं
- ब्राउज़र की जाँच पर भरोसा करना। विज़िटर के अपने डिवाइस पर चलने वाली जाँच से बचना आसान है, इसलिए सर्वर को सब कुछ दोबारा जाँचना चाहिए।
- यह सोचना कि छोटी वेबसाइट सुरक्षित है। ऑटोमैटिक टूल बहुत बड़ी संख्या में वेबसाइटें जाँचते हैं, चाहे वे कितनी भी बड़ी या छोटी हों।
- एक फ़ॉर्म ठीक करना और बाकी भूल जाना। सर्च बॉक्स, फ़िल्टर, वेब पता और मोबाइल ऐप के पीछे का API, सबको एक जैसी देखभाल चाहिए।
- पासवर्ड को सादे टेक्स्ट में रखना। अगर डेटा लीक हो जाए, तो मज़बूत हैशिंग से रखे गए पासवर्ड (ऐसे उलझे कोड में बदले गए जिसे वापस पढ़ा नहीं जा सकता) का गलत इस्तेमाल करना बहुत मुश्किल होता है।
- सिर्फ़ फ़ायरवॉल पर निर्भर रहना। फ़िल्टर आपको समय देता है। उसके पीछे की असुरक्षित क्वेरी को फिर भी ठीक करना पड़ता है।
हम कैसे मदद कर सकते हैं
Linkysoft में SQL इंजेक्शन की जाँच हमारी साइबर सुरक्षा सेवाओं का हिस्सा है। हम आपकी वेबसाइट, ऐप और API पर सुरक्षित, नकली हमले करते हैं, कोड की समीक्षा करते हैं, और आपको आसान भाषा में एक सूची देते हैं कि हमें क्या मिला और उसे कैसे ठीक करना है। सुधार के बाद हम फिर से टेस्ट करते हैं। यह दूसरी टीमों की बनाई वेबसाइटों के लिए भी काम करता है, और मुफ़्त सुरक्षा जाँच एक आसान पहला कदम है।
नया सिस्टम बनाने की सोच रहे हैं? हमारे वेब एप्लिकेशन और मैनेजमेंट सिस्टम शुरू से ही सुरक्षित बनाए जाते हैं, OWASP Top 10 के अनुसार मज़बूती और लॉन्च से पहले पेनिट्रेशन टेस्ट के साथ।
SQL इंजेक्शन से जुड़े सवाल
आसान शब्दों में SQL इंजेक्शन क्या है?
क्या छोटी वेबसाइट पर भी SQL इंजेक्शन हो सकता है?
मुझे कैसे पता चलेगा कि मेरी वेबसाइट SQL इंजेक्शन के लिए कमज़ोर है?
SQL इंजेक्शन रोकने का सबसे अच्छा तरीका क्या है?
क्या फ़ायरवॉल SQL इंजेक्शन को रोक देता है?
ब्लाइंड SQL इंजेक्शन क्या है?
अगर मेरी वेबसाइट पर SQL इंजेक्शन हो गया तो क्या करूँ?
क्या SQL इंजेक्शन सिर्फ़ वेबसाइटों की समस्या है?
अभी भी पक्का नहीं कि यह आपके प्रोजेक्ट पर कैसे लागू होता है?
हमें बताएं आप क्या बना रहे हैं और हम सीधी भाषा में जवाब देंगे।