ایک GET collection endpoint پر سیکیورٹی چیک کی کمی کی وجہ سے CoopCycle کے کسی بھی بنیادی اکاؤنٹ والا شخص ایک مشترکہ instance میں موجود ہر اسٹور کی مکمل ایڈریس بک حاصل کر سکتا تھا، جس سے بے شمار صارفین کے نام، گلی کے پتے اور پوسٹ کوڈز ظاہر ہو گئے۔ اس خامی کو دو دنوں کے اندر ٹھیک کر دیا گیا ہے، اور صارفین کو تازہ ترین ورژن پر اپ گریڈ کرنے کی تاکید کی جاتی ہے۔
یہ ڈیٹا لیک کیسے ہوا
CoopCycle – جو کہ فوڈ ڈیلیوری کوآپریٹیوز کے ذریعے استعمال کیا جانے والا ایک اوپن سورس لاجسٹکس پلیٹ فارم ہے – اپنی API کو PHP فریم ورک API Platform کے ذریعے ڈیفائن کرتا ہے۔ اس فریم ورک میں ہر آپریشن (POST, GET, وغیرہ) کے ساتھ ایک سیکیورٹی ایکسپریشن (security expression) کا ہونا ضروری ہے؛ اگر یہ ایکسپریشن موجود نہ ہو تو فریم ورک بغیر کسی اتھارائزیشن چیک کے کوڈ چلا دیتا ہے۔
ڈویلپرز نے اسٹور کی ایڈریس لسٹ بنانے یا اسے اپ ڈیٹ کرنے والی POST ریکویسٹ کو معیاری ایکسپریشن is_granted('edit', object) کے ذریعے محفوظ کیا تھا۔ یہ اس لیے کام کرتا ہے کیونکہ ریکویسٹ ایک واحد اسٹور اینٹیٹی (entity) کو نشانہ بناتی ہے، جس سے فریم ورک کو جانچ پڑتال کے لیے ایک ٹھوس "object" مل جاتا ہے۔
وہی ریسورس پڑھنے والی GET ریکویسٹ ایک کلیکشن (collection) کو نشانہ بناتی ہے: /api/stores/{id}/addresses۔ ایک کلیکشن میں کوئی ایک واحد آبجیکٹ نہیں ہوتا، اس لیے وہی is_granted('edit', object) ایکسپریشن وہاں لاگو نہیں کی جا سکتی۔ چونکہ ڈویلپرز نے سیکیورٹی لائن شامل نہیں کی تھی، اس لیے فریم ورک نے کسی بھی تصدیق شدہ (authenticated) صارف کو، tenancy سے قطع نظر، ایڈریس کا ڈیٹا فراہم کر دیا۔
ایک مشترکہ CoopCycle instance پر، ایک بدنیتی پر مبنی صارف محض اسٹور آئی ڈیز (IDs) کو ترتیب وار چلا کر، اینڈ پوائنٹ پر GET ریکویسٹس بھیج سکتا تھا، اور سسٹم میں محفوظ ہر صارف کے گھر کے پتے نکال سکتا تھا۔ اس کے لیے ایک عام اکاؤنٹ کے علاوہ کسی اضافی مراعات (privileges) کی ضرورت نہیں تھی۔
یہ بگ (bug) کیوں برقرار رہا
یہ مسئلہ محض ایک سادہ سی غلطی نہیں تھی۔ API Platform کے ڈیکلیریٹیو سیکیورٹی ماڈل میں یہ بتانے کا کوئی سیدھا طریقہ نہیں ہے کہ "صارف کو کلیکشن میں موجود ہر آبجیکٹ کے ساتھ ایک ہی ٹیننٹ (tenant) سے تعلق رکھنا چاہیے"۔ کوڈ کی وہ غائب لائن بالکل وہیں تھی جہاں فریم ورک اتھارزییشن کو مشکل بنا دیتا ہے۔
مسئلے کو مزید سنگین بنانے والی بات یہ ہے کہ پروجیکٹ کے ٹیسٹ سویٹ (test suite) نے درحقیقت یہ دعویٰ کیا تھا کہ تمام ایڈریسز پر مشتمل GET رسپانس ایک متوقع طرزِ عمل تھا۔ دوسرے لفظوں میں، خودکار ٹیسٹ اس لیے پاس ہو گئے کیونکہ ٹیسٹنگ میں استعمال ہونے والے fixtures نے کراس-ٹیننٹ رسائی (cross-tenant access) کی اجازت دی تھی، جس نے مؤثر طور پر اس کمزوری کو چھپا دیا۔ اس معاملے میں، ایک کامیاب ٹیسٹ سویٹ نے سیکیورٹی کا غلط احساس دلایا۔
فائدہ کس کا اور نقصان کس کا
- صارفین (Customers): ان کی ذاتی طور پر شناخت کے قابل معلومات (PII) – مکمل نام اور گھر کے پتے – پلیٹ فارم پر موجود کسی بھی شخص کے لیے ظاہر ہو گئے۔ اگرچہ ڈیٹا عوامی طور پر پوسٹ نہیں کیا گیا تھا، لیکن اس خلاف ورزی نے متعدد کوآپریٹیوز کی رازداری کو خطرے میں ڈال دیا۔
- CoopCycle استعمال کرنے والی کوآپریٹیوز: ٹیننٹ ڈیٹا کو محفوظ رکھنے کی پلیٹ فارم کی صلاحیت پر اعتماد کمزور ہوا۔ وہ تمام کوآپریٹیوز جنہوں نے ابھی تک اپ گریڈ نہیں کیا تھا، وہ مسلسل ڈیٹا کے انکشاف کے خطرے کا شکار تھیں۔
- CoopCycle کے مینٹینرز (maintainers): ان کے فوری ردعمل نے – دو دنوں کے اندر پیچ (patch) فراہم کرنا اور ریگریشن ٹیسٹ (regression tests) شامل کرنا – اس کمزوری کے استعمال کے دور کو محدود کر دیا اور ذمہ دارانہ اوپن سورس انتظام کا مظاہرہ کیا۔ تاہم، یہ واقعہ سیکیورٹی ریویو کے عمل کو مزید سخت کرنے کی ضرورت کو اجاگر کرتا ہے، خاص طور پر فریم ورک پر مبنی ڈیفالٹس کے حوالے سے۔
ڈویلپرز اور آڈیٹرز کو کن چیزوں پر نظر رکھنی چاہیے
- آپریشن کی عدم توازن (Operation asymmetry): اگر کسی پاتھ پر POST (یا کوئی بھی تبدیلی لانے والا آپریشن) محفوظ ہے لیکن اس کے مطابق GET کھلا ہوا ہے، تو یہ فرق ایک خطرے کی علامت ہے۔ POST ڈویلپرز کے ریسورس کو محفوظ بنانے کے ارادے کو ظاہر کرتا ہے۔
- کلیکشن اینڈ پوائنٹس (Collection endpoints): کوئی بھی چیز جو ایک آئٹم کے بجائے فہرست (list) واپس کرتی ہے، وہ اکثر عام سیکیورٹی پیٹرنز سے باہر ہوتی ہے۔ اس بات کی تصدیق کریں کہ بلک ریڈز (bulk reads) کے لیے اتھارائزیشن چیک واضح طور پر شامل کیے گئے ہیں۔
- ٹیسٹ سویٹ کی حقیقت پسندی: اس بات کو یقینی بنائیں کہ fixtures حقیقی ٹیننٹ کی حدود کی عکاسی کریں۔ ایک ایسا پاس ہونے والا ٹیسٹ جو کراس-ٹیننٹ ڈیٹا لیک ہونے کی تصدیق کرتا ہو، وہ وارننگ کا نشان ہے، نہ کہ کامیابی کا۔
حل اور اگلے اقدامات
جب اس کمزوری کی اطلاع دی گئی، تو CoopCycle کی کور ٹیم نے GET کلیکشن آپریشن میں غائب سیکیورٹی ایکسپریشن شامل کر دی اور ایسے ریگریشن ٹیسٹ متعارف کرائے جو سنگل آئٹم اور کلیکشن اینڈ پوائنٹس دونوں کے لیے ٹیننٹ آئسولیشن (tenant isolation) کو نافذ کرتے ہیں۔ یہ پیچ سافٹ ویئر کے اگلے ورژن میں جاری کر دیا گیا۔
CoopCycle کے صارفین کو چاہیے کہ:
- تصدیق کریں کہ وہ سافٹ ویئر کا تازہ ترین ورژن چلا رہے ہیں۔
- کسی بھی ایسے کسٹم ایکسٹینشنز یا پلگ انز کا جائزہ لیں جو اسی طرح کے کلیکشن لیول کے خلا پیدا کر سکتے ہیں۔
- تمام API روٹس پر ریڈ/رائٹ کی عدم توازن (asymmetries) پر توجہ دیتے ہوئے سیکیورٹی اسکینز دوبارہ چلائیں۔
حاصل شدہ سبق
وہ فریم ورکس جو سیکیورٹی کو ڈیکلیریٹیو (declarative) بناتے ہیں، خطرناک خامیاں چھپا سکتے ہیں جب ڈویلپرز ایسے پیٹرنز پر انحصار کرتے ہیں جو صرف انفرادی آبجیکٹس (single objects) کے لیے کام کرتے ہیں۔ ایک سادہ سا چیک—کیا کسی اینڈ پوائنٹ کا ریڈ سائیڈ (read side) وہی گارڈ رکھتا ہے جو رائٹ سائیڈ (write side) کا ہے؟—کراس ٹیننٹ لیکس (cross-tenant leaks) کی ایک قسم کو بے نقاب کر سکتا ہے جو ورنہ کامیاب ٹیسٹ سویٹس (green test suites) کے پیچھے چھپے رہتے۔