PHP और MySQL में SQL इंजेक्शन के खिलाफ सुरक्षा

अपने आश्चर्य के लिए, मुझे इंजेक्शन के खिलाफ सुरक्षा के विषय पर हबेरा का एक विस्तृत लेख नहीं मिला। इसलिए, मैंने अपना लिखने का फैसला किया।


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

नियम जो हमें इंजेक्शन से गारंटी देते हैं

1. हम केवल प्लेसहोल्डर्स के माध्यम से अनुरोध में डेटा स्थानापन्न करते हैं
2. हम अपने कोड में निर्धारित श्वेत सूची से केवल पहचानकर्ताओं और खोजशब्दों को प्रतिस्थापित करते हैं।

केवल दो अंक।
बेशक, इन नियमों के व्यावहारिक कार्यान्वयन को अधिक विस्तृत कवरेज की आवश्यकता है।
लेकिन इस सूची में एक महान गुण है - यह सटीक और व्यापक है। नियमों के विपरीत "mysql_real_escape_string के माध्यम से उपयोगकर्ता इनपुट चलाएं" या "हमेशा तैयार भाव का उपयोग करें" जन चेतना में निहित है, मेरे नियमों का सेट एक भयावह गिरावट (पहले की तरह) या अपूर्ण (दूसरे की तरह) नहीं है।

लेकिन आगे बढ़ो, पाठक - चलो एक विस्तृत विश्लेषण पर चलते हैं।

प्लेसहोल्डर - डेटा प्रतिस्थापन

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

SELECT * FROM table WHERE id > ? LIMIT ? 

और डेटा को जोड़ा और अलग से संसाधित किया जाता है।
लेकिन "साधारण भागने" से बेहतर क्या है? और सभी को:

• सबसे पहले, "भागने" का सुरक्षा से कोई लेना-देना नहीं है। कल्पना कीजिए!
• दूसरे, कोड छोटा हो जाता है। कोई mysql_real_escape_string (), और न ही intval () - सभी प्रसंस्करण अंदर छिपा हुआ है।
• तीसरा, कोड आसान हो रहा है । अनुरोध के विभिन्न भागों को प्रारूपित करने के लिए विभिन्न नियमों को याद रखने की आवश्यकता नहीं है
• चौथा, प्लेसहोल्डर्स का उपयोग (बशर्ते कि वे सही ढंग से संसाधित हैं) हमें डेटा के माध्यम से इंजेक्शन से गारंटी देता है। "यह स्पष्ट है!" - आप कहते हैं - "यह एक अलग बिंदु को बाड़ने के लिए इसके लायक था?" यह इसके लायक था। वही बचने की सुरक्षा की गारंटी नहीं है। इसके अलावा, स्वरूपण नियमों को एक तक कम करना - यहां कुछ भी भ्रमित करना मुश्किल होगा
• पांचवां - और सबसे महत्वपूर्ण बात - हम डेटा को ठीक उसी जगह संसाधित करते हैं जहां आपको इसकी आवश्यकता होती है ! यह एक बहुत ही महत्वपूर्ण बिंदु है जो बहुतों को समझ में नहीं आता है। क्लासिक "मज़ेदार" पाठ्यपुस्तकों में, SQL के लिए डेटा स्वरूपण पूरे कोड में बिखरा हुआ है। और PHP के पुराने संस्करणों में, यह कोड निष्पादन की शुरुआत से पहले ही शुरू हो गया था - जो पूरी तरह से किसी भी द्वार में नहीं जाता है! यह स्थिति इस तथ्य की ओर ले जाती है कि कुछ डेटा को दो बार स्वरूपित किया जाता है, अन्य - केवल आधा, और अभी भी अन्य - कभी-कभी या बिल्कुल भी नहीं, जैसा कि आवश्यक हो, मामूली लाभ के बिना । उसी समय, एसक्यूएल के लिए प्रारूपित डेटा अचानक HTML या कुकीज़ में दिखाई देता है, जो उपयोगकर्ताओं और डेवलपर्स के लिए खुशी नहीं जोड़ता है।

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

उपयोग के उदाहरण:

मैनुअल से:

 $stmt = $dbh->prepare("SELECT * FROM REGISTRY where name LIKE ?"); $stmt->execute(array("%$_GET[name]%")); $data = $stmt->fetchAll(); 

इसके लिए प्रयास करने का एक उदाहरण:

 $ban = $db->getRow("SELECT 1 FROM ban WHERE ip = inet_aton(s:)", $ip); 

जैसा कि आप देख सकते हैं, यह बिल्कुल भी मुश्किल नहीं है, और कुशल उपयोग के साथ यह आपके हाथों से अनुरोध करने की तुलना में बहुत कम है। क्या आप अभी भी पुराने ढंग से लिखना चाहते हैं?

महत्वपूर्ण नोट: निश्चित रूप से, प्लेसहोल्डर्स के माध्यम से डेटा प्रतिस्थापन हमेशा डेटा स्रोत या किसी अन्य शर्तों की परवाह किए बिना किया जाना चाहिए।

पहचानकर्ता और खोजशब्द - श्वेत सूची

इंजेक्शन पर लेख के विशाल बहुमत पूरी तरह से इस बिंदु को याद करते हैं। लेकिन वास्तविकता यह है कि इसमें हमें केवल डेटा ही नहीं, बल्कि अन्य तत्वों - पहचानकर्ताओं (क्षेत्रों और तालिकाओं के नाम) और यहां तक ​​कि वाक्यविन्यास तत्वों, कीवर्ड में स्थानापन्न करने की आवश्यकता का भी सामना करना पड़ता है। भले ही DESC या AND जैसा महत्वहीन हो, लेकिन ऐसे प्रतिस्थापन के लिए सुरक्षा आवश्यकताओं को अभी भी कम कठोर नहीं होना चाहिए!

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

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

आवेदन उदाहरण:

 $order = isset($_GET['order']) ? $_GET['order'] : ''; //     $sort = isset($_GET['sort']) ? $_GET['sort'] : ''; $allowed = array("name", "price", "qty"); //  $key = array_search($sort,$allowed); //      $orderby = $allowed[$key]; //  (,     - ) . $order = ($order == 'DESC') ? 'DESC' : 'ASC'; //    $query = "SELECT * FROM `table` ORDER BY $orderby $order"; // 100%  

मैं मानता था कि एक प्लेसहोल्डर पहचानकर्ताओं के लिए पर्याप्त है। लेकिन समय के साथ, इस पद्धति के नुकसान की समझ आ गई:

• सबसे पहले, एक अमान्य फ़ील्ड नाम के मामले में, अनुरोध एक त्रुटि का कारण होगा। और गलतियाँ हमेशा बुरी होती हैं
• दूसरी बात, और बहुत अधिक महत्वपूर्ण: यदि आप प्रारंभिक फ़िल्टरिंग के बिना फ़ील्ड नामों को स्वचालित रूप से प्रतिस्थापित करते हैं, तो केवल उनसे बचकर, आप एक अलग तरह का एक इंजेक्शन प्राप्त कर सकते हैं - आखिरकार, उपयोगकर्ता फिर उन फ़ील्ड नामों में प्रवेश कर सकता है जिन्हें वह बदलने वाला नहीं है! यदि हम $ _POST सरणी के आधार पर स्वचालित रूप से SQL क्वेरी उत्पन्न करते हैं (फ़ील्ड नामों को सही रूप में प्रारूपित करते समय!), तो हैकर, जब पंजीकरण करता है, तो व्यवस्थापक फ़ील्ड को "1" मान के साथ जोड़ता है और प्रपत्र बन जाता है।

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

 $query = "SELECT * FROM `table` ORDER BY n: $order"; 

मूल रूप से, यह जानकारी पूरी तरह से सुरक्षित प्रश्नों को लिखना शुरू करने के लिए पर्याप्त है। लेकिन, हमेशा की तरह, वास्तविक जीवन में अलग-अलग बारीकियां हैं, और मैं प्लेसहोल्डर्स के तंत्र को अधिक विस्तार से समझना चाहूंगा।

प्लेसहोल्डर्स के साथ काम करें

पहले आपको यह समझने की आवश्यकता है कि प्लेसहोल्डर्स को लागू करने के लिए दो विकल्प हैं - सर्वर और क्लाइंट:

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

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

 $dbh->setAttribute( PDO::ATTR_EMULATE_PREPARES, false ); 

लेकिन चूंकि इम्यूलेशन प्रोग्रामर की भागीदारी के बिना भी किया जाता है, इसलिए हम पीडीओ को सर्वर प्लेसहोल्डर्स के प्रतिनिधि के रूप में मानेंगे।

सर्वर प्लेसहोल्डर

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

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

सिद्धांत रूप में, यह बहुत लुभावना लगता है।
हालांकि, व्यवहार में, दुर्भाग्य से, पीएचपी में मैसकल के साथ काम करने के लिए मौजूदा पुस्तकालयों में, तैयार अभिव्यक्तियों के साथ काम करने का कार्यान्वयन अभी भी आदर्श से बहुत दूर है।
उदाहरण के लिए, निम्नलिखित तथ्यों का हवाला देना पर्याप्त है:

• तैयार अभिव्यक्तियों का उपयोग करके प्रश्नों के लिए एक सरणी (mysql_fetch_array () का एनालॉग) में परिणाम स्ट्रिंग प्राप्त करने के रूप में इस तरह के एक भोज सुविधा केवल संस्करण 5.3 (!) में mysqli में जोड़ा गया था। इस संस्करण से पहले, पुस्तकालय नारकीय विकृतियों के बिना व्यावहारिक रूप से अस्थिर था।
• पीडीओ में कनेक्शन के एन्कोडिंग को स्थापित करने के लिए भी यही लागू होता है - यह केवल उसी 5.3 में संभव हो गया। पिछले सभी संस्करणों में, पीडीओ में कनेक्शन के एन्कोडिंग को सेट करना असंभव था (जो - निष्पक्षता में, इसे पहचाना जाना चाहिए - संगतता मोड बंद होने पर, एक बड़ी समस्या नहीं है, लेकिन - छेद-एस!)।
• mysqli कुछ मामलों में जितना संभव हो उतना मेमोरी को आरक्षित करने की कोशिश करता है क्योंकि क्षेत्र डेटाबेस में जितना संभव हो उतना फिट हो सकता है - माध्यमटेक्स के साथ सावधान रहें!

ये तथ्य हमें बताते हैं कि दोनों पुस्तकालय अभी भी काफी कच्चे हैं, और हम उनसे अन्य आवश्यक कार्यक्षमता की अनुपस्थिति की अपेक्षा कर सकते हैं।

हम मौजूदा पुस्तकालयों के मुख्य नुकसानों को सूचीबद्ध करते हैं।

• wordiness
• कुछ उपयोगी प्लेसहोल्डर्स की कमी
• डिबगिंग उद्देश्यों के लिए क्लासिक SQL क्वेरी प्राप्त करने में असमर्थता
• संभावित प्रदर्शन समस्याएं * (इस मुद्दे पर नीचे चर्चा की जाएगी)

और उन्हें और अधिक विस्तार से विश्लेषण करें

शब्दाडंबर।

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

 $data = array(); $query = "SELECT Name, Population, Continent FROM Country WHERE Continent=? ORDER BY Name LIMIT 1"; $stmt->prepare($query); $stmt->bind_param("s", $continent); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_array(MYSQLI_NUM)) { $data[] = $row; } 

इसके अलावा, इस कोड के अधिकांश किसी भी शब्दार्थ भार को नहीं ले जाते हैं, सभी निष्पादित प्रश्नों के लिए बिल्कुल समान है, और सैकड़ों लिपियों में कई बार दोहराया जाता है।
इस तथ्य के बावजूद कि डेटा प्राप्त करने के लिए केवल दो लाइनें पर्याप्त हैं:

 $query = "SELECT Name, Population, Continent FROM Country WHERE Continent=? ORDER BY Name LIMIT 1"; $data = $db->getAll($query,$continent); 

पीडीओ के पास इसके साथ थोड़ा बेहतर है - उन्हें यह पता लगा कि अगर उन्होंने सरणी को निष्पादित करने के लिए पारित करने की अनुमति दी है () और एक fetchAll () विधि है। लेकिन फिर भी आपको सरलतम संचालन के लिए बहुत सारे अनावश्यक नीरस कोड लिखना होगा।
विशेष रूप से, हम अपने लेख के विषय पर लौटेंगे - बाध्यकारी। यहां मेरे पास चर $ _GET ['आईडी'] है; मैं इसे एक प्लेसहोल्डर से जोड़ना चाहता हूं। महान, मैं इसे सीधे निष्पादित () में कर सकता हूं ... लेकिन केवल इसे एक सरणी बनाकर। क्यों? क्या ड्राइवर खुद मेरे लिए ऐसा नहीं कर सकता?

क्रियात्मक कमी

एक अन्य समस्या जो हाल ही में एक लेख पर टिप्पणियों में पहले ही उठाई जा चुकी है वह है IN () ऑपरेटर। इसके लिए प्रतिस्थापन बनाना बहुत ही गैर-तुच्छ कार्य है। यद्यपि ऐसा लगता है कि यह ऐसे मामलों के लिए ठीक था जो प्लेसहोल्डर्स का आविष्कार किया गया था:

 $conts = array('Europe','Africa','Asia','North America'); $query = "SELECT * FROM Country WHERE Continent IN(?) ORDER BY Name LIMIT 1"; $data = $db->getAll($query,$conts); 

इसके बजाय दर्जनों लाइनों से वंचित कोड।
इससे हम क्या निष्कर्ष निकाल सकते हैं? इसे खत्म करना आवश्यक है।

SQL क्वेरी प्राप्त करने में असमर्थता

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

उत्पादकता

आमतौर पर, सर्वर-साइड तैयार अभिव्यक्तियों के लिए माफी माँगने वाले इस तथ्य पर जोर देते हैं कि अनुरोध केवल एक बार किया जाता है।
दुर्भाग्य से, वेब एप्लिकेशन के लिए यह काम नहीं करता है। स्क्रिप्ट की वह प्रति जिसने तैयारी को निष्पादित किया () निष्पादित करता है (इस अनुरोध के लिए निष्पादित) बिल्कुल 1 बार और सुरक्षित रूप से मर जाता है। एक नई प्रति फिर से तैयार होती है। नतीजतन, अधिक काम सामने आता है जहां वे बचाना चाहते थे।
हाल ही में एक लेख पर टिप्पणी में, मुझे एक और संभावित गति लाभ बताया गया था - एक क्वेरी योजना को कैशिंग। और वास्तव में, भले ही हम प्रत्येक क्वेरी के लिए तैयारी करते हों, डेटाबेस अलग-अलग डेटा के लिए एक ही क्वेरी को कैश कर सकता है। और पर्सिंग के बिना निष्पादन योजना प्राप्त करें, लेकिन सरल स्ट्रिंग तुलना द्वारा!
काश, मैं तंत्र की उपस्थिति और इसकी व्यावहारिक प्रभावशीलता दोनों की पुष्टि या खंडन करने के लिए MySQL की आंतरिक संरचना में इतना मजबूत नहीं हूं।
उसी समय, जहां तक ​​मुझे पता है, बड़े वास्तविक भार के तहत, सर्वर तैयार किए गए भाव मानक SQL प्रश्नों की गति में खो जाते हैं।
किसी भी मामले में, विषय खुला है और अभी भी अपने शोधकर्ता की प्रतीक्षा कर रहा है। अंत में, DBMS संस्करण बढ़ते हैं और परीक्षण के परिणाम पुराने हो जाते हैं।

सामान्य तौर पर, हमें पता चला कि DBMS और इसके साथ काम करने के लिए ड्राइवर जो उपकरण हमें प्रदान करते हैं, वे उतने अच्छे नहीं थे जितना कि वे विज्ञापन में दिखते थे। और सवाल उठता है - क्या हम अपने दम पर प्लेसहोल्डर्स के साथ काम को लागू कर सकते हैं? और जवाब उठता है - हम कर सकते हैं!

प्लेसहोल्डर्स का स्वतंत्र कार्यान्वयन

वास्तव में, वास्तव में, कोई भी हमें प्लेसहोल्डर्स के साथ परेशान किए बिना मौजूदा पुस्तकालयों की उपयोगिता में सुधार करने से नहीं रोक रहा है। बता दें, PDO पर एक रैपर लिखें जो लापता कार्यक्षमता को लागू करता है, अपने स्वयं के PDO प्लेसहोल्डर्स (या mysqli का उपयोग करके, जैसा कि यह एक वर्ष पहले Habré पर प्रकाशित पुस्तकालय में किया गया था)।

लेकिन हमारे पास घर-निर्मित प्लेसहोल्डर्स पर विचार करने के कई कारण हैं:
सबसे पहले, जैसा कि हमने पहले ही देखा है, मानक पुस्तकालयों में उपलब्ध प्लेसहोल्डर्स का सेट स्पष्ट रूप से पर्याप्त नहीं है।
दूसरे, किसी कारण से सर्वर प्लेसहोल्डर हमें सूट नहीं कर सकता है।
तीसरे, प्लेसहोल्डर्स के स्वतंत्र प्रसंस्करण के उदाहरण पर, हम एसक्यूएल प्रश्नों को सही ढंग से प्रारूपित करने की बारीकियों पर विचार करेंगे।

SQL क्वेरी के विभिन्न तत्वों को प्रारूपित करने के सिद्धांत

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

पहले, आइए तय करें कि क्वेरी में कौन से तत्व शामिल हो सकते हैं?
उदाहरण के लिए, ऐसे SQL को लें:

 INSERT INTO `db`.`table` as `t1` VALUES('string',1,1.5,NOW()); 

तत्वों के तीन मुख्य समूहों को इसमें प्रतिष्ठित किया जा सकता है:

• एसक्यूएल भाषा तत्व स्वयं - ऑपरेटरों, अंतर्निहित कार्यों, चर, आदि।
• पहचानकर्ता (डेटाबेस, तालिकाओं और क्षेत्रों के नाम)
• शाब्दिक (डेटा क्वेरी में सीधे प्रतिस्थापित) कई अलग-अलग प्रकार के।

हमें अंतिम दो बिंदुओं में दिलचस्पी होगी, क्योंकि केवल उन्हें विशेष प्रारूपण की आवश्यकता होती है।

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

सामान्य तौर पर, एक अलग समाधान की आवश्यकता होती है। और यह है! लेकिन हम इसके बारे में नीचे बात करेंगे, लेकिन अब हम नियमों को प्रारूपित करने पर विचार करेंगे।

स्वरूपण पहचानकर्ता

सामान्य तौर पर, पहचानकर्ताओं के नामकरण के नियम काफी व्यापक हैं । लेकिन यह देखते हुए कि सुरक्षा के लिए हम श्वेतसूची का उपयोग करते हैं, और केवल स्वरूपण के लिए एक प्लेसहोल्डर है, तो ये दोनों पर्याप्त होंगे:

• पहचानकर्ता को वापस एकल उद्धरण (बैकटिक्स) में संलग्न किया जाना चाहिए
• यदि नाम में ऐसा कोई उद्धरण होता है, तो उसे दोगुना होने से बच जाना चाहिए।

 function escapeIdent($value) { return "`".str_replace("`","``",$value)."`"; } 

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

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

स्ट्रिंग शाब्दिक स्वरूप

सबसे काट दिया, यह प्रतीत होता है, विषय।लेकिन, जैसा कि हाल के लेखों की चर्चा से पता चला है, कई अभी भी भ्रमित हैं, अगर समझ में नहीं आता है, तो कम से कम शब्दों में। तो, चलिए SQL में स्ट्रिंग्स को फॉर्मेट करने के लिए नियम बनाते हैं।

• स्ट्रिंग को उद्धरण चिह्नों (एकल या दोहरे में संलग्न किया जाना चाहिए, लेकिन चूंकि डुप्लिकेट का उपयोग पहचानकर्ताओं के लिए किया जा सकता है, यह हमेशा एकल के लिए बेहतर होता है)
• लाइन में सूची में विशेष वर्ण से बच जाना चाहिए। इसके लिए, एपीआई एक विशेष फ़ंक्शन प्रदान करता है। इस फ़ंक्शन को सही ढंग से काम करने के लिए, कनेक्शन एन्कोडिंग को सही ढंग से सेट किया जाना चाहिए।

जब

• इन नियमों को हमेशा एक साथ लागू किया जाना चाहिए, और केवल एक ही नहीं
• उनमें से कोई भी पंक्तियों के अलावा किसी भी डेटा पर लागू नहीं होना चाहिए

यह सरल नियम लगता है? लेकिन यह केवल आश्चर्यजनक है कि उन्हें कितने लोगों को नहीं करना चाहिए।
और यहां तक ​​कि PHP प्रलेखन में, mysql_real_escape_string () के बारे में लेख में, खेल कहता है: "यदि आप इस फ़ंक्शन का उपयोग नहीं करते हैं, तो क्वेरी SQL इंजेक्शन के साथ हैकिंग की चपेट में आ जाती है। "- मानो संख्याओं या पहचानकर्ताओं के लिए इसका उपयोग करने से कम से कम कुछ मदद मिलेगी!

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

  function escapeString($value) { return "'".mysqli_real_escape_string($this->connect,$value)."'"; } 

यह केवल यह जोड़ने के लिए बना हुआ है कि "एन्कोडिंग सही ढंग से सेट है" केवल फ़ंक्शन mysqli_set_charset / mysql_set_charset , और PDO में - DSN में हो सकता है।

संख्या स्वरूपण

सैद्धांतिक रूप से, ज्यादातर मामलों में, संख्याओं को स्ट्रिंग्स के रूप में स्वरूपित किया जा सकता है, और फिर कार्य पिछले एक तक कम हो जाएगा। लेकिन तीन समस्याएं हैं

• Mysql में STRICT मोड मोड, जो सक्षम होने पर, कुछ मामलों में एक संख्या के रूप में एक स्ट्रिंग पास करने की कोशिश करते समय त्रुटियों को फेंक देगा।
• लिमिट ऑपरेटर, जिसमें लाइनों का उपयोग बिल्कुल भी प्रदान नहीं किया जाता है
• mysql विशेषज्ञों द्वारा टिप्पणी कि एक शाब्दिक का प्रकार बहुत महत्वपूर्ण है और एक क्वेरी की योजना बनाने और निष्पादित करने में एक भूमिका निभाता है। मैं खुद इस पर मजबूत नहीं हूं, और मुझे एक विस्तृत टिप्पणी करने में खुशी होगी।

सामान्य तौर पर, हम संख्याओं को भी प्रारूपित करेंगे। इसके अलावा, प्लेसहोल्डर्स की मदद से यह कोई समस्या नहीं है।
एक अन्य समस्या पीएचपी में अंतर्निहित प्रकार के रूपांतरण तंत्र की अपर्याप्त बिट गहराई से दर्शाती है। इसलिए, यदि आपको PHP_INT_MAX से बड़े पूर्णांक मानों के साथ काम करने की आवश्यकता है, तो सत्यापन के लिए नियमित उपयोग करें। खैर, सामान्य स्थिति में, आप इंटवल () का उपयोग कर सकते हैं।

केवल नियमित अंतराल द्वारा दशमलव बिंदु के साथ संख्याओं की जांच करना उचित है, क्योंकि PHP में MySQL में सुपर-उपयोगी DECIMAL प्रकार के समान कोई डेटा प्रकार नहीं है।

आलसी प्लेसहोल्डर

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

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

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

 function query(){ $query = array_shift($args); $query = str_replace("%s","'%s'",$query); foreach ($args as $key => $val) { $args[$key] = mysql_real_escape_string($val); } $query = vsprintf($query, $args); if (!$query) return FALSE; $res = mysql_query($query) or trigger_error("db: ".mysql_error()." in ".$query); return $res; } 

जो अनुरोध में डेटा को प्रतिस्थापित करने के अपने कर्तव्यों के साथ अच्छी तरह से मुकाबला करता है।
इसके अलावा, मूर्खता के साथ: यदि हम प्लेसहोल्डर को भ्रमित करते हैं और उदाहरण के लिए,% s को लीमिट ऑपरेटर में% d के बजाय, हम विकास के चरण में एक अनुरोध त्रुटि प्राप्त करेंगे, लेकिन इंजेक्शन नहीं (जैसा कि भागने की स्थिति में होगा)।

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

उपयोग के उदाहरण:

 $name = dbget(1,"SELECT name FROM users WHERE id=%d",$_GET['id']); //      $user = dbget(2,"SELECT * FROM users WHERE id=%d",$_GET['id']); //     $sql = "SELECT * FROM news WHERE title LIKE %s LIMIT %d,%d"; $news = dbget(3,$sql,"%$_GET[search]%",$start,$per_page); //   

कुछ भद्दापन के बावजूद, इस समारोह, मेरे दिल को प्रिय है, क्योंकि यह अच्छी तरह से ज्ञात सिद्धांतों का कड़ाई से पालन में लिखा है: KISS और यह तिरस्कार में रखा जा सकता है, यह का उपयोग बहुत, बहुत शुष्क कोड बनाता है।

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

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

दूसरे, हमारी कक्षा के लिए हम टाइप किए गए प्लेसहोल्डर्स के वास्तव में शानदार विचार का उपयोग करते हैं। और उसी समय, हम पीडीओ नाम के प्लेसहोल्डर्स से लाभान्वित होंगे।
हमारे प्लेसहोल्डर के पास फॉर्म है

 [az]:[az]* 

उदाहरण के लिए

 i: 

या

 s:name 

पहले मामले में, यह एक अनाम प्लेसहोल्डर होगा, और दूसरे में - नाम दिया गया है।
पहला अक्षर प्रकार सेट करता है, बृहदान्त्र लाइन के अन्य तत्वों से प्लेसहोल्डर को अलग करता है, और नाम वैकल्पिक है।

तीसरा, IN () ऑपरेटर के लिए लंबे समय से प्रतीक्षित प्लेसहोल्डर (तार के लिए)

 function createIN($data) { if (!is_array($data)) { throw new E_DB_MySQL_parser("Value for a: type placeholder should be array."); } if (!$data) { throw new E_DB_MySQL_parser("Empty array for a: type placeholder."); } $query = $comma = ''; foreach ($data as $key => $value) { $query .= $comma.$this->escapeString($value); $comma = ","; } return $query; } 

और इस पर टिप्पणियों के एक जोड़े।
जैसा कि आप देख सकते हैं, पार्सर एक खाली सरणी पर एक अपवाद फेंकता है। क्यों?
mysql IN(), .
- implode , : — , .

DmitryKoterov dbSimple — IN , , , . , , , .

अपडेट:
, zerkms david_mz , , !

 IN(NULL) 

एक त्रुटि नहीं फेंकता है और हमेशा FALSE लौटाता है - एक खाली सरणी के लिए आदर्श प्रतिनिधित्व।
यही है, आपको बस इसके लिए NULL स्थानापन्न करने की आवश्यकता है:

 function createIN($data) { if (!is_array($data)) { throw new E_DB_MySQL_parser("Value for a: type placeholder should be array."); } if (!$data) { return 'NULL'; } $query = $comma = ''; foreach ($data as $key => $value) { $query .= $comma.$this->escapeString($value); $comma = ","; } return $query; } 

मैंने पहले अपवाद को छोड़ने का फैसला किया, इस तरह के विचारों से आगे बढ़ना:
सैद्धांतिक रूप से, हम एक स्केलर को एक सरणी में बदल सकते हैं और इसे सामान्य तरीके से आगे की प्रक्रिया कर सकते हैं। लेकिन इस तरह के छिपे हुए प्रकार के रूपांतरण, हालांकि भाषा से परिचित हैं, तार्किक त्रुटियों से भरा है।
नतीजतन, अगर हमारे कोड के अंदर एक सरणी बनती है, तो यह चेक हमें विकास के स्तर पर गठन की सभी त्रुटियों को पकड़ने में मदद करेगा। ठीक है, अगर सरणी बाहर से आती है, तो सभी को आपको अपवाद फेंकने की आवश्यकता है।
</ अद्यतन>

मैं ख़ुद सरणी के प्रारंभिक सत्यापन के साथ एक संस्करण पर बस गया। एक अन्य वर्ग विधि मुझे इसमें मदद करती है - पार्स (), जो स्ट्रिंग को प्लेसहोल्डर्स के साथ पार्स करता है, पास किए गए मापदंडों को प्रतिस्थापित करता है और एक तैयार-निर्मित SQL क्वेरी का उत्पादन करता है ... या सर्वर-साइड प्लेसहोल्डर्स के मामले के विपरीत, हम आसानी से अनुरोध के एक मनमाने टुकड़े को पार्स कर सकते हैं! )। और अगर पहला डिबगिंग के लिए हमारे लिए उपयोगी है, तो दूसरा हमारे जैसे मामलों के लिए है:

 if (is_array($array) and $array) { $sql .= $db->parse(" AND type IN(a:)",$array); } 

इसके अलावा, इस पद्धति का उपयोग बहु-मंजिला सशर्त WHERE की रचना के लिए किया जा सकता है:

 $w = array(); $where = ''; if (!empty($_GET['type'])) $w[] = $db->parse("type = s:", $_GET['type']); if (!empty($_GET['rooms'])) $w[] = $db->parse("rooms IN (a:)",$_GET['rooms']); if (!empty($_GET['max_price'])) $w[] = $db->parse("price <= i:", $_GET['max_price']); if (count($w)) $where = "WHERE ".implode(' AND ',$w); $data = $db->getArr("SELECT * FROM table $where LIMIT i:,i:",$start,$per_page); 

उपरोक्त DbSimple पुस्तकालय , वैसे, एक अलग पैराग्राफ के रूप में उल्लेख के लायक है, यहाँ प्रस्तुत अधिकांश विचारों के तैयार कार्यान्वयन के उदाहरण के रूप में (विशेष रूप से, स्व-लिखित प्लेसहोल्डर्स का मूल में अनुवाद, 100,500 प्रकारों के लिए टाइपहोल्डहोल्डर और बहुत कुछ), अलग से इस तथ्य को ध्यान में रखते हुए कि यह थोड़ा लिखा गया था। शायद 10 साल पहले, लेकिन किसी कारण से व्यापक वितरण नहीं हुआ।

अंधविश्वास एक्सपोजर सत्र

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

लंबे समय से PHP में मायक्क्ल_ * फ़ंक्शंस को हटा दिया गया है

उदास विषय।
कैसे आलस्य और अज्ञानता की कहानी एक सुंदर पुस्तकालय को दफन कर देती है।

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

लेकिन इस वाक्यांश में एक और अति सूक्ष्मता है, जो बहुत महत्वपूर्ण है। कई शुरुआती डेवलपर्स समझ में नहीं आता है कि चीजों की श्रेणी से।
यदि हम "mysql_ * फ़ंक्शन" के बारे में विशेष रूप से बात करते हैं, तो आवेदन कोड में उन्हें वास्तव में नहीं होना चाहिए! साथ ही mysqli_ *, pdo_ * फ़ंक्शन या किसी भी अन्य कॉल को नंगे एपीआई के लिए। कृपया ध्यान दें कि हम एप्लिकेशन कोड के बारे में बात कर रहे हैं, कोड के बारे में बिल्कुल नहीं: बस एपीआई कार्यों के लिए सभी कॉल पुस्तकालयों में पैक की जानी चाहिए, और एप्लिकेशन कोड में आपको लाइब्रेरी फ़ंक्शन तक पहुंचने की आवश्यकता है। और इन सभी mysql (i) _query (), और mysql (i) _fetch_array () का उपयोग विशिष्ट प्रश्नों को निष्पादित करने के लिए कहता है, अफसोस, अव्यवसायिकता।
इसका कारण अनिवार्य रूप से बहुत सरल है: एपीआई फ़ंक्शन बहुत अधिक बेमानी हैं। डेटाबेस से डेटा की एक पंक्ति प्राप्त करने के लिए, आपको एक दर्जन पंक्तियों को लिखना होगा। और यह इस तरह की आवश्यक चीजों को ध्यान में नहीं ले रहा है जैसे कि त्रुटि से निपटने, लॉगिंग और अनुरोधों की रूपरेखा और बहुत कुछ। नतीजतन, अगर हम कोड में सीधे एपीआई फ़ंक्शन का उपयोग करते हैं, तो यह एक तरफ, बहुत अनावश्यक रूप से, और दूसरे पर निकलता है ... पर्याप्त कार्यात्मक नहीं है!
पीडीओ लेखकों ने अपनी लाइब्रेरी को अधिक उपयोगी बनाने की कोशिश की है, लेकिन, मेरी राय में, पर्याप्त नहीं है। और पीडीओ को कॉल को आपकी अपनी कक्षा के तरीकों में उसी तरह से समझाया जाना चाहिए।
एक और तर्क - अब आपको mysql_ * को कुछ और में बदलना होगा। एक एकल लाइब्रेरी फ़ाइल में, दर्जनों परियोजनाओं की तुलना में यह करना बहुत आसान है।

कोई चांदी की गोली नहीं है

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

Eskeyping

अंधविश्वास का एक पूरा गुच्छा है। मुझे उम्मीद है कि उपरोक्त स्पष्टीकरण के बाद कोई सवाल नहीं बचा है, लेकिन सिर्फ मामले में:

• "Mysql_real_escape_string फ़ंक्शन के साथ समस्या यह है कि इसका उपयोग किया जाता है" - यह बकवास है। Mysql_real_escape_string () फ़ंक्शन के साथ एकमात्र समस्या यह है कि इतने सारे लोग यह नहीं समझते हैं कि यह क्या है।
• आने वाले डेटा के लिए "पलायन की आवश्यकता है" - बेशक, ऐसा नहीं है। तार के लिए भागने की जरूरत है
• « „“ „“» — . «» . , , , , —
• « - » — , ? . , .
• « » — , , . , — . — , SQL . PDO, — , , . PDO . , , «» . PDO «», .

«»

जैसे "UNION", एक एकल उद्धरण इत्यादि। सुरक्षा का एक बहुत ही मजेदार तरीका। जब मैं किसी लेखक की साइट पर गंभीरता से इसके दूसरे संस्करण की पेशकश करता हूं, तो मैं हमेशा उससे पूछना चाहता हूं कि अगर साइट को ही सुरक्षा प्रदान की जाती है तो क्या होगा? हमारे जासूसी आविष्कारक बस अपने पोस्ट को उन "खतरनाक" "शब्दों को रोक" के रूप में प्रकाशित नहीं कर सकते थे।

यूनिवर्सल डेटा सुरक्षा फ़ंक्शन

नौसिखिया phpshniks के बीच एक बहुत ही आम गलत धारणा। "हम इनपुट पर एक सार्वभौमिक कार्य करते हैं जो आने वाले डेटा में सभी" हानिकारक पात्रों "को मार देगा और इस तरह किसी भी इंजेक्शन से खुद को बचाएगा!" वे सोचते हैं।
लेकिन जैसा कि हम पहले ही पता लगा चुके हैं, "हानिकारक" वर्ण मौजूद नहीं हैं। केवल सेवा वर्ण हैं जिनका एक निश्चित अर्थ केवल एक निश्चित संदर्भ में है। और अन्य सभी मामलों में पूरी तरह से सुरक्षित है।
हमें यह भी पता चला कि सबसे पहले हमें सुरक्षा की नहीं, बल्कि डेटा की सही स्वरूपण की आवश्यकता है। और यह केवल तभी किया जा सकता है जब हम पहले से जानते हैं कि उनका उपयोग किस संदर्भ में किया जाएगा। काश, हम अभी भी स्क्रिप्ट इनपुट पर यह नहीं जानते। इस दृष्टिकोण का एक ज्वलंत उदाहरण कुख्यात मैजिक_क्वोट्स निर्देश है, जो सौभाग्य से, अब भाषा से हटा दिया गया है। डेटा को संसाधित करना जो बिल्कुल भी आवश्यक नहीं था, उसने सुरक्षा का भ्रम पैदा किया, केवल लाइनों की रक्षा की (और केवल बाहर से स्क्रिप्ट में गिर रही है)।
इसलिए, कृपया इन त्रुटियों को न दोहराएं - स्क्रिप्ट में आने पर तुरंत SQL के लिए डेटा को प्रारूपित न करें।

एन्कोडिंग

एन्कोडिंग का विषय केवल स्ट्रिंग्स के मैनुअल फॉर्मेटिंग पर लागू होता है। प्लेसहोल्डर्स को सर्वर पर संसाधित करते समय, कोई समस्या नहीं है।
यहां विषय पुराना है, " शिफ्टलेट ने अठारहवें वर्ष में यह सब आविष्कार किया" और फिर अल्शनत्स्की ने दिखाया कि mysql_real_escape_string () भी मदद नहीं करता है (!)
पूरी चाल है, जो दस्तावेज में कहा गया है , इसके विपरीत , mysql_real_escape_string () "खाता" नहीं लेता है। ", जब तक आप विशेष रूप से उसे लात नहीं मारते। डिफ़ॉल्ट रूप से, वर्तमान एन्कोडिंग लैटिन 1 है, जिसके लिए किसी भी मुश्किल सेटिंग्स की आवश्यकता नहीं है, और mysql_real_escape_string () अपने गूंगे रिश्तेदार mysql_escape_string () की तुलना में कोई होशियार कार्य नहीं करता है।
उसी समय, 2006 में, mysql_real_escape_string () mysql एक्सटेंशन में वर्तमान एन्कोडिंग कार्य करने का कोई तरीका नहीं था। तब से, हालांकि, प्रगति बहुत दूर चली गई है और उपकरण दिखाई दिया है - mysql_set_charset () फ़ंक्शन । जिसे SET NAMES अनुरोध के बजाय क्लाइंट एन्कोडिंग सेट करने के लिए उपयोग किया जाना चाहिए।

किसी भी मामले में, इंजेक्शन केवल कुछ विदेशी एनकोडिंग के लिए संभव है। सभी एकल-बाइट एन्कोडिंग और UTF-8 सुरक्षित हैं और इसलिए (जिसके परिणामस्वरूप तथ्य यह है कि कुख्यात Addlashes () भी उनके लिए उपयुक्त हैं)।

यह जाँचने के लिए मैं उस समय बहुत आलसी नहीं था कि यह कैसे काम करता है। मैं आश्वस्त था - यह भविष्यवाणी की तरह ही काम करता है।

एक विशिष्ट विवरण, जिसका मैंने पहले उल्लेख किया था:
हाल ही में, पीडीओ में, आप कनेक्शन के एन्कोडिंग को बिल्कुल भी सेट नहीं कर सकते थे। PDO में mysql_set_charset () के समान कोई फ़ंक्शन नहीं है, और संस्करण 5.3 से पहले DSN में चारसेट पैरामीटर के लिए केवल एक डमी था, जो त्रुटियों का उत्पादन नहीं करता था, लेकिन किसी भी एन्कोडिंग को उजागर नहीं करता था।
कुछ भी नहीं, विशेष रूप से, पात्रों को ट्रोल करने की क्षमता के अलावा, जो बात करते हैं कि पीडीओ हर चीज के खिलाफ कैसे सुरक्षा करता है।

"LIKE में भेद्यता"

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

निष्कर्ष

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

अद्यतन: mysql के साथ सुविधाजनक काम के लिए एक वर्ग और SQL इंजेक्शन के खिलाफ सुरक्षा , जो लेख में उल्लिखित सिद्धांतों को लागू करता है।