mysql_real_escape_string() को बायपास करने वाला SQL इंजेक्शन: कमजोरियों का विश्लेषण

«बचाओ! मेरी mysql_real_escape_string() काम नहीं कर रही!»

यदि आपने कभी «SQL injection that gets around mysql_real_escape_string()» गूगल किया है, तो आप अकेले नहीं हैं। Stack Overflow पर इस प्रश्न को दसियों हज़ार बार देखा गया है और यह वेब सुरक्षा का एक क्लासिक बन गया है। ऐसा लगता है, आप mysql_real_escape_string() लेते हैं — और आप सुरक्षित हैं। लेकिन नहीं। हैकर्स खामियाँ ढूंढ लेते हैं, और डेवलपर्स को सफेद बाल मिल जाते हैं।

इस लेख में, हम विश्लेषण करेंगे कि कैसे SQL-इंजेक्शन PHP में mysql_real_escape_string() के एस्केपिंग को बायपास कर सकते हैं। आप कोड के वास्तविक उदाहरण देखेंगे, समझेंगे कि «पुराना अच्छा» तरीका अब क्यों काम नहीं करता, और जानेंगे कि वास्तव में कैसे सुरक्षित रहें। चलिए शुरू करते हैं!

mysql_real_escape_string() रामबाण क्यों नहीं है?

शुरुआत करने के लिए — थोड़ा इतिहास। mysql_real_escape_string() फ़ंक्शन PHP 4 और 5 के युग में आया था, जब सभी mysql_* एक्सटेंशन पर निर्भर थे। यह उद्धरण, बैकस्लैश और नियंत्रण वर्णों जैसे विशेष वर्णों को एस्केप करता है। लेकिन समस्या यह है कि यह केवल एक एन्कोडिंग के संदर्भ में काम करता है।

यदि क्लाइंट और सर्वर की एन्कोडिंग मेल नहीं खाती — तो मुसीबत शुरू हो जाती है। और यदि आप मल्टीबाइट एन्कोडिंग (जैसे GBK या SJIS) का उपयोग करते हैं — तो फ़ंक्शन आपका सबसे बड़ा दुश्मन बन सकता है।

क्लासिक उदाहरण: मल्टीबाइट अटैक

कल्पना करें कि आपकी साइट GBK (चीनी) एन्कोडिंग का उपयोग करती है, और आप यह स्ट्रिंग भेजते हैं:

$_POST['name'] = "0xbf27"; // एस्केप किया गया ' या बस '?\n

GBK में, वर्ण 0xbf27 एक मान्य चीनी अक्षर है। लेकिन यदि mysql_real_escape_string() 0x27 (एपॉस्ट्रॉफी) को «देखता» है, तो यह इसे बैकस्लैश से एस्केप कर देगा: 0xbf5c27। समस्या यह है कि 0xbf5c भी GBK में एक मान्य वर्ण है! इसका मतलब है कि एपॉस्ट्रॉफी 0x27 अनएस्केप रह जाता है, और हैकर अपना SQL कोड डाल सकता है।

// कमजोर कोड\n$name = mysql_real_escape_string($_POST['name']);\n$query = "SELECT * FROM users WHERE name = '$name'";\n\n// यदि इनपुट है: 0xbf27\n// फ़ंक्शन लौटाएगा: 0xbf5c27\n// GBK में यह है: चीनी अक्षर + एपॉस्ट्रॉफी\n// क्वेरी बन जाती है: SELECT * FROM users WHERE name = 'चीनी_अक्षर' OR 1=1 -- '\n

वाह! इंजेक्शन सफल हुआ। और यह सिद्धांत नहीं है — ऐसी कमजोरियाँ वास्तविक प्रोजेक्ट्स में पाई गई हैं।

mysql_real_escape_string() का उपयोग करते समय सामान्य कमजोरियाँ

आइए सबसे सामान्य गलतियों की सूची बनाएं जो एस्केपिंग को बायपास करने देती हैं:

\n
• गलत एन्कोडिंग — जैसा कि ऊपर के उदाहरण में है। यदि सर्वर सोचता है कि डेटा UTF-8 में है, जबकि क्लाइंट GBK भेजता है, तो एस्केपिंग टूट जाती है।
\n
• बिना उद्धरण के संख्यात्मक फ़ील्ड का उपयोग — यदि आप सीधे संख्या डालते हैं, तो एस्केपिंग काम नहीं करेगी। उदाहरण: SELECT * FROM users WHERE id = $id — और हैकर लिखता है 1 OR 1=1।
\n
• LIKE-क्वेरीज़ — एस्केपिंग % और _ वर्णों को संसाधित नहीं करता। पैटर्न के माध्यम से Blind SQL injection किया जा सकता है।
\n
• बार-बार एस्केपिंग — यदि आप फ़ंक्शन को दो बार कॉल करते हैं, तो बैकस्लैश दोगुना हो जाता है, और सुरक्षा खत्म हो जाती है।
\n

उदाहरण: संख्यात्मक फ़ील्ड पर हमला

// कमजोर कोड\n$id = mysql_real_escape_string($_GET['id']);\n$query = "SELECT * FROM products WHERE id = $id"; // उद्धरण की आवश्यकता नहीं!\n\n// हैकर इनपुट करता है: 1 UNION SELECT username, password FROM users\n// क्वेरी बन जाती है: SELECT * FROM products WHERE id = 1 UNION SELECT username, password FROM users\n

यहाँ एस्केपिंग बेकार है — एस्केप करने के लिए कोई उद्धरण नहीं हैं। हैकर सीधे अपना SQL डाल देता है।

आधुनिक सुरक्षा विधियाँ (जो काम करती हैं)

डरावनी कहानियाँ बहुत हो गईं — अब समाधानों पर आते हैं। यदि आप PHP में लिखते हैं और SQL-इंजेक्शन के बारे में भूलना चाहते हैं, तो यहाँ आपकी चेकलिस्ट है:

1. PDO या MySQLi का उपयोग prepared statements के साथ करें

यह