एक साइट को SQL इंजेक्शन से कैसे सुरक्षित करें

SQL इंजेक्शन के खिलाफ साइट की सुरक्षा: डेटाबेस हमलों से वेब संसाधन की रक्षा कैसे करें

SQL इंजेक्शन तब होता है जब दुर्भावनापूर्ण SQL कोड डेटाबेस क्वेरी में प्रवेश करता है और किसी और की लॉजिक को लागू करना शुरू कर देता है। आमतौर पर, हमलावर "सामान्य" पाठ नहीं डालता, बल्कि एक ऐसा अंश जो क्वेरी के अर्थ को बदल देता है - उदाहरण के लिए, प्रमाणीकरण को बायपास करने, तालिकाओं से रिकॉर्ड निकालने, या उन्हें हटाने में मदद करना।

यहां खतरा बहुत व्यावहारिक है। लॉगिन, पासवर्ड, पते, ऑर्डर, आंतरिक सेटिंग्स, सत्र टोकन, और यहां तक कि साइट के प्रशासनिक कार्य भी उजागर हो सकते हैं। एक लापरवाह क्वेरी डेटा तक पहुंच खोल सकती है जिसे आप कभी भी किसी को दिखाने का इरादा नहीं रखते थे, यही कारण है कि SQL इंजेक्शन सुरक्षा को शुरू से ही कोड में शामिल किया जाना चाहिए।

SQL इंजेक्शन भी खतरनाक है क्योंकि यह लंबे समय तक छिपा रह सकता है, और साइट सामान्य लग सकती है, फॉर्म काम कर सकते हैं, कार्ट ऑर्डर स्वीकार कर सकता है, जबकि डेटाबेस में पहले से ही एक बैकडोर मौजूद है। कभी-कभी समस्या केवल लीक या तालिकाओं में अजीब रिकॉर्ड के बाद ही खोजी जाती है।

व्यवहार में SQL इंजेक्शन हमले कैसे काम करते हैं

सबसे सरल परिदृश्य एक लॉगिन फॉर्म है। एक उपयोगकर्ता एक उपयोगकर्ता नाम और पासवर्ड दर्ज करता है, और एप्लिकेशन बिना किसी पैरामीटर के एक डेटाबेस क्वेरी बनाता है। यदि क्वेरी स्ट्रिंग मैन्युअल रूप से बनाई जाती है, तो एक हमलावर पासवर्ड के बजाय एक SQL का टुकड़ा दर्ज कर सकता है जो जांच को तोड़ता है या खोज की शर्त को बदलता है।

URL पैरामीटर के माध्यम से, हमला लगभग नियमित लगता है। उदाहरण के लिए, एक कैटलॉग पृष्ठ स्वीकार करता है ?id=15, और सर्वर उत्पादों की तालिका को क्वेरी करता है। यदि आप संख्या के अलावा कुछ और पास करते हैं - एक अभिव्यक्ति जिसे डेटाबेस SQL के भाग के रूप में स्वीकार करता है - तो आप अतिरिक्त पंक्तियाँ प्राप्त कर सकते हैं या किसी और के रिकॉर्ड देख सकते हैं। यही कारण है कि लिंक और फ़िल्टर को SQL इंजेक्शन को रोकने के बारे में सोचते समय कभी भी

कुकीज़ का उपयोग भी ऐसे हमले के लिए किया जा सकता है। यदि साइट एक कुकी मान पढ़ती है और इसे बिना सत्यापन के SQL क्वेरी में डालती है, तो हमलावर ब्राउज़र में कुकी को बदलता है और एक खतरनाक स्ट्रिंग प्रदान करता है। API अनुरोध इसी तरह काम करते हैं: JSON या फ़ॉर्म पैरामीटर सर्वर पर जाते हैं, और सर्वर लापरवाही से क्वेरी बनाता है। तीन प्रवेश बिंदु, एक समस्या।

व्यवहार में, हमला शायद ही कभी नाटकीय दिखता है, और अधिकतर यह एक अजीब चरित्र, एक अतिरिक्त उद्धरण, एक पैरामीटर होता है जिसे

मुख्य संकेत कि एक साइट कमजोर हो सकती है

पहला स्पष्ट संकेत स्क्रीन पर डेटाबेस त्रुटियाँ हैं। यदि SQL सिंटैक्स संदेश, तालिका के नाम, या कनेक्शन ड्राइवर विवरण अचानक खोज या फ़िल्टर फ़ील्ड में टेक्स्ट दर्ज करते समय दिखाई देते हैं, तो यह एक बुरा संकेत है।

दूसरा संकेत अजीब फॉर्म व्यवहार है। एक लॉगिन फॉर्म गलत डेटा को बहुत आसानी से स्वीकार करता है, एक फ़िल्टर अधिक परिणाम लौटाता है जितना उसे करना चाहिए, और खोज एक क्वेरी के लिए रिकॉर्ड ढूंढना शुरू कर देती है जो सामान्य पाठ से भी मेल नहीं खाता, और यह व्यवहार अक्सर संकेत करता है कि पैरामीटर SQL तक सख्त हैंडलिंग के बिना पहुँच रहे हैं।

तीसरा संकेत डेटा तक अनधिकृत पहुँच है। उदाहरण के लिए, एक उपयोगकर्ता अन्य लोगों के ऑर्डर, प्रोफाइल, या आंतरिक फ़ील्ड देखता है जो कभी भी इंटरफ़ेस में नहीं दिखने चाहिए। कभी-कभी यह चुपचाप प्रकट होता है: रिपोर्ट में अतिरिक्त पंक्तियाँ दिखाई देती हैं, या प्रशासन पैनल में परिवर्तन दिखाई देते हैं जो किसी ने नहीं किए।

कम स्पष्ट संकेत भी हैं। साइट कुछ अनुरोधों पर धीमी होने लगती है, लॉग में बार-बार त्रुटियाँ दिखाई देती हैं, और जब एक पैरामीटर थोड़ा बदलता है तो वही पृष्ठ अलग तरीके से प्रतिक्रिया करता है, और यह अभी तक हमले का प्रमाण नहीं है, लेकिन यह कोड और डेटाबेस की जांच करने का एक कारण है।

SQL इंजेक्शन से साइट की सुरक्षा: बुनियादी उपाय

पहला और सबसे महत्वपूर्ण उपाय पैरामीटरयुक्त क्वेरी हैं। जब एक मान SQL पाठ से अलग पास किया जाता है, तो डेटाबेस इसे डेटा के रूप में मानता है, न कि कमांड के भाग के रूप में। यह एक सरल सिद्धांत है, लेकिन यह अधिकांश सामान्य हमलों को रोकता है।

तैयार बयानों का काम उसी भावना में होता है। पहले एप्लिकेशन क्वेरी संरचना को परिभाषित करता है, फिर यह पैरामीटर के माध्यम से मान भरता है। यह दृष्टिकोण विशेष रूप से उन स्थानों पर उपयोगी है जहाँ समान संचालन अक्सर दोहराए जाते हैं: लॉगिन, खोज, फ़िल्टरिंग, प्रोफाइल अपडेट, ऑर्डर निर्माण। व्यावहारिक रूप से, पैरामीटरयुक्त क्वेरी बनाम तैयार बयानों का चयन लगातार सुरक्षित पैटर्न का उपयोग करने की तुलना में कम महत्वपूर्ण है।

ORM का सावधानी से उपयोग करने पर भी मदद मिलती है। ORM अपने आप में आपको गलतियों से नहीं बचाता है यदि डेवलपर बिना पैरामीटर के तरीकों में कच्चा SQL डालता है, लेकिन सामान्य परिदृश्यों में, ORM मैन्युअल रूप से तैयार किए गए प्रश्नों के जोखिम को कम करता है और कोड को अधिक पूर्वानुमानित बनाता है। यहाँ अनुशासन पुस्तकालय के नाम से अधिक महत्वपूर्ण है।

मान्यता इनपुट चरण पर आवश्यक है, बाद में नहीं। यदि एक फ़ील्ड में संख्या होनी चाहिए, तो उसे संख्या ही होनी चाहिए; यदि यह एक ईमेल है, तो प्रारूप की जांच करें; यदि यह एक तारीख है, तो पैटर्न को सीमित करें। एस्केपिंग पैरामीटराइजेशन का स्थान नहीं लेती, लेकिन कभी-कभी यह इसे पूरा करती है, विशेष रूप से आउटपुट में और विरासती कोड में। बस SQL इंजेक्शन को "कोट्स को बदलने" से ठीक करने की कोशिश न करें - यह एक बुरी आदत है, सुरक्षा नहीं।

कोड स्तर पर व्यक्तिगत प्रवेश बिंदुओं का परीक्षण करना भी उपयोगी है। SQL कहाँ बनाया जाता है? उपयोगकर्ता इनपुट कहाँ आता है? स्ट्रिंग्स कहाँ मैन्युअल रूप से जोड़ी जाती हैं? तीन प्रश्न, और यह स्पष्ट हो जाता है कि पहले क्या फिर से लिखा जाना चाहिए।

SQL इंजेक्शन के जोखिम को कम करने के लिए अतिरिक्त सुरक्षा उपाय

डेटाबेस के लिए न्यूनतम विशेषाधिकार का सिद्धांत डिफ़ॉल्ट रूप से सक्षम होना चाहिए। एप्लिकेशन खाता को सब कुछ करने की अनुमति नहीं होनी चाहिए: इसे सिस्टम तालिकाओं, अनावश्यक स्कीमाओं, या खतरनाक संचालन तक पहुँच की आवश्यकता नहीं है, और यदि साइट केवल एक कैटलॉग पढ़ती है, तो इसे रिकॉर्ड हटाने की अनुमति नहीं होनी चाहिए।

एक्सेस को अलग करना भी मदद करता है। आप प्रशासन पैनल, सार्वजनिक साइट और बैकग्राउंड जॉब्स के लिए विभिन्न खातों और विभिन्न अनुमति सेट का उपयोग कर सकते हैं। फिर, भले ही एक मॉड्यूल में कोई दोष हो, हमलावर को पूरे डेटाबेस तक पहुंच नहीं मिलती। यह विशेष रूप से उन परियोजनाओं पर ध्यान देने योग्य है जिनमें कई भूमिकाएँ और कई प्रवेश बिंदु हैं; हमने इसके समान साइट आर्किटेक्चर कार्यों को लेख में कवर किया है कॉर्पोरेट वेबसाइट संरचना.

विस्तृत त्रुटियों को उपयोगकर्ताओं से छिपा कर रखना बेहतर है। “SQL सिंटैक्स त्रुटि के पास...” जैसा संदेश डेवलपर्स के लिए सुविधाजनक है, लेकिन उत्पादन में हानिकारक है, और उपयोगकर्ता को एक तटस्थ प्लेसहोल्डर देखना चाहिए, जबकि विवरण लॉग में जाना चाहिए।

लॉगिंग हमले के प्रयासों का पता लगाने में मदद करती है इससे पहले कि वे एक घटना बन जाएं। असफल अनुरोधों की श्रृंखला, एक ही मार्ग पर दोहराई गई त्रुटियाँ, अजीब पैरामीटर मान, और संवेदनशील पृष्ठों पर दोहराई गई विज़िट की तलाश करें। लॉग अपने आप में सुरक्षा नहीं देते, लेकिन वे निशान छोड़ते हैं।

डेटाबेस खाता क्षमताओं को सीमित करना सुरक्षा की एक और व्यावहारिक परत है, और यदि एप्लिकेशन को DELETE या DROP TABLE की आवश्यकता नहीं है, तो उन ऑपरेशनों की अनुमति नहीं दी जानी चाहिए। जब खाता डेटाबेस संरचना को नहीं बदल सकता, तो हमले का एक भाग बस अपना अर्थ खो देता है।

SQL इंजेक्शन कमजोरियों के लिए एक साइट की जांच कैसे करें

परीक्षण को लाइव साइट पर नहीं, बल्कि एक स्टेजिंग वातावरण में शुरू करना सबसे अच्छा है। वहाँ आप बिक्री का जोखिम उठाए बिना, प्रशासन पैनल को तोड़े बिना, या तालिकाओं को नुकसान पहुँचाए बिना परिदृश्यों को पुन: उत्पन्न कर सकते हैं। परीक्षण के लिए कोड की एक प्रति, कॉन्फ़िगरेशन की एक प्रति, और लॉग तक पहुंच की आवश्यकता होती है।

हाथ से परीक्षण संदिग्ध स्थानों के चारों ओर बनाया गया है: लॉगिन, खोज, फ़िल्टर, क्रमबद्ध करना, उत्पाद पृष्ठ, API विधियाँ, और एक बार में एक पैरामीटर बदलें और देखें कि एप्लिकेशन कैसे प्रतिक्रिया करता है। यदि डेटाबेस त्रुटि केवल एक मान के लिए प्रकट होती है, तो यह पहले से ही एक संकेत है। यदि एक उद्धरण के कारण व्यवहार बदलता है, तो समस्या की गहरी विश्लेषण की आवश्यकता है।

स्वचालित स्कैनर उपयोगी होते हैं, लेकिन वे जादू नहीं हैं, और वे सामान्य मामलों को ढूंढते हैं, लेकिन वे जटिल श्रृंखलाओं को छोड़ सकते हैं या, इसके विपरीत, गलत सकारात्मक परिणाम उत्पन्न कर सकते हैं। इसलिए एक स्कैनर पहला चरण है, अंतिम निर्णय नहीं। इसके बाद, आपको एक व्यक्ति की आवश्यकता होती है जो अनुप्रयोग लॉजिक को समझता हो।

उत्पादन पर, सतर्कता आवश्यक है। आक्रामक परीक्षण डेटाबेस को ओवरलोड कर सकता है, लॉग को अव्यवस्थित कर सकता है, और यदि कहीं एक खतरनाक प्रवेश बिंदु पहले से मौजूद है, तो डेटा को भी नुकसान पहुंचा सकता है, और एक लाइव साइट के लिए, हल्के परीक्षण पर टिके रहना बेहतर है और जोखिम भरे परिदृश्यों को स्टेजिंग और बैकअप के लिए छोड़ देना चाहिए।

यदि साइट बड़ी है, तो ऑडिट को दो चरणों में विभाजित करना समझदारी है: पहले महत्वपूर्ण फॉर्म और एपीआई, फिर कम दृश्य क्षेत्रों। यह दृष्टिकोण समय बचाता है और लाइव प्रक्रिया को गलती से बाधित करने की संभावना को कम करता है। यहाँ जल्दी करने की कोई आवश्यकता नहीं है।

यदि SQL इंजेक्शन पहले ही हो चुका है तो क्या करें

पहला कदम घटना को अलग करना है। यदि सक्रिय हमले का संदेह है, तो अस्थायी रूप से कमजोर मॉड्यूल तक पहुंच को प्रतिबंधित करें, इसे सुरक्षित मोड में स्विच करें, या समस्या वाले फीचर को बंद करें, और एक छोटा विराम व्यापक लीक से बेहतर है।

इसके बाद, पासवर्ड और एक्सेस कुंजी बदलें। इसमें डेटाबेस पासवर्ड, अनुप्रयोग रहस्य, एकीकरण टोकन, एपीआई कुंजी, और यदि वे जोखिम में हो सकते हैं तो व्यवस्थापक क्रेडेंशियल शामिल हैं। एक बार समझौता किया गया रहस्य अक्सर अन्य को भी खींच लेता है।

फिर आपको लॉग विश्लेषण की आवश्यकता है। देखें कि घटना से पहले कौन से अनुरोध किए गए थे, कौन से आईपी दोहराए गए, कौन से पैरामीटर बदले गए, और कौन से तालिकाएँ पढ़ी या संशोधित की गईं, और यदि बैकअप उपलब्ध हैं, तो डेटा परिवर्तनों के समय की तुलना संदिग्ध गतिविधि के क्षण से करें। यह आपको एक स्पष्ट समयरेखा देता है।

इसके बाद, यदि डेटाबेस की अखंडता प्रभावित हुई है, तो एक साफ बैकअप से डेटा पुनर्स्थापित करें। जब तक न केवल छिद्र बंद नहीं हो जाता, बल्कि इसके परिणाम भी नहीं होते, तब तक साइट को सामान्य पर लौटने के लिए जल्दी न करें। अन्यथा, हमला फिर से उसी बिंदु के माध्यम से होगा।

अंतिम कदम है कमजोरियों को बंद करना और साइट का फिर से परीक्षण करना, और सुधार को मूल गलती के समान पथ से गुजरना चाहिए: कोड, परीक्षण, स्टेजिंग, फिर उत्पादन। बिना पुनः परीक्षण के, आप केवल आशा कर सकते हैं - और आशा इस तरह के मामलों में एक कमजोर उपकरण है।

SQL इंजेक्शनों से साइट की सुरक्षा के लिए व्यावहारिक चेकलिस्ट

• जहां भी उपयोगकर्ता इनपुट SQL तक पहुंचता है, वहां पैरामीटराइज्ड क्वेरीज़ का उपयोग करें।
• इनपुट को प्रकार द्वारा मान्य करें: संख्या, ईमेल, तिथि, अनुमत मानों की सूची।
• स्ट्रिंग्स को जोड़कर SQL मैन्युअल रूप से न बनाएं।
• अपने ORM की समीक्षा करें: सुरक्षित तरीके हां, बिना पैरामीटर के कच्चा SQL नहीं।
• डेटाबेस खाते को न्यूनतम आवश्यक विशेषाधिकारों तक सीमित करें।
• इंटरफेस में उपयोगकर्ताओं से विस्तृत डेटाबेस त्रुटियों को छिपाएं।
• त्रुटियों, संदिग्ध पैरामीटरों और असफल अनुरोधों के लिए लॉगिंग सक्षम करें।
• तैनाती से पहले स्टेजिंग में कमजोर क्षेत्रों का परीक्षण करें।
• फॉर्म, URL पैरामीटर, कुकीज़ और API एंडपॉइंट्स को मैन्युअल रूप से जांचें।
• बैकअप और पुनर्प्राप्ति योजना को उत्पादन सर्वर से अलग रखें।

यदि साइट पहले से ही गंभीर ट्रैफ़िक संभाल रही है, तो लॉन्च के बाद समर्थन कैसे सेट किया गया है, इसकी जांच करें। डेटाबेस-चालित परियोजना के लिए, यह एक औपचारिकता नहीं है: अपडेट, सुधार और लॉग निगरानी नियमित रूप से आवश्यक हैं, हर छह महीने में एक बार नहीं। इस संदर्भ में, लेख पर लॉन्च के बाद साइट समर्थन उपयोगी है।

नियमित ऑडिट भी महत्वपूर्ण हैं। एक SQL इंजेक्शन को एक बार बंद करना पर्याप्त नहीं है यदि एक महीने बाद प्रोजेक्ट को एक नया फॉर्म, एक नया API विधि, या एक पुराना स्क्रिप्ट मिलता है जो अभी भी मैन्युअल रूप से क्वेरी बनाता है। SQL इंजेक्शन से साइट की सुरक्षा एक पैच पर निर्भर नहीं करती, बल्कि हर बार जब डेटाबेस लॉजिक बदलता है, कोड और अनुमतियों की जांच करने की आदत पर निर्भर करती है।