SQL انجیکشن SQLi
ایک ویب حملہ جس میں کوئی شخص فارم یا ویب ایڈریس میں ڈیٹا بیس کی کمانڈز لکھ دیتا ہے۔ ویب سائٹ انہیں چلا دیتی ہے اور وہ ڈیٹا ظاہر، تبدیل یا حذف کر دیتی ہے جس کی اسے حفاظت کرنی چاہیے۔
اس نام سے بھی جانا جاتا ہے SQLi SQL Injection SQL انجیکشن اٹیک SQL کوڈ انجیکشن ڈیٹا بیس انجیکشن انجیکشن حملہ
تعریف
SQL انجیکشن کیا ہے
آپ ایک آن لائن دکان چلاتے ہیں۔ ایک وزیٹر سرچ باکس میں کچھ عجیب سا لکھتا ہے، Enter دباتا ہے، اور صفحہ اسے آپ کے تمام گاہکوں کے نام، فون نمبر اور آرڈرز کی تاریخ دکھا دیتا ہے۔ کسی نے پاس ورڈ نہیں چرایا۔ اس نے درست الفاظ غلط جگہ پر لکھے، اور باقی کام آپ کی ویب سائٹ نے کر دیا۔ یہی SQL انجیکشن ہے۔
زیادہ تر ویب سائٹیں اپنی معلومات ایک ڈیٹا بیس میں رکھتی ہیں: جدولوں کا ایک منظم ذخیرہ، کچھ حد تک اسپریڈ شیٹس کے ایک مجموعے جیسا۔ ان معلومات کو پڑھنے یا بدلنے کے لیے ویب سائٹ SQL (Structured Query Language) نام کی زبان استعمال کرتی ہے۔ وہ جو بھی درخواست بھیجتی ہے اسے کوئری کہتے ہیں، جیسے "وہ گاہک ڈھونڈو جس کی ای میل یہ ہے"۔
SQL انجیکشن تب ہوتا ہے جب ویب سائٹ وزیٹر کا لکھا ہوا متن لے کر سیدھا انہی میں سے کسی کوئری میں ڈال دیتی ہے۔ اگر وزیٹر عام متن کی جگہ SQL لکھ دے تو ڈیٹا بیس فرق نہیں پہچان پاتا اور حملہ آور کی کمانڈ کو ایسے مانتا ہے جیسے ویب سائٹ نے خود لکھی ہو۔ لوگ اکثر اس کا نام مختصر کر کے SQLi کہتے ہیں۔
SQL انجیکشن حملہ کیسے کام کرتا ہے
ایک بینک کلرک کے بارے میں سوچیے جو گاہک کی دی ہوئی ہر پرچی لفظ بہ لفظ تجوری والے عملے تک پہنچا دیتا ہے۔ عام پرچی کہتی ہے "میرا بیلنس دکھائیں"۔ چالاکی والی پرچی کہتی ہے "میرا بیلنس دکھائیں، اور ساری تجوریاں بھی کھول دیں"۔ اگر کلرک پہلے کبھی پرچی نہیں پڑھتا تو تجوری والا عملہ وہی کر دیتا ہے۔
ویب سائٹ پر مراحل عام طور پر یوں ہوتے ہیں:
- حملہ آور ایسی جگہ ڈھونڈتا ہے جو ڈیٹا بیس کو متن بھیجتی ہو: لاگ اِن فارم، سرچ باکس، رابطہ فارم، یا خود ویب ایڈریس، جیسے کسی پروڈکٹ پیج کا ایڈریس جو "?id=25" پر ختم ہوتا ہے۔
- وہ عام متن کی جگہ SQL کا ایک چھوٹا سا ٹکڑا لکھتا ہے۔ ایک مشہور مثال لاگ اِن فارم کے پاس ورڈ والے خانے میں ' OR '1'='1 لکھنا ہے۔
- ویب سائٹ اس متن کو جانچے بغیر اپنی کوئری میں جوڑ دیتی ہے۔ اب کوئری کچھ ایسا پوچھتی ہے: "اس شخص کو اندر آنے دو اگر پاس ورڈ درست ہے، یا اگر 1 برابر ہے 1 کے"۔
- چونکہ 1 ہمیشہ 1 کے برابر ہوتا ہے، ڈیٹا بیس ہاں کہہ دیتا ہے، اور حملہ آور کوئی پاس ورڈ جانے بغیر لاگ اِن ہو جاتا ہے۔
کچھ حملے زیادہ خاموشی سے ہوتے ہیں۔ بلائنڈ SQL انجیکشن میں صفحہ کوئی ڈیٹا نہیں دکھاتا، اس لیے حملہ آور ڈیٹا بیس سے ہاں یا نہیں والے سوال پوچھتا ہے اور دیکھتا ہے کہ صفحہ کیسا ردعمل دیتا ہے یا لوڈ ہونے میں کتنا وقت لیتا ہے۔ ہاتھ سے یہ سست کام ہے، اسی لیے حملہ آور مفت خودکار ٹولز سے یہ کام کرواتے ہیں۔
حملہ آور اس سے کیا کر سکتا ہے
جب ڈیٹا بیس اس کی کمانڈز ماننے لگتا ہے تو نقصان اس بات پر منحصر ہوتا ہے کہ ویب سائٹ کے ڈیٹا بیس اکاؤنٹ کو کیا کرنے کی اجازت ہے۔ اکثر یہ اجازت ویب سائٹ کی ضرورت سے کہیں زیادہ ہوتی ہے۔ حملہ آور یہ کر سکتا ہے:
- نجی ڈیٹا پڑھنا، جیسے گاہکوں کے نام، پتے، ای میلز، آرڈرز کی تاریخ، طبی ریکارڈ یا محفوظ کیے گئے پاس ورڈ
- کسی دوسرے صارف کے نام سے لاگ اِن ہونا، ایڈمن کے نام سے بھی
- ڈیٹا بدلنا، جیسے قیمتیں، بیلنس یا آرڈرز کی حالت
- پوری جدولیں مٹانا، یا پورا ڈیٹا بیس
- کچھ سیٹ اپس میں خود سرور تک پہنچنا اور اس پر نقصان دہ فائلیں رکھ دینا
یہ آپ کے کاروبار کے لیے کیوں اہم ہے
SQL انجیکشن سب سے پرانے ویب حملوں میں سے ایک ہے، اور یہ آج بھی موجود ہے۔ OWASP ایک کھلی کمیونٹی ہے جو ویب ایپلیکیشنز کے خطرات کی مشہور فہرست OWASP Top 10 شائع کرتی ہے، اور اس نے انجیکشن کو برسوں سے اس فہرست میں رکھا ہوا ہے۔ اسے آزمانا آسان ہے، اور بہت سی ویب سائٹوں میں اب بھی کوئی بھولا ہوا فارم ہوتا ہے جو اس کے لیے کھلا رہتا ہے۔
کاروبار کے مالک کے لیے اصل نقصان شاذ و نادر ہی تکنیکی ہوتا ہے۔ یہ لیک ہونے والی گاہکوں کی فہرست ہو سکتی ہے، غلط قیمت پر سامان بیچتی دکان، ایک ہفتے کی اپائنٹمنٹس گنوا دینے والا بکنگ سسٹم، یا وہ پیغام جو آپ کو گاہکوں کو بھیجنا پڑے کہ ان کا ڈیٹا ظاہر ہو گیا ہے۔ بہت سے ممالک میں GDPR جیسے ڈیٹا کے تحفظ کے قوانین بھی آپ سے توقع رکھتے ہیں کہ آپ ذاتی ڈیٹا کی حفاظت کریں اور لیک کی اطلاع دیں۔
کیا آپ کی ویب سائٹ کا ہر فارم اس خطرے کو ذہن میں رکھ کر بنایا گیا تھا؟ جو ویب سائٹیں پرانے پلگ اِنز سے جلدی میں بنائی گئیں، یا برسوں میں کئی ہاتھوں سے بدلی گئیں، ان میں کوئی کمزور جگہ چھپی ہونے کا امکان زیادہ ہوتا ہے۔
ویب سائٹ کو SQL انجیکشن سے کیسے بچائیں
بنیادی حل سب کو معلوم ہے، اور یہ کام کرتا ہے۔ زیادہ تر حفاظت اس بات میں ہے کہ ویب سائٹ کیسے بنائی گئی ہے، اس لیے یہ سوال آپ کو اپنے ڈویلپرز یا سروس فراہم کرنے والے سے پوچھنے چاہییں۔
- پریپیئرڈ اسٹیٹمنٹس۔ انہیں پیرامیٹر والی کوئریز بھی کہتے ہیں۔ ویب سائٹ کوئری اور وزیٹر کا متن الگ الگ بھیجتی ہے، اس لیے ڈیٹا بیس اس متن کو ہمیشہ صرف ڈیٹا سمجھتا ہے، کبھی کمانڈ نہیں۔ یہی بنیادی بچاؤ ہے۔ Laravel جیسے جدید فریم ورکس یہ کام خود بخود کرتے ہیں جب ڈویلپرز ان کے بنے بنائے ڈیٹا بیس ٹولز استعمال کرتے ہیں۔
- ان پٹ کی جانچ۔ فون نمبر والے خانے میں صرف ہندسے آنے چاہییں، اور تاریخ والے خانے میں صرف تاریخ۔ عجیب ان پٹ کو شروع میں ہی رد کر دینے سے بہت سے دروازے بند ہو جاتے ہیں۔
- کم سے کم اختیارات۔ ویب سائٹ جس اکاؤنٹ سے ڈیٹا بیس تک پہنچتی ہے، اس کے پاس صرف اتنے ہی اختیارات ہونے چاہییں جتنے اسے درکار ہیں۔ ایک عوامی سرچ پیج کے پاس جدولیں مٹانے کی کوئی وجہ نہیں ہے۔
- کم بولنے والے ایرر میسجز۔ اسکرین پر ڈیٹا بیس کی تفصیلی غلطی حملہ آور کو نقشہ تھما دیتی ہے۔ وزیٹر کو مختصر اور سادہ پیغام دکھائیں، اور تفصیلات نجی لاگز میں رکھیں۔
- اپ ڈیٹس۔ پلیٹ فارم، پلگ اِنز اور لائبریریوں کو اپ ڈیٹ رکھیں، کیونکہ پرانے ورژنز میں اکثر معلوم خامیاں ہوتی ہیں۔
- ویب ایپلیکیشن فائر وال۔ یہ ویب سائٹ کے سامنے لگا ایک فلٹر ہے جو بہت سے جانے پہچانے حملوں کو آپ کے کوڈ تک پہنچنے سے پہلے روک دیتا ہے۔ یہ مدد کرتا ہے، لیکن غیر محفوظ کوڈ کو ٹھیک نہیں کرتا۔
- باقاعدہ ٹیسٹ۔ پینیٹریشن ٹیسٹ (ماہرین کا کیا ہوا محفوظ اور منصوبہ بند حملہ) اور کمزوریوں کا اسکین کمزور جگہوں کو حملہ آور سے پہلے ڈھونڈ لیتے ہیں۔
روزمرہ عادتوں کا موازنہ کچھ یوں ہے:
| خطرناک عادت | زیادہ محفوظ عادت |
|---|---|
| وزیٹر کا متن سیدھا کوئری میں جوڑنا | ہر کوئری کے لیے پریپیئرڈ اسٹیٹمنٹس استعمال کرنا |
| ہر کام کے لیے مکمل اختیارات والا ایک ہی ڈیٹا بیس اکاؤنٹ | ویب سائٹ کے ہر حصے کے لیے محدود اکاؤنٹ |
| صفحے پر ڈیٹا بیس کی مکمل غلطیاں دکھانا | وزیٹر کے لیے مختصر پیغام، تفصیلات نجی لاگز میں |
| مہینوں تک بغیر اپ ڈیٹ کے پڑے پلگ اِنز | باقاعدہ اپ ڈیٹس اور انسٹال شدہ چیزوں کی واضح فہرست |
| صرف یہ جانچنا کہ فیچرز چل رہے ہیں | یہ بھی جانچنا کہ کوئی نقصان دہ چیز لکھے تو کیا ہوتا ہے |
لوگ کون سی غلطیاں کرتے ہیں
- براؤزر کی جانچ پر بھروسا کرنا۔ وزیٹر کے اپنے ڈیوائس پر چلنے والی جانچ سے بچنا آسان ہے، اس لیے سرور کو سب کچھ دوبارہ جانچنا چاہیے۔
- یہ سوچنا کہ چھوٹی ویب سائٹ محفوظ ہے۔ خودکار ٹولز بہت بڑی تعداد میں ویب سائٹیں جانچتے ہیں، چاہے وہ کتنی ہی چھوٹی یا بڑی ہوں۔
- ایک فارم ٹھیک کرنا اور باقی بھول جانا۔ سرچ باکس، فلٹرز، ویب ایڈریس اور موبائل ایپ کے پیچھے کا API، سب کو ایک جیسی توجہ چاہیے۔
- پاس ورڈ سادہ متن میں رکھنا۔ اگر ڈیٹا لیک ہو جائے تو مضبوط ہیشنگ سے رکھے گئے پاس ورڈ (ایسے الجھے ہوئے کوڈ میں بدلے گئے جسے واپس پڑھا نہیں جا سکتا) کا غلط استعمال بہت مشکل ہوتا ہے۔
- صرف فائر وال پر انحصار کرنا۔ فلٹر آپ کو وقت دیتا ہے۔ اس کے پیچھے کی غیر محفوظ کوئری کو پھر بھی ٹھیک کرنا پڑتا ہے۔
ہم کیسے مدد کر سکتے ہیں
Linkysoft میں SQL انجیکشن کی جانچ ہماری سائبر سیکیورٹی سروسز کا حصہ ہے۔ ہم آپ کی ویب سائٹ، ایپ اور API پر محفوظ، فرضی حملے کرتے ہیں، کوڈ کا جائزہ لیتے ہیں، اور آپ کو آسان زبان میں ایک فہرست دیتے ہیں کہ ہمیں کیا ملا اور اسے کیسے ٹھیک کرنا ہے۔ درستی کے بعد ہم دوبارہ ٹیسٹ کرتے ہیں۔ یہ دوسری ٹیموں کی بنائی ہوئی ویب سائٹوں کے لیے بھی کام کرتا ہے، اور مفت سیکیورٹی جانچ ایک آسان پہلا قدم ہے۔
نیا سسٹم بنانے کا سوچ رہے ہیں؟ ہماری ویب ایپلیکیشنز اور مینجمنٹ سسٹمز شروع سے ہی محفوظ بنائے جاتے ہیں، OWASP Top 10 کے مطابق مضبوطی اور لانچ سے پہلے پینیٹریشن ٹیسٹ کے ساتھ۔
SQL انجیکشن کے بارے میں سوالات
آسان الفاظ میں SQL انجیکشن کیا ہے؟
کیا چھوٹی ویب سائٹ پر بھی SQL انجیکشن ہو سکتا ہے؟
مجھے کیسے پتا چلے گا کہ میری ویب سائٹ SQL انجیکشن کے لیے کمزور ہے؟
SQL انجیکشن روکنے کا بہترین طریقہ کیا ہے؟
کیا فائر وال SQL انجیکشن کو روک دیتی ہے؟
بلائنڈ SQL انجیکشن کیا ہے؟
اگر میری ویب سائٹ پر SQL انجیکشن ہو جائے تو کیا کروں؟
کیا SQL انجیکشن صرف ویب سائٹوں کا مسئلہ ہے؟
ابھی بھی یقین نہیں کہ یہ آپ کے پروجیکٹ پر کیسے لاگو ہوتا ہے؟
ہمیں بتائیں آپ کیا بنا رہے ہیں، ہم سادہ الفاظ میں جواب دیں گے۔