C# युद्ध में: SQL-इंजेक्शन और XSS हमलों से कोड की सुरक्षा कैसे करें

प्रस्तावना: सुरक्षा कोई विकल्प नहीं, बल्कि बुनियादी स्वच्छता क्यों है

कल्पना करें: आप C# में एक शानदार वेब सेवा लिख रहे हैं। सब कुछ पूरी तरह से काम कर रहा है — उपयोगकर्ता पंजीकरण कर रहे हैं, टिप्पणियाँ छोड़ रहे हैं, उत्पाद खोज रहे हैं। और फिर "हैकर वास्या" आता है (जिसने वास्तव में इंटरनेट से एक स्क्रिप्ट कॉपी की है) — और पूरा डेटाबेस लीक कर देता है। या, इससे भी बुरा, आपके पेज में एक स्क्रिप्ट डाल देता है जो सभी विज़िटर की कुकीज़ चुरा लेती है।

क्या यह किसी हॉरर फिल्म की तरह लगता है? लेकिन ऐसा हर दिन होता है। OWASP के आंकड़ों के अनुसार, इंजेक्शन (SQL, XSS, LDAP) वेब एप्लिकेशन की शीर्ष 3 सबसे खतरनाक कमजोरियों में शामिल हैं। और C#, अपनी सारी विश्वसनीयता के बावजूद, आपको डिफ़ॉल्ट रूप से कोई immunity-शील्ड नहीं देता।

इस लेख में हम दो सबसे गर्म हमलों — SQL-इंजेक्शन और XSS (क्रॉस-साइट स्क्रिप्टिंग) पर चर्चा करेंगे। आपको केवल सिद्धांत नहीं, बल्कि वास्तविक कोड उदाहरणों के साथ C# में सुरक्षा के युद्ध-स्तरीय तरीके मिलेंगे। चलिए शुरू करते हैं!

SQL-इंजेक्शन: जब उपयोगकर्ता हैकर बन जाता है

यह व्यवहार में कैसा दिखता है

मान लीजिए, आपके पास एक सरल लॉगिन सिस्टम है। उपयोगकर्ता लॉगिन और पासवर्ड दर्ज करता है, और आप इस तरह क्वेरी बनाते हैं:

string login = txtLogin.Text;\nstring password = txtPassword.Text;\nstring query = "SELECT * FROM Users WHERE Login = '" + login + "' AND Password = '" + password + "'";\nSqlCommand cmd = new SqlCommand(query, connection);

तार्किक लगता है? गलती! यदि हमलावर लॉगिन फ़ील्ड में दर्ज करता है: ' OR 1=1 --, तो क्वेरी बन जाती है:

SELECT * FROM Users WHERE Login = '' OR 1=1 --' AND Password = '...'

-- के बाद सब कुछ एक टिप्पणी है। शर्त 1=1 हमेशा सत्य है। क्वेरी सभी उपयोगकर्ताओं को लौटाएगी, और प्रमाणीकरण पास हो जाता है। और अगर टिप्पणी के बजाय DROP TABLE Users डाला जाए? अलविदा, डेटाबेस।

सुरक्षा #1: पैरामीटराइज्ड क्वेरी (आपकी मुख्य ढाल)

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

string login = txtLogin.Text;\nstring password = txtPassword.Text;\n\nstring query = "SELECT * FROM Users WHERE Login = @Login AND Password = @Password";\n\nusing (SqlConnection conn = new SqlConnection(connectionString))\n{\n    SqlCommand cmd = new SqlCommand(query, conn);\n    cmd.Parameters.AddWithValue("@Login", login);\n    cmd.Parameters.AddWithValue("@Password", password);\n    \n    conn.Open();\n    SqlDataReader reader = cmd.ExecuteReader();\n    // परिणाम की प्रक्रिया\n}

ध्यान दें: @Login और @Password पैरामीटर हैं। भले ही उपयोगकर्ता '; DROP TABLE Users; -- दर्ज करे, DBMS इसे कोड के रूप में नहीं, बल्कि एक सामान्य स्ट्रिंग के रूप में समझेगा। सुरक्षित और सुरुचिपूर्ण।

सुरक्षा #2: संग्रहीत प्रक्रियाएँ

एक और शक्तिशाली उपकरण — संग्रहीत प्रक्रियाएँ। वे न केवल इंजेक्शन से बचाती हैं, बल्कि प्रदर्शन में भी सुधार करती हैं (क्वेरी प्लान कैश हो जाते हैं)।

-- SQL Server\nCREATE PROCEDURE GetUserByLogin\n    @Login NVARCHAR(50)\nAS\nBEGIN\n    SELECT * FROM Users WHERE Login = @Login\nEND

// C# कोड\nusing (SqlConnection conn = new SqlConnection(connectionString))\n{\n    SqlCommand cmd = new SqlCommand("GetUserByLogin", conn);\n    cmd.CommandType = CommandType.StoredProcedure;\n    cmd.Parameters.AddWithValue("@Login", inputLogin);\n    \n    conn.Open();\n    // ...\n}

सुरक्षा #3: Entity Framework और ORM

यदि आप Entity Framework (या कोई अन्य ORM) का उपयोग करते हैं, तो आप पहले से ही आंशिक रूप से सुरक्षित हैं। EF स्वचालित रूप से पैरामीटराइज्ड क्वेरी उत्पन्न करता है। लेकिन एक बारीक बात है: EF के माध्यम से कच्ची SQL क्वेरी (विधि FromSqlRaw) — यह वही संयोजन है। सावधान रहें!

// बुरा:\nvar users = context.Users.FromSqlRaw("SELECT * F