प्रश्न में आपने जो प्रश्न दिखाया है वह उपयोगकर्ता द्वारा प्रदत्त मूल्यों का उपयोग नहीं करता है, इसलिए SQL इंजेक्शन का कोई मामला नहीं है, लेकिन सामान्य स्थिति में:-
सबसे पहले, आपको सभी . को सत्यापित करना होगा किसी क्वेरी में उपयोग करने से पहले उपयोगकर्ता इनपुट (उपयोगकर्ता नाम, ईमेल आदि)। उदाहरण के लिए:- यदि आपने किसी उपयोगकर्ता नाम में केवल अक्षरांकीय वर्णों की अनुमति दी है, तो डेटाबेस क्वेरी बनाने के लिए आगे बढ़ने से पहले आपको यह जांचना होगा कि इनपुट वास्तव में अल्फ़ान्यूमेरिक है या नहीं और आपको सभी इनपुट के आकार की भी जांच करनी चाहिए।
उसके बाद, मेरी राय में SQL इंजेक्शन को रोकने के लिए तैयार विवरण सबसे अच्छा विकल्प है।
mysql_real_escape_string के साथ समस्या ():-
चूंकि mysql_real_escape_string() डिफ़ॉल्ट वर्णसेट के अनुसार वर्णों से बच निकलता है, इसलिए यह addlashes() फ़ंक्शन से बेहतर है और यह मल्टीबाइट कैरेक्टर सेट के दुरुपयोग से उत्पन्न होने वाले SQL इंजेक्शन , लेकिन एक अन्य लेख में यहां , एक समाधान-परिदृश्य दिखाया गया है जो बताता है कि इंजेक्शन अभी भी किया जा सकता है।
समाधान:-
तो एसक्यूएल इंजेक्शन को रोकने का उचित और बेहतर तरीका तैयार बयानों का उपयोग करना है। यह एक ऐसी तकनीक है जिसमें SQL कथन उपयोगकर्ता-इनपुट (पैरामीटर) को सम्मिलित करने से पहले पूर्व-संकलित होते हैं और पुन:प्रयोज्य SQL टेम्पलेट के रूप में माने जाते हैं। तो, यह उपयोगकर्ता इनपुट को वास्तविक SQL-Code से अलग करता है और SQL-parser कभी भी उपयोगकर्ता इनपुट को पार्स नहीं करता है।
सुरक्षा के अलावा, यह गति के लिए SQL क्वेरी को भी अनुकूलित करता है। यह उन मामलों में मदद करता है जहां आपको अलग-अलग उपयोगकर्ता इनपुट के साथ एक ही क्वेरी को कई बार चलाने की आवश्यकता होती है।
कार्यान्वयन विवरण के लिए आप PHP मैनुअल का संदर्भ ले सकते हैं।
