एसक्यूएल इंजेक्शन का सारांश

मुझे पता है कि एसक्यूएल इंजेक्शन का विषय पहले ही सभी को तड़क-भड़क में ले चुका है।

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

इंजेक्शन को रोकने के तरीके पर पहले से ही बहुत सारे लेख थे - मैं इसे नहीं दोहराऊंगा - यह सब कुछ अभ्यास के कुछ सामान्य से नीचे आता है:

1. किसी भी बाहरी स्रोतों से सभी डेटा (भले ही यह डेटा एक सुपर सीक्रेट और सुरक्षित साइट से लिया गया XML से लिया गया हो) की जाँच की जानी चाहिए।
   
   प्रकार की जांच करना सुनिश्चित करें और जो आप उम्मीद करते हैं उसे लाएं।
   यदि आप किसी पूर्णांक की प्रतीक्षा कर रहे थे, लेकिन अक्षर और (या) एक बिंदु आ गए हैं, तो हम कहीं न कहीं एक त्रुटि की सूचना देते हैं, और हम ग्राहक को 500/404 / या कोड देते हैं, जिसकी आपको आवश्यकता होती है।
   
   अहस्ताक्षरित पूर्णांक के लिए मेरा उदाहरण f-s:
   
   

   function getAsUint( &$var ) { return ( preg_match( "~^\\s*(\\d+)\\s*$~i", $val, $t ) ) ? $t[1] : null; } 

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

    "select * from `table` where `id`={$id}" 

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

    function prepareStr( $str ) { return "'". str_replace( array( '\\', "\0", "\n", "\r", "'", '"', "\x1a" ), array( '\\\\', '\\0', '\\n', '\\r', "\\'", '\\"', '\\Z' ), $str ) . "'"; } 

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

    "select * from `table` where `id`=" . prepareStr( $tag ) 

   
   मापदंडों के अंदर के उद्धरण उसके लिए आवश्यक नहीं हैं - वह उन्हें खुद प्रतिस्थापित करता है - यह इस तथ्य से रक्षा करेगा कि आप गलती से 5 मिनट के लिए भूल सकते हैं :)
   
   यहाँ से mysql मैन्युअल से लिया गया रिप्लेसमेंट डेटा
   
   अब, mysql_real_escape_string के बारे में थोड़ा, जो पहले से ही एक गले में बढ़त प्राप्त कर चुका है, जिनमें से एक पैरामीटर कनेक्शन आईडी है।
   उदाहरण के लिए, यह मेरे लिए बहुत सुविधाजनक नहीं है, क्योंकि सभी उपयोगों के लिए यह मेरे पास नहीं है
   लेकिन किसी कारण से उसे इस फ़ंक्शन की आवश्यकता है? उन्होंने लिखा कि इसके बिना यह ठीक से काम नहीं करता है :)
   यदि आप mysql स्रोत को देखते हैं, तो यह फ़ाइल mysys / charset.c में निहित है और इसमें से CHARSET_INFO प्राप्त करने के लिए पहचानकर्ता का उपयोग करता है, और यह केवल मल्टीबाइट एन्कोडिंग निर्धारित करने के लिए या नहीं।
   और एक वर्ण कितना लंबा है। किसी भी मामले में, जैसा कि मैंने इसे लिस्टिंग से समझा। शायद कोई गुरु C है? अगर मैं गलत हूं तो मुझे सुधारो।
   
   चूंकि मैं डेटाबेस से कनेक्ट करते समय UTF के साथ काम करता हूं, या WIN1251 के साथ सबसे खराब स्थिति में, आप एन्कोडिंग से परेशान हुए बिना पूरी तरह से लगभग तैयार हो सकते हैं, लेकिन अगर यह वास्तव में आपके लिए विदेशी है, तो mysql -real_escape_string का उपयोग करना बेहतर है।
   
   Mysql_real_escape_string की तरह तैयार करने वाले फ़ंक्शन में एक भेद्यता है - तथ्य यह है कि वे दोनों "%" और "_" से बचते नहीं हैं जो कि LIKE प्रकार के निर्माण में उपयोग किए जाते हैं।
   फ़ॉर्म का परिरक्षण "\" और "\ _" LIKE के अंदर काम करता है, लेकिन बाहर - नहीं - यह दो वर्णों को लौटाएगा। क्यों? - अज्ञात, लेकिन सच है।
   इसलिए, यदि आप इस अस्पष्टता से छुटकारा पाना चाहते हैं, तो मुझे दो तरीके दिखाई देते हैं - या तो LIKE प्रतिस्थापन में फ़ंक्शन के किसी भिन्न संस्करण का उपयोग करें, या एक फ़ंक्शन का उपयोग करें, लेकिन सार्वभौमिकता के लिए आपको सभी वर्णों "%" और "_" को कुछ इस तरह से बदलना होगा
   
   

    "CONCAT( '%_', '\%\_', '%_ ')" 

   
   शायद एक बेहतर समाधान है, लेकिन मुझे इसके बारे में पता नहीं है।
   
   
4. प्लेसहोल्डर्स / तैयार स्टेटमेंट का उपयोग करें (या उन्हें PDO / ActiveRecord / ORM, आदि को एकीकृत करें)
   
   ये, वैसे, पूरी तरह से अलग चीजें हैं।
   संक्षेप में - प्लेसहोल्डर एक सहायक है जो डेटाबेस में एक नियमित पाठ क्वेरी उत्पन्न करता है, लेकिन सभी मापदंडों से खुद को बचता है, अर्थात्। वह "..." की आवश्यकता को समाप्त करता है। mysql_real_escape_string ($ परम)। "..."।
   और तैयार किए गए बयान एक डेटाबेस को अनुरोध करने के लिए पूछने का एक तरीका है, उदाहरण के लिए कई कॉल।
   
   मेरे दृष्टिकोण से, एक नियमित साइट और एक नियमित सीआरयूडी के लिए तैयार बयान का उपयोग करना एक बाज़ू से गौरैया को गोली मारने जैसा है। कैशिंग आदि के साथ उनके कई नुकसान हैं।
   यदि आप उन्हें जानते हैं या जानते हैं कि आपको इसकी आवश्यकता है - तो ठीक है फिर मामला पहले से अलग है।
   
   
5. अच्छी तरह से और सबसे महत्वपूर्ण बात, आपको SQL इंजेक्शन के बारे में जानने की आवश्यकता है - कोई चांदी की गोली नहीं है।
   
   प्रश्न लिखते समय, आपको मस्तिष्क और गधे का उपयोग करने की आवश्यकता होती है। ब्राइन - क्योंकि उसे समझना चाहिए कि वह क्या लिखता है, और गधे - क्योंकि उसे होश है कि कुछ गलत है;)
   
   और अगर हास्य के बिना - यह मेरे लिए मज़ेदार है जब पीडीओ या तैयार स्टेटमेंट का उपयोग करने वाले लोग मानते हैं कि उनकी परियोजनाओं में SQL इंजेक्शन सब कुछ असंभव है - ऐसा नहीं है, क्योंकि ये सभी सिर्फ उपकरण हैं जो उन जगहों की संख्या को कम करते हैं जहां आपको सोचने की ज़रूरत है, लेकिन हटा नहीं है उन्हें।
   और अगर किसी व्यक्ति ने एक असुरक्षित अनुरोध किया है, तो वैसे भी, जिसके माध्यम से वह उसे डेटाबेस में फेंकता है, वह कमजोर होगा।
   
   

एक उदाहरण उन परियोजनाओं में से एक है, जिसका मैंने विश्लेषण किया (जैसे कि यह):

 "select * from `{$table}` where `col` LIKE ?" 

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

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

PS त्रुटियों के बारे में, यदि आप पाते हैं - कृपया पीएम में।

टिप्पणियों से दिलचस्प है

• जैसा कि zapimir ने ठीक से mysql_real_escape_string का उपयोग करने के लिए कहा है , mysql_set_charset के माध्यम से लोकेल सेट करना आवश्यक है। सेट NAMES इसे प्रभावित नहीं करता है (डिफ़ॉल्ट रूप से लिया जाएगा)