एसक्यूएल इंजेक्शन क्या है और पीएचपी एप्लीकेशन में कैसे रोकें?

तो आपको लगता है कि आपका एसक्यूएल डेटाबेस प्रदर्शन और तत्काल विनाश से सुरक्षित है? खैर, SQL इंजेक्शन असहमत है!


हां, यह तत्काल विनाश है जिसके बारे में हम बात कर रहे हैं, क्योंकि मैं इस लेख को “कड़ी सुरक्षा” और “दुर्भावनापूर्ण पहुंच को रोकने” की सामान्य लंगड़ी शब्दावली के साथ नहीं खोलना चाहता। एसक्यूएल इंजेक्शन पुस्तक में एक ऐसी पुरानी चाल है जिसे हर कोई, हर डेवलपर, इसके बारे में अच्छी तरह से जानता है और इसे रोकने के तरीके के बारे में अच्छी तरह से जानता है। सिवाय उस एक विषम समय के जब वे फिसल जाते हैं, और परिणाम विनाशकारी से कम नहीं हो सकते हैं.

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

एसक्यूएल इंजेक्शन क्या है?

SQL इंजेक्शन को समझने की कुंजी इसके नाम में है: SQL + Injection। यहां “इंजेक्शन” शब्द का कोई चिकित्सकीय अर्थ नहीं है, बल्कि यह क्रिया “इंजेक्शन” का उपयोग है। साथ में, ये दो शब्द SQL को एक वेब एप्लिकेशन में डालने के विचार को व्यक्त करते हैं.

एक वेब अनुप्रयोग में SQL लाना। । । हम्म। । । क्या ऐसा नहीं है कि हम क्या कर रहे हैं? हां, लेकिन हम अपने डेटाबेस को चलाने के लिए एक हमलावर नहीं चाहते हैं। आइए इसे एक उदाहरण की मदद से समझते हैं.

मान लें कि आप स्थानीय ई-कॉमर्स स्टोर के लिए एक विशिष्ट PHP वेबसाइट का निर्माण कर रहे हैं, इसलिए आप इस तरह से संपर्क फ़ॉर्म जोड़ने का निर्णय लेते हैं:

आपका नाम

आपका सन्देश

और मान लें कि फ़ाइल send_message.php एक डेटाबेस में सब कुछ संग्रहीत करता है ताकि स्टोर के मालिक बाद में उपयोगकर्ता संदेशों को पढ़ सकें। यह इस तरह से कुछ कोड हो सकता है:

<?php

$ नाम = $ _POST [‘नाम’];
$ संदेश = $ _POST [‘संदेश’];

// जांचें कि क्या इस उपयोगकर्ता के पास पहले से कोई संदेश है
mysqli_query ($ Conn, "उन संदेशों से * का चयन करें जहां नाम = $ नाम");

// यहाँ अन्य कोड

इसलिए आप पहले यह देखने का प्रयास कर रहे हैं कि क्या इस उपयोगकर्ता के पास पहले से कोई अपठित संदेश है। क्वेरी का चयन * संदेशों से जहां नाम = $ नाम काफी सरल लगता है, सही है?

गलत!

हमारी मासूमियत में, हमने अपने डेटाबेस के तत्काल विनाश के लिए दरवाजे खोल दिए हैं। ऐसा होने के लिए, हमलावर को निम्नलिखित शर्तों को पूरा करना होगा:

  • एप्लिकेशन SQL डेटाबेस पर चल रहा है (आज, लगभग हर एप्लिकेशन है)
  • वर्तमान डेटाबेस कनेक्शन में डेटाबेस पर “संपादित करें” और “हटाएं” अनुमतियां हैं
  • महत्वपूर्ण तालिकाओं के नामों का अनुमान लगाया जा सकता है

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

जो; टुकड़े टुकड़े आदेश? जी श्रीमान! आइए देखें कि PHP स्क्रिप्ट द्वारा निष्पादित होने पर क्वेरी क्या बन जाएगी:

संदेशों का चयन करें * जहां से नाम = जो; truncate के आदेश;

ठीक है, क्वेरी के पहले भाग में एक सिंटैक्स त्रुटि है (“जो” के आसपास कोई उद्धरण नहीं है), लेकिन अर्ध-बृहदान्त्र MySQL इंजन को एक नया: ट्रंकट ऑर्डर की व्याख्या करने के लिए मजबूर करता है। ठीक उसी तरह, जैसे एक ही झटके में, पूरा क्रम इतिहास बन जाता है!

अब जब आप जानते हैं कि SQL इंजेक्शन कैसे काम करता है, तो यह समय है कि इसे कैसे रोका जाए। सफल SQL इंजेक्शन के लिए जिन दो शर्तों को पूरा करने की आवश्यकता है वे हैं:

  1. PHP स्क्रिप्ट में डेटाबेस पर विशेषाधिकारों को संशोधित / हटाना चाहिए। मुझे लगता है कि यह सभी अनुप्रयोगों के लिए सही है और आप अपने अनुप्रयोगों को केवल पढ़ने में सक्षम नहीं होंगे। Privileges और अनुमान लगाएं कि क्या, भले ही हम सभी संशोधित विशेषाधिकार हटा दें, लेकिन SQL इंजेक्शन अभी भी किसी को चुनिंदा प्रश्नों को चलाने और सभी डेटाबेस, संवेदनशील डेटा को देखने की अनुमति दे सकता है। दूसरे शब्दों में, डेटाबेस एक्सेस स्तर को कम करने से काम नहीं चलता है, और आपके आवेदन को वैसे भी इसकी आवश्यकता होती है.
  2. उपयोगकर्ता इनपुट संसाधित किया जा रहा है। SQL इंजेक्शन काम करने का एकमात्र तरीका है जब आप उपयोगकर्ताओं से डेटा स्वीकार कर रहे हैं। एक बार फिर, यह आपके अनुप्रयोग के लिए सभी इनपुटों को रोकने के लिए व्यावहारिक नहीं है क्योंकि आप SQL इंजेक्शन के बारे में चिंतित हैं.

PHP में SQL इंजेक्शन को रोकना

अब, यह देखते हुए कि डेटाबेस कनेक्शन, क्वेरीज़ और उपयोगकर्ता इनपुट जीवन का हिस्सा हैं, हम SQL इंजेक्शन को कैसे रोक सकते हैं? शुक्र है, यह बहुत आसान है, और इसे करने के दो तरीके हैं: 1) उपयोगकर्ता इनपुट को साफ करें, और 2) तैयार किए गए बयानों का उपयोग करें.

उपयोगकर्ता इनपुट को संचित करें

यदि आप पुराने PHP संस्करण का उपयोग कर रहे हैं (5.5 या उससे कम, और यह साझा होस्टिंग पर बहुत कुछ होता है), तो mysql_real_escape_string () नामक एक फ़ंक्शन के माध्यम से अपने सभी उपयोगकर्ता इनपुट को चलाने के लिए बुद्धिमान है। मूल रूप से, यह एक स्ट्रिंग में सभी विशेष वर्णों को निकालता है ताकि वे डेटाबेस द्वारा उपयोग किए जाने पर अपना अर्थ खो दें.

उदाहरण के लिए, यदि आपके पास एक स्ट्रिंग है जैसे मैं एक स्ट्रिंग हूं, तो एक क्वेरी वर्ण (be) का उपयोग किसी हमलावर द्वारा डेटाबेस क्वेरी को बनाए जाने में हेरफेर करने के लिए किया जा सकता है और SQL इंजेक्शन का कारण बन सकता है। इसे mysql_real_escape_string () के माध्यम से चलाना I \ ‘s स्ट्रिंग का निर्माण करता है, जो इसे से बचते हुए, एकल उद्धरण में एक बैकस्लैश जोड़ता है। परिणामस्वरूप, संपूर्ण स्ट्रिंग अब क्वेरी हेरफेर में भाग लेने में सक्षम होने के बजाय, डेटाबेस के लिए हानिरहित स्ट्रिंग के रूप में पारित हो जाती है.

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

तैयार कथनों का प्रयोग करें

तैयार किए गए बयान डेटाबेस प्रश्नों को अधिक सुरक्षित और मज़बूती से बनाने का एक तरीका है। विचार यह है कि डेटाबेस में कच्ची क्वेरी भेजने के बजाय, हम पहले डेटाबेस को उस क्वेरी की संरचना बताते हैं जिसे हम भेज रहे हैं। यह हम एक बयान “तैयारी” से क्या मतलब है। एक बार एक स्टेटमेंट तैयार हो जाने के बाद, हम सूचना को पैरामीट्रिज्ड इनपुट के रूप में पास करते हैं ताकि डेटाबेस उस इनपुट को प्लग करके “भर सके” जिसे हम पहले भेजे गए क्वेरी स्ट्रक्चर में इनपुट कर सकें। यह किसी भी विशेष शक्ति को हटा देता है जो इनपुट हो सकता है, जिससे उन्हें पूरी प्रक्रिया में मात्र चर (या पेलोड के रूप में माना जाता है)। यहाँ क्या तैयार बयान की तरह लग रहे हैं:

<?php
$ सर्वरनाम = "स्थानीय होस्ट";
$ उपयोगकर्ता नाम = "उपयोगकर्ता नाम";
$ पासवर्ड = "कुंजिका";
$ dbname = "mydb";

// कनेक्शन बनाएँ
$ con = new mysqli ($ servername, $ username, $ password, $ dbname);

// कनेक्शन की जाँच करें
अगर ($ कॉन->connect_error) {
मरने ("कनेक्शन विफल: " . $ Conn->connect_error);
}

// तैयार करें और बांधें
$ स्टमट = $ कॉन->तैयार("INSERT में MyGuests (Firstname, lastname, email) VALUES (?,?)?");
$ stmt->bind_param ("एसएसएस", $ Firstname, $ lastname, $ ईमेल);

// सेट पैरामीटर और निष्पादित
$ Firstname = "जॉन";
$ अंतिम नाम = "हरिणी";
$ ईमेल = "[ईमेल संरक्षित]";
$ stmt->निष्पादित();

$ Firstname = "मैरी";
$ अंतिम नाम = "मो";
$ ईमेल = "[ईमेल संरक्षित]";
$ stmt->निष्पादित();

$ Firstname = "जूली";
$ अंतिम नाम = "डूले";
$ ईमेल = "[ईमेल संरक्षित]";
$ stmt->निष्पादित();

गूंज "नए रिकॉर्ड सफलतापूर्वक बनाए गए";

$ stmt->बंद करे();
$ Conn->बंद करे();
?>

मुझे पता है कि यदि आप तैयार कथनों में नए हैं तो प्रक्रिया अनावश्यक रूप से जटिल लगती है, लेकिन अवधारणा अच्छी तरह से प्रयास के लायक है. यहां बताया गया है यह एक अच्छा परिचय है.

जो लोग पहले से ही PHP के PDO एक्सटेंशन से परिचित हैं और इसे तैयार स्टेटमेंट बनाने के लिए उपयोग कर रहे हैं, मेरे पास सलाह का एक छोटा सा टुकड़ा है.

चेतावनी: पीडीओ स्थापित करते समय सावधान रहें

डेटाबेस एक्सेस के लिए पीडीओ का उपयोग करते समय, हम सुरक्षा के झूठे अर्थों में चूसे जा सकते हैं। “आह, ठीक है, मैं पीडीओ का उपयोग कर रहा हूं। अब मुझे किसी और चीज के बारे में सोचने की जरूरत नहीं है ”- यह हमारी सोच आम तौर पर इसी तरह चलती है। यह सही है कि सभी प्रकार के SQL इंजेक्शन के हमलों को रोकने के लिए PDO (या MySQLi तैयार स्टेटमेंट) पर्याप्त है, लेकिन इसे सेट करते समय आपको सावधान रहना चाहिए। ट्यूटोरियल से या पहले की परियोजनाओं से कोड कॉपी-पेस्ट करना आम बात है और आगे बढ़ना है, लेकिन यह सेटिंग सब कुछ पूर्ववत कर सकती है:

$ dbConnection->setAttribute (PDO :: ATTR_EMULATE_PREPARES, सच);

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

समाधान सरल है: सुनिश्चित करें कि यह अनुकरण गलत पर सेट है.

$ dbConnection->setAttribute (PDO :: ATTR_EMULATE_PREPARES, गलत);

अब SQL स्क्रिप्ट के सभी प्रकारों को रोकने के लिए PHP स्क्रिप्ट को डेटाबेस स्तर पर तैयार कथनों का उपयोग करने के लिए मजबूर किया जाता है.

WAF का उपयोग करना रोकना

क्या आप जानते हैं कि आप WAF (वेब ​​एप्लिकेशन फ़ायरवॉल) का उपयोग करके वेब अनुप्रयोगों को SQL इंजेक्शन से भी बचा सकते हैं?

ठीक है, न केवल एसक्यूएल इंजेक्शन बल्कि कई अन्य परतें 7 भेद्यताएं जैसे क्रॉस-साइट स्क्रिप्टिंग, टूटी प्रमाणीकरण, क्रॉस-साइट जालसाजी, डेटा एक्सपोज़र, आदि। या तो आप स्वयं की मेजबानी कर सकते हैं जैसे कि मॉड सुरक्षा या क्लाउड-आधारित निम्नानुसार.

SQL इंजेक्शन और आधुनिक PHP चौखटे

एसक्यूएल इंजेक्शन इतना सामान्य, इतना आसान, इतना निराशाजनक और इतना खतरनाक है कि सभी आधुनिक PHP वेब फ्रेमवर्क में काउंटर-काउंटर के साथ निर्मित होते हैं। वर्डप्रेस में, उदाहरण के लिए, हमारे पास $ wpdb है->तैयार () फ़ंक्शन, जबकि यदि आप MVC फ्रेमवर्क का उपयोग कर रहे हैं, तो यह आपके लिए सभी गंदे काम करता है और आपको SQL इंजेक्शन को रोकने के बारे में सोचना भी नहीं है। यह थोड़ा कष्टप्रद है कि वर्डप्रेस में आपको स्पष्ट रूप से स्टेटमेंट तैयार करना है, लेकिन हे, हम जिस वर्डप्रेस के बारे में बात कर रहे हैं। ��

वैसे भी, मेरी बात यह है कि वेब डेवलपर्स की आधुनिक नस्ल को SQL इंजेक्शन के बारे में नहीं सोचना पड़ता है, और परिणामस्वरूप, वे संभावना के बारे में भी नहीं जानते हैं। जैसे, भले ही वे अपने आवेदन में एक पिछले दरवाजे को खुला छोड़ देते हैं (शायद यह एक $ _GET क्वेरी पैरामीटर है और एक गंदे क्वेरी किक को बंद करने की पुरानी आदतें), परिणाम भयावह हो सकते हैं। इसलिए नींव में गहराई तक गोता लगाने के लिए समय निकालना हमेशा बेहतर होता है.

निष्कर्ष

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map