flawopen.com/SQL Injection/क्या escaping काफ़ी है?

क्या Quotes Escape करने से SQL Injection रुकता है?

CWE-89: SQL InjectionReference page

संक्षिप्त उत्तर

आमतौर पर नहीं। Escaping फ़ंक्शन डेटाबेस, connection character set, SQL mode और quotes के सटीक context पर निर्भर करता है। Parameterized queries driver API के ज़रिए values को SQL syntax से अलग रखती हैं। Values के लिए parameters इस्तेमाल करें; जिन dynamic identifiers को bind नहीं कर सकते, उन्हें application की fixed allowlist से चुनें।

व्यवहार में escaping नाज़ुक क्यों है

Connection character set escaping को बदल सकता है

Escaping context से स्वतंत्र text replacement नहीं है। MySQL के अनुसार mysql_real_escape_string() connection character set का उपयोग करता है और SET NAMES उस client library state को अपडेट नहीं करता जिसे यह function उपयोग करता है। Mismatch होने पर escaped text के बारे में धारणाएँ गलत हो सकती हैं। Parameterized APIs को प्राथमिकता दें; पुराने code में escaping आवश्यक हो तो driver की समर्थित function से charset सेट करें और errors संभालें।

एक call छूटने से पूरी सुरक्षा कमज़ोर होती है

हर interpolation point पर सही driver, character set, SQL mode और string-literal context के अनुसार escaping लागू करनी पड़ती है। Parameterized APIs query call पर value और data का अंतर स्पष्ट करती हैं और quoted string को हाथ से बनाने से बचाती हैं।

Quotes Escape करना हर SQL context की रक्षा नहीं करता

Quote escaping केवल किसी खास quoted string के अंदर के characters संभालता है। यह table/column name, keyword या sort direction सुरक्षित नहीं बनाता और unquoted numeric expression में input से भी नहीं बचाता। Values bind करें और dynamic SQL structure को application के fixed choices से map करें।

VULNERABLE

// User input को SQL syntax में जोड़ा गया है
query = f"SELECT id FROM users WHERE name = '{name}'"
cursor.execute(query)

HARDENED

// Driver name को data value के रूप में bind करता है
cursor.execute(
    "SELECT id FROM users WHERE name = ?",
    (name,),
)

Parameter binding क्या बदलती है

Parameterized query database API के ज़रिए SQL structure और values अलग inputs के रूप में देती है। Drivers native prepared statements या कोई अन्य सुरक्षित implementation इस्तेमाल कर सकते हैं; किसी एक protocol sequence को न मानें। सुरक्षा का गुण यह है कि value data रहती है, SQL syntax के रूप में दोबारा parse नहीं होती। Python DB-API में driver का placeholder इस्तेमाल करें और values अलग दें; string formatting से query न बनाएँ।

इंजीनियरिंग जाँच सूची

✓हर user-controlled data value को driver API से bind करें; उसे SQL text में format न करें।
✓Dynamic table, column और sort names को application की fixed allowlist से चुनें।
✓यदि legacy escaping अभी नहीं हट सकती, तो driver की context-appropriate API इस्तेमाल करें और connection character set तथा SQL mode जाँचें।
✓Quotes, non-ASCII text और invalid identifiers से query construction जाँचें; destructive statements न भेजें।

अक्सर पूछे जाने वाले प्रश्न

क्या escaping कभी सही विकल्प हो सकता है?

जो identifier या SQL fragment bind नहीं हो सकता, उसके लिए driver की समर्थित quoting API और application की fixed allowlist साथ इस्तेमाल करें। Arbitrary values पर सामान्य escaping न लगाएँ।

यदि driver की escape function maintained है, तो क्या वह सुरक्षित है?

यह documented context में मदद कर सकती है, लेकिन database, connection settings, quoting context और हर call site पर सही उपयोग पर निर्भर रहती है। Values के लिए parameterized queries अधिक सुरक्षित default हैं।

संदर्भ

यह भी देखें SQL इंजेक्शन (CWE-89): यह कैसे काम करता है और हर भाषा में इसे कैसे रोकें — flawopen.com SQL इंजेक्शन रोकने के लिए ORM का उपयोग काफ़ी है? क्या Knex.js SQL Injection से सुरक्षित है? MyBatis ${} बनाम #{}: SQL Injection से बचाव MySQLi बनाम PDO: सुरक्षित Prepared Statements क्या NHibernate SQL Injection से बचाता है? MongoDB NoSQL Injection: सुरक्षित query filters