Safari MCP پر مبنی ایک آٹومیشن ٹول نے ڈویلپر کے ڈیش بورڈ ٹیب کو پڑھنے کے دوران ہی بند کر دیا۔ اس واقعے نے اس 'گارڈ' (guard) میں ایک چھپے ہوئے نقص کو بے نقاب کیا جو AI سے چلنے والے ایجنٹس کو کسی بھی ایسے ٹیب کو چھونے سے روکنے کے لیے بنایا گیا تھا جو ان کا اپنا نہ ہو، اور یہ ظاہر کرتا ہے کہ کیوں "safe-by-default" کیٹیگریز ایک خطرہ بن سکتی ہیں۔
وہ گارڈ جو کام کرتا تھا—جب تک کہ وہ کام کرنا چھوڑ نہ گیا
یہ ٹول اپنے بنائے ہوئے ہر ٹیب کو ایک اندرونی شناختی نشان (internal identifier) کے ساتھ ٹیگ کرتا ہے۔ ایجنٹ کی جانب سے کوئی بھی کمانڈ جاری کرنے سے پہلے، گارڈ اس مارکر کی جانچ کرتا ہے؛ اگر مارکر موجود نہ ہو، تو گارڈ عمل کرنے سے انکار کر دیتا ہے۔ عملی طور پر، گارڈ نے ایجنٹ کو وہ صفحہ پڑھنے سے روک دیا جو اس نے خود نہیں کھولا تھا—بالکل ویسا ہی جیسا کہ اسے ڈیزائن کیا گیا تھا۔
ایک فارم بھرتے وقت، صفحہ ری ڈائریکٹ ہو کر ایک مختلف ڈومین پر چلا گیا۔ اس ری ڈائریکشن نے مارکر کو ختم کر دیا، جس سے ٹیب بغیر کسی لیبل کے رہ گیا۔ گارڈ نے مارکر کی عدم موجودگی دیکھی اور رپورٹ کیا، "میں ملکیت کی تصدیق نہیں کر سکتا، اس لیے میں اس ٹیب کو نہیں پڑھوں گا۔" اس وقت سیفٹی چیک بالکل اسی طرح کام کر رہا تھا جیسا کہ اسے کرنا چاہیے تھا۔
وہ کلین اپ کوڈ جس نے حد عبور کر دی
اس کے بعد ایک دستی کلین اپ روٹین (manual cleanup routine) آئی جس کا مقصد یتیم ٹیبز (orphaned tabs)—یعنی وہ ٹیبز جن پر کوئی مارکر نہ ہو—کو بند کرنا تھا۔ اس روٹین نے ملکیت کی تصدیق کیے بغیر ٹول سے "ایک ٹیب بند کرنے" (close a tab) کا کہا۔ چونکہ گارڈ یہ ثابت نہیں کر سکا کہ ٹیب اس کا اپنا ہے، اس لیے ٹول نے ڈیفالٹ ایکشن اپنا لیا: "موجودہ ٹیب بند کریں" (close the current tab)۔ موجودہ ٹیب وہ ڈیش بورڈ تھا جسے ڈویلپر پڑھ رہا تھا، نہ کہ کوئی یتیم ٹیب۔
اس کا نتیجہ ایک تباہ کن عمل کی صورت میں نکلا جو ایک ایسے سیفٹی پاتھ سے شروع ہوا جسے ایک ڈیڈ اینڈ (dead end) ہونا چاہیے تھا۔
تین تہیں جنہوں نے "ملکیت نہ ہونے" کو اجازت سمجھ لیا
- کمانڈ کی درجہ بندی (Command categorisation) – کمانڈز کو گروپ کرنے والی فہرست نے
close_tabکو ایک وسیع "tab management" کے گروپ میں رکھ دیا۔ ڈویلپر نے یہ فرض کر لیا کہ اس گروپ میں موجود ہر چیز بے ضرر ہے کیونکہ دیگر کمانڈز (جیسے "list tabs") صرف معلومات پڑھتی ہیں۔ کسی بھی واضح نوٹ نےclose_tabکو تباہ کن کے طور پر نشان زد نہیں کیا تھا، اس لیے اس نے اپنے پڑوسیوں کی محسوس شدہ حفاظت کو اپنا لیا۔ - ایکسٹینشن لیول کی پالیسی (Extension-level policy) – Safari ایکسٹینشن جو تمام براؤزر ایکشنز کے درمیان ثالثی کرتی ہے، اس نے اس وقت کسی بھی آپریشن کی اجازت دے دی جب سیشن کی کوئی ملکیت نہیں تھی۔ وہ اصول صرف پڑھنے (read-only) والے ایکشنز کے لیے ٹھیک ہے، لیکن اس نے
close_tabکے لیے بھی کسی ثبوت کے بغیر عمل کرنے کا راستہ کھول دیا۔ - منطق کا تضاد (Logic mismatch) – کلین اپ روٹین نے ایک ٹیب پر ملکیت کے فلیگ کی جانچ کی لیکن پھر اس ٹیب پر کلوز فنکشن کال کیا جسے براؤزر نے "موجودہ" (current) کے طور پر رپورٹ کیا تھا۔ اس تضاد کی وجہ سے گارڈ کی مارکر نہ ڈھونڈ پانے کی ناکامی نے کلوز کمانڈ کو بائی پاس کر دیا اور اسے غلط ہدف کی طرف موڑ دیا۔
ہر تہہ نے یہ فرض کر لیا کہ "کوئی ملکیت ریکارڈ نہیں" کا مطلب ہے "عمل کرنے کے لیے محفوظ ہے،" اور ان سب نے مل کر ایک ایسا ٹیب بند کرنے والا کمانڈ تیار کیا جو قانونی حیثیت کے کسی بھی ثبوت کے بغیر چل گیا۔
حل: تباہ کن اعمال کے لیے ملکیت کا ثبوت لازمی ہے
نظر ثانی شدہ منطق (revised logic) پڑھنے والے راستوں کو تباہ کن راستوں سے الگ کرتی ہے۔ اب، close_tab کمانڈ کے چلنے سے پہلے، ٹول کو ہدف والے ٹیب کے لیے ایک درست مارکر پیش کرنا ہوگا۔ اگر مارکر موجود نہ ہو، تو کمانڈ موجودہ ٹیب کو ڈیفالٹ بنانے کے بجائے ایرر (error) دے گی۔ گارڈ اب کسی عام "کچھ کریں" (do something) والے برانچ پر واپس نہیں جائے گا۔
یہ تبدیلی اس مبہم حالت کو ختم کرتی ہے جہاں مارکر کی عدم موجودگی کو یا تو "کچھ کرنے کو نہیں ہے" یا "آگے بڑھیں اور عمل کریں" کے طور پر پڑھا جا سکتا ہے۔ واضح ناکامی (explicit failure) کو لازمی قرار دے کر، ٹول صارف کے کام کو حادثاتی نقصان سے بچاتا ہے۔
ڈویلپرز کو کن چیزوں پر نظر رکھنی چاہیے
- کیٹیگری کے نام کو حفاظت کا فیصلہ نہ کرنے دیں – "tab management" جیسا لیبل اس کے اندر موجود ہر کمانڈ کے اثرات کے بارے میں کچھ نہیں بتاتا۔ ہر آپریشن کی قیمت (پڑھنا بمقابلہ تباہ کرنا) کو خود کمانڈ کے ساتھ ریکارڈ کریں۔
- گارڈ کی شرائط عمل کی شدت کے مطابق ہونی چاہئیں – ایک چیک جو پڑھنے کی درخواست کے لیے کافی ہے، وہ ایسی کمانڈ کے لیے کافی نہیں ہے جو ڈیٹا ڈیلیٹ کر سکتی ہے۔ اثر کے ہر درجے کے لیے الگ ویلیڈیشن پائپ لائنز بنائیں۔
- ضمنی متبادلات (implicit fallbacks) سے بچیں – جب گارڈ ملکیت کی تصدیق نہ کر سکے، تو سب سے محفوظ ردعمل عمل کو روک دینا (abort) ہے، نہ کہ کسی ڈیفالٹ ہدف کا انتخاب کرنا۔ ڈیفالٹ ایکشنز پرائیویلیج ایسکلیشن (privilege-escalation) بگ کا ایک عام ذریعہ ہیں۔
- قریبی مفروضوں کا آڈٹ کریں – کسی بھی ایسی فہرست یا مینو کا جائزہ لیں جہاں کمانڈز ایک دوسرے کے ساتھ ہوں۔ اگر کوڈ واضح طور پر حفاظت کا دوبارہ جائزہ نہیں لیتا، تو ایک بے ضرر کمانڈ بھی اپنے پڑوسیوں پر کیے گئے اعتماد کو اپنا سکتی ہے۔
خلاصہ
ملکیت کے گارڈ کا نہ ہونا کوئی بگ (bug) نہیں ہے؛ یہ ڈیزائن کا ایک خلا ہے۔ ہر تباہ کن کمانڈ کو ایک الگ سیکیورٹی ڈومین کے طور پر لیں جو اختیار کے واضح ثبوت کا تقاضا کرتا ہے، اور کبھی بھی "مارکر نہیں ہے" کا مطلب "آگے بڑھیں" نہ نکالیں۔ صرف تب ہی آٹومیشن ٹولز ان ٹیبز کی حفاظت کر سکتے ہیں جنہیں انہیں مینیج کرنا ہوتا ہے۔