SQL Injection کیا ہے اور آپ اس سے کیسے بچتے ہیں؟

SQL injection 1990 کی دہائی کے آخر سے موجود ہے اور یہ ابھی بھی ویب ایپلیکیشنز کے compromise ہونے کے سب سے عام طریقوں میں سے ایک ہے۔ یہ خرابی سادہ ہے: حملہ ور ایسی input بھیجتا ہے جو SQL کوڈ کے طور پر interpret ہوتی ہے صرف ڈیٹا کے بجائے، اور ڈیٹابیس وہ کرتا ہے جو اسے کبھی کرنا نہیں چاہیے تھا۔

حملہ اصل میں کیسے کام کرتا ہے

تصور کریں ایک login فارم جو PHP میں اس طرح ایک query بناتا ہے:

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

اگر app input کو sanitize نہیں کرتا، تو حملہ ور username field میں admin' -- type کرتا ہے۔ Query بن جاتی ہے:

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

-- بقیہ لائن کو comment کرتا ہے، تو password کی جانچ کبھی نہیں ہوتی۔ یہ ایک classic auth bypass ہے۔ حملہ ور UNION SELECT بھی استعمال کرتے ہیں دوسری tables سے ڈیٹا نکالنے کے لیے، یا semicolon کے ساتھ queries کو stack کرتے ہیں کوئی destructive چیز چلانے کے لیے جیسے DROP TABLE users; اگر driver متعدد statements کی اجازت دیتا ہے۔

blind SQL injection بھی ہے، جہاں app query کے نتائج براہ راست نہیں دکھاتا۔ حملہ ور timing کے ذریعے معلومات کا اندازہ لگاتے ہیں (SLEEP(5) MySQL میں) یا boolean responses (کیا صفحہ true بمقابلہ false condition کے لیے مختلف سلوک کرتا ہے)۔ sqlmap جیسے tools اس قسم کی extraction کو automate کرتے ہیں جب ایک vulnerable parameter مل جائے۔

string concatenation بنیادی مسئلہ کیوں ہے

اس حملے کی ہر variant ایک چیز پر واپس آتی ہے: code اور data کو ایک ہی string میں ملانا۔ ڈیٹابیس فرق نہیں بتا سکتا ایک جائز value اور injected syntax کے درمیان کیونکہ وہ ایک ہی channel میں آتے ہیں۔ Escaping quotes بعض حالات میں مدد کرتا ہے لیکن یہ نازک ہے — مختلف encodings، second-order injection (ڈیٹا ایک بار محفوظ کیا جائے، پھر بعد میں غیر محفوظ طریقے سے دوبارہ استعمال)، اور driver-specific quirks سب bypass کے راستے بناتے ہیں۔ Escaping ایک patch ہے، fix نہیں۔

Parameterized queries اصل حل ہیں

حل یہ ہے کہ SQL code کو user data سے driver level پر الگ کریں، parameterized queries استعمال کرتے ہوئے (جسے prepared statements بھی کہتے ہیں)۔ ڈیٹابیس کو پہلے query کی ساخت ملتی ہے، پھر بعد میں values bind ہوتی ہیں، تو user input query کے معنی کو کبھی تبدیل نہیں کر سکتی۔

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 کو دیکھیں: placeholders (%s, ?) data کے لیے جگہ رکھتے ہیں، اور اصل values الگ سے pass ہوتی ہیں۔ کوئی string concatenation نہیں، کوئی manual escaping ضروری نہیں۔ یہ queries کی بھاری اکثریت کے لیے کام کرتا ہے جو آپ ایک عام application میں لکھیں گے۔

dynamic table یا column names کے بارے میں کیا؟

Parameterization values کو handle کرتا ہے لیکن identifiers کو نہیں — آپ table name کو parameter کے طور پر bind نہیں کر سکتے۔ اگر آپ کے app کو ایک table کو dynamically select کرنے کی ضرورت ہے (نادر، اور اکثر ایک design smell)، allowed values کو ایک hardcoded list کے خلاف whitelist کریں بجائے اس کے کہ user input پر سیدھے سادھے اعتماد کریں:

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

کبھی بھی identifier names کو user input سے string formatting کے ذریعے build نہ کریں، escaping کے ساتھ بھی۔

query خود سے آگے layered defenses

Parameterized queries بنیادی control ہیں، لیکن کچھ اور چیزیں اہم ہیں:

• ڈیٹابیس اکاؤنٹ پر least privilege۔ App کا DB user کو DROP، ALTER، یا غیر متعلقہ schemas تک رسائی نہیں ہونی چاہیے۔ اگر injection پھسل جائے، تو limited privileges نقصان کو محدود کرتے ہیں۔
• ORMs ڈیفالٹ سے مدد کرتے ہیں۔ Django کا ORM، SQLAlchemy، اور Hibernate سب queries کو automatically parameterize کرتے ہیں جب آپ ان کے standard query-building methods استعمال کرتے ہیں۔ خطرہ دوبارہ ظاہر ہوتا ہے جب developers raw SQL میں جاتے ہیں یا .extra()/text() calls استعمال کرتے ہیں string interpolation کے ساتھ — تو وہ spots خاص طور پر audit کریں۔
• Input validation ایک secondary layer ہے، replacement نہیں۔ یہ چیک کرنا کہ ایک email field ایک email کی طرح لگتا ہے اچھی practice ہے، لیکن یہ injection کو روکتا نہیں ہے — حملہ ور creative payloads تلاش کرتے ہیں جو ابھی بھی loose validation کو pass کرتے ہیں۔
• WAF معروف حملے کے patterns کو پکڑ سکتا ہے، لیکن یہ ایک detection layer ہے، underlying code کے لیے fix نہیں۔

اپنے اپنے کوڈ کو اس خرابی کے لیے test کریں

اپنی queries کو ایک static analysis tool کے ذریعے چلائیں (Python کے لیے Bandit، SQL injection rulesets کے ساتھ Semgrep) CI کے حصے کے طور پر۔ Manual testing کے لیے، ایک single quote (') کو ہر input field میں inject کرنے کی کوشش کریں اور response میں SQL error messages کو دیکھیں — یہ اکثر پہلا نشان ہے کہ ایک query parameterized نہیں ہے۔

اگر آپ اس پر مزید گہرائی میں جانا چاہتے ہیں، تو Korra Studio کا Web Security track injection کو XSS اور auth bypass کے ساتھ احاطہ کرتا ہے، اور Databases segments query design patterns کے ذریعے چلتے ہیں جو bug کی اس class کو مکمل طور پر avoid کرتے ہیں۔