SQL Injection क्या है और आप इसे कैसे रोकते हैं?

SQL injection late 1990s से है और यह अभी भी web applications के compromise होने का सबसे common तरीका है। bug सरल है: एक attacker input भेजता है जो plain data की जगह SQL code के रूप में interpret होता है, और database कुछ ऐसा करता है जो उसे कभी नहीं करना चाहिए था।

attack actually कैसे काम करता है

एक login form को imagine करें जो PHP में इस तरह query बनाता है:

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";

अगर app input को sanitize नहीं करता, तो एक attacker username field में admin' -- type करता है। query बन जाती है:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

-- line के बाकी को comment कर देता है, तो password check कभी नहीं होता। यह एक classic auth bypass है। Attackers UNION SELECT भी use करते हैं दूसरी tables से data निकालने के लिए, या semicolon के साथ queries stack करते हैं कुछ destructive चलाने के लिए जैसे DROP TABLE users; अगर driver multiple statements allow करता है।

Blind SQL injection भी है, जहाँ app query results directly नहीं दिखाता। Attackers timing से information infer करते हैं (SLEEP(5) MySQL में) या boolean responses से (क्या page एक true vs. false condition के लिए अलग तरह से behave करता है)। sqlmap जैसे tools इस तरह के extraction को automate करते हैं एक बार vulnerable parameter मिल जाने पर।

string concatenation root problem क्यों है

इस attack का हर variant एक चीज़ पर वापस आता है: code और data को same string में mix करना। database differentiate नहीं कर सकता एक legitimate value और injected syntax के बीच क्योंकि वे same channel में आते हैं। Escaping quotes कुछ cases में मदद करता है लेकिन यह fragile है — different encodings, second-order injection (data एक बार store होता है, फिर later unsafely reuse होता है), और driver-specific quirks सब bypass paths create करते हैं। Escaping एक patch है, एक fix नहीं।

Parameterized queries real fix हैं

fix यह है कि SQL code को user data से driver level पर separate किया जाए, parameterized queries (जिन्हें prepared statements भी कहा जाता है) use करके। database को पहले query structure मिलता है, फिर values afterward bind होती हैं, तो user input कभी query के meaning को change नहीं कर सकता।

Python में psycopg2 के साथ:

cur.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))

Node.js में mysql2 के साथ:

connection.execute('SELECT * FROM users WHERE username = ? AND password = ?', [username, password]);

Java में JDBC के साथ:

PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?");
stmt.setString(1, username);
stmt.setString(2, password);

pattern को notice करें: placeholders (%s, ?) data के लिए जगह hold करते हैं, और actual values अलग से pass होती हैं। कोई string concatenation नहीं, कोई manual escaping की ज़रूरत नहीं। यह एक normal application में आप जो queries लिखते हैं उनके huge majority के लिए काम करता है।

dynamic table या column names के बारे में क्या?

Parameterization values को handle करता है लेकिन identifiers को नहीं — आप एक table name को parameter के रूप में bind नहीं कर सकते। अगर आपके app को एक table को dynamically select करने की ज़रूरत है (rare, और अक्सर एक design smell), तो allowed values को एक hardcoded list के खिलाफ whitelist करें user input को directly trust करने की जगह:

allowed_tables = {'orders', 'invoices', 'customers'}
if table_name not in allowed_tables:
    raise ValueError("Invalid table")

कभी भी identifier names को user input से string formatting के through build न करें, escaping के साथ भी नहीं।

query के beyond layered defenses

Parameterized queries primary control हैं, लेकिन कुछ अन्य चीज़ें matter करती हैं:

• Least privilege on the database account. app का DB user को DROP, ALTER, या unrelated schemas तक access नहीं होना चाहिए। अगर एक injection slip through करता है, तो limited privileges damage को cap करते हैं।
• ORMs by default मदद करते हैं। Django की ORM, SQLAlchemy, और Hibernate सब automatically queries को parameterize करते हैं जब आप उनके standard query-building methods use करते हैं। risk फिर से appear होता है जब developers raw SQL में drop करते हैं या .extra()/text() calls use करते हैं string interpolation के साथ — तो उन spots को specifically audit करें।
• Input validation एक secondary layer है, replacement नहीं। checking कि एक email field एक email जैसा दिखता है good practice है, लेकिन यह injection को अपने आप रोक नहीं सकता — attackers creative payloads find करते हैं जो still loose validation pass करते हैं।
• एक WAF known attack patterns को catch कर सकता है, लेकिन यह एक detection layer है, underlying code के लिए एक fix नहीं।

अपने code को इस bug के लिए test करना

अपनी queries को एक static analysis tool के through run करें (Python के लिए Bandit, SQL injection rulesets के साथ Semgrep) CI के part के रूप में। Manual testing के लिए, एक single quote (') को हर input field में inject करने की कोशिश करें और response में SQL error messages leaking के लिए देखें — यह अक्सर पहली sign है कि एक query parameterized नहीं है।

अगर आप इस पर deeper जाना चाहते हैं, तो Korra Studio की Web Security track injection को XSS और auth bypass के साथ cover करता है, और Databases segments query design patterns walk through करते हैं जो इस class की bug को completely avoid करते हैं।