ایک ریڈ-اونلی (read-only) اکاؤنٹنٹ اوپن سورس بک کیپنگ ٹول Akaunting میں انوائسز منسوخ کر سکتا تھا اور ادائیگی کی تاریخ کو مٹا سکتا تھا، جس سے چھوٹے کاروبار خاموش ڈیٹا کے نقصان کے خطرے میں پڑ سکتے تھے۔ اس خامی کو ورژن 3.2.0 میں ٹھیک کر دیا گیا ہے، لیکن یہ غلطی—یعنی اجازت کی جانچ (permission checks) کو میتھڈ کے ناموں کی ایک ہارڈ کوڈڈ لسٹ سے جوڑنا—اب بھی ہر اس سسٹم کے لیے خطرہ ہے جو رول بیسڈ ایکسیس کنٹرول (role-based access control) پر انحصار کرتا ہے۔

یہ بگ کیسے نظر انداز ہو گیا

Akaunting کی API میتھڈ کے ناموں کی ایک 'ایلو لسٹ' (allowlist) سے رجوع کر کے صارف کے حقوق کی تصدیق کرتی ہے۔ اس لسٹ میں عام CRUD آپریشنز—create، read، update، delete—شامل تھے، لیکن اسٹیٹس تبدیل کرنے والے کئی اینڈ پوائنٹس (endpoints) رہ گئے تھے:

  • markSent
  • markCancelled
  • markReceived

چونکہ وہ ہینڈلرز لسٹ میں نہیں تھے، اس لیے جب وہ چلتے تھے تو فریم ورک نے کبھی بھی پرمیشن چیک کرنے والے روٹین کو کال نہیں کیا۔ ریڈ-اونلی رول رکھنے والا صارف markCancelled اینڈ پوائنٹ پر ایک سادہ GET ریکویسٹ بھیج سکتا تھا اور سسٹم اسے ایک جائز اسٹیٹ چینج (state change) کے طور پر تسلیم کر لیتا۔

کسی انوائس کو منسوخ کرنے کا مطلب صرف دستاویز کو کالعدم قرار دینا نہیں ہے؛ بلکہ یہ اس انوائس سے منسلک ادائیگی کے تمام ریکارڈز کو بھی ختم کر دیتا ہے۔ نتیجہ یہ نکلتا ہے کہ ایڈیٹ کرنے کے حقوق کے بغیر بھی ایک صارف کسی لین دین کا مالیاتی سراغ (financial trail) مٹا سکتا ہے۔

ٹیسٹنگ سے کیا معلوم ہوا

یہ کمزوری Akaunting کی آفیشل Docker امیج میں ظاہر ہوئی:

  • انوائس کو اپ ڈیٹ کرنے کے لیے ایک عام PUT ریکویسٹ نے 403 Forbidden واپس کیا، جس سے تصدیق ہوئی کہ عام اپ ڈیٹ کا راستہ محفوظ تھا۔
  • کینسلشن اینڈ پوائنٹ پر ایک GET ریکویسٹ بغیر کسی اتھارزیشن ایرر کے کامیاب رہی، جس سے یہ خامی سامنے آگئی۔

یہ کیوں اہم ہے

مالیاتی گوشواروں (financial statements) میں واضح آڈٹ ٹریل کے بغیر تبدیلی کی جا سکتی ہے، جس سے دھوکہ دہی کو پکڑنا اور ایمانداری سے ہونے والی غلطیوں کو درست کرنا مشکل ہو جاتا ہے۔

حل

ورژن 3.2.0 پرمیشن میپ (permission map) کو وسعت دیتا ہے تاکہ پہلے سے نظر انداز کیے گئے اسٹیٹس ایکشنز کو شامل کیا جا سکے۔ اس ریلیز کے بعد سے، کوئی بھی ریکویسٹ جو دستاویز کی حالت تبدیل کرتی ہے—خواہ وہ sent، cancelled، یا received کے طور پر نشان زد ہو—اسے ایک عام اپ ڈیٹ کی طرح اسی رول ویریفیکیشن سے گزرنا ہوگا۔ اس سے یہ توقع بحال ہوتی ہے کہ ریڈ-اونلی رول واقعی ڈیٹا میں ترمیم نہیں کر سکتا۔

ڈویلپرز کے لیے اسباق

  • میتھڈ کے ناموں کو کبھی بھی حفاظت کا معیار نہ سمجھیں۔ ایک نیا اینڈ پوائنٹ شامل کرنے کا مطلب یہ نہیں کہ اسے خود بخود تحفظ مل جائے گا؛ ہر پبلک میتھڈ کا سائیڈ ایفیکٹس (side effects) کے لیے آڈٹ کریں۔
  • ایلو لسٹ (Allowlists) اتنی ہی مکمل ہوتی ہے جتنی کہ خود لسٹ۔ "اچھے" وربز (verbs) کی ایک اسٹیٹک لسٹ کوتاہیوں کے لیے دروازہ کھلا چھوڑ دیتی ہے۔
  • ارادے (intent) کو HTTP ورب سے الگ رکھیں۔ GET صرف پڑھنے کے لیے ہوتا ہے، لیکن یہاں اس نے اسٹیٹ چینج کر دیا۔ تبدیلیوں (mutations) کو صرف POST، PUT، DELETE، PATCH تک محدود رکھیں۔
  • پرمیشن کوریج چیکس کو خودکار بنائیں۔ اسٹیٹک اینالیسس ٹولز ان کنٹرولر میتھڈز کی نشاندہی کر سکتے ہیں جن میں اتھارزیشن کال کی کمی ہو، تاکہ ریلیز سے پہلے ان خامیوں کو پکڑا جا سکے۔
  • کم سے کم اختیارات (least-privilege) والے اکاؤنٹس کے ساتھ ٹیسٹ کریں۔ Docker پر مبنی ٹیسٹ میں ریڈ-اونلی صارف کا استعمال کیا گیا تھا؛ CI پائپ لائنز میں ایسے منظرناموں کو دہرانے سے اسی طرح کے مسائل جلد سامنے آ جاتے ہیں۔

آگے کیا دیکھنا ہے

Akaunting کی کمیونٹی پہلے ہی پیچ شدہ (patched) ورژن جاری کر چکی ہے۔ ایڈمنسٹریٹرز کو چاہیے کہ وہ اپنے انسٹنس کے ورژن کی تصدیق کریں اور فوری طور پر اپ ڈیٹ لاگو کریں۔

کسی بھی رول بیسڈ سسٹم کو بنانے والے ڈویلپرز کے لیے سبق واضح ہے: ایک ایسا پرمیشن ماڈل جو ہر ممکن عمل کو یاد رکھنے پر انحصار کرتا ہے، ڈیزائن کے لحاظ سے کمزور ہے۔ واضح طور پر اعلان کریں کہ کون سے آپریشنز اسٹیٹ کو تبدیل کرتے ہیں، فریم ورک کی سطح پر چیکز نافذ کریں، اور باقاعدگی سے کوڈ بیس کا آڈٹ کریں۔ صرف تب ہی "ریڈ-اونلی" لیبل پر مالیاتی ریکارڈز کو محفوظ رکھنے کے لیے بھروسہ کیا جا سکتا ہے۔