Akaunting या ओपन-सोर्स बुककीपिंग टूलमध्ये, केवळ 'रीड-ओन्ली' (read-only) अधिकार असलेला अकाउंटंट देखील इनव्हॉइस रद्द करू शकत होता आणि पेमेंटचा इतिहास पुसून टाकू शकत होता, ज्यामुळे लहान व्यवसायांना डेटाच्या गुप्त नुकसानीचा धोका निर्माण झाला होता. ही त्रुटी व्हर्जन 3.2.0 मध्ये सुधारण्यात आली आहे, परंतु ही चूक—परवानगी तपासणी (permission checks) पद्धतीच्या नावांच्या (method names) हार्ड-कोडेड सूचीशी जोडणे—अजूनही 'रोल-बेस्ड ॲक्सेस कंट्रोल'वर अवलंबून असलेल्या कोणत्याही प्रणालीला धोका निर्माण करू शकते.

ही त्रुटी कशी निर्माण झाली

Akaunting चा API पद्धतीच्या नावांच्या 'अलोविस्ट' (allowlist) द्वारे वापरकर्त्याच्या अधिकारांची पडताळणी करतो. या सूचीमध्ये नेहमीच्या CRUD ऑपरेशन्स—create, read, update, delete—चा समावेश होता, परंतु स्थिती बदलणाऱ्या (status-changing) काही एंडपॉइंट्स (endpoints) सुटले होते:

  • markSent
  • markCancelled
  • markReceived

हे हँडलर्स (handlers) सूचीमध्ये नसल्यामुळे, जेव्हा ते कार्यान्वित झाले तेव्हा फ्रेमवर्कने परवानगी तपासण्याची प्रक्रिया (permission-checking routine) कधीच कॉल केली नाही. 'रीड-ओन्ली' रोल असलेला वापरकर्ता markCancelled एंडपॉइंटला साधा GET रिक्वेस्ट पाठवू शकत होता आणि सिस्टमने त्याला वैध स्थिती बदल (legitimate state change) म्हणून स्वीकारले.

इनव्हॉइस रद्द करणे म्हणजे केवळ दस्तऐवज रद्द म्हणून चिन्हांकित करणे नव्हे; तर त्या इनव्हॉइसशी संबंधित असलेले सर्व पेमेंट रेकॉर्ड्स देखील ते काढून टाकते. परिणामी: संपादन (edit) करण्याचे अधिकार नसलेला वापरकर्ता व्यवहाराचा आर्थिक मागोवा (financial trail) पुसून टाकू शकतो.

चाचणीमध्ये काय दिसून आले

ही असुरक्षितता Akaunting च्या अधिकृत Docker इमेजमध्ये दिसून आली:

  • इनव्हॉइस अपडेट करण्यासाठी पाठवलेल्या मानक PUT रिक्वेस्टने 403 Forbidden प्रतिसाद दिला, ज्यामुळे हे सिद्ध झाले की नियमित अपडेट मार्ग सुरक्षित होता.
  • कॅन्सेलेशन एंडपॉइंटला पाठवलेल्या GET रिक्वेस्टमध्ये कोणताही ऑथोरायझेशन एरर न येता ती यशस्वी झाली, ज्यामुळे ही त्रुटी समोर आली.

हे महत्त्वाचे का आहे

स्पष्ट ऑडिट ट्रेलशिवाय आर्थिक विवरणांमध्ये (financial statements) फेरफार केले जाऊ शकतात, ज्यामुळे फसवणूक ओळखणे कठीण होते आणि प्रामाणिक चुका सुधारणे देखील कठीण होते.

उपाय

व्हर्जन 3.2.0 मध्ये परवानगी मॅपचा विस्तार करून यापूर्वी वगळलेल्या स्टेटस ॲक्शन्सचा समावेश करण्यात आला आहे. त्या रिलीजपासून, दस्तऐवजाची स्थिती बदलणारी कोणतीही विनंती—मग ती 'sent', 'cancelled' किंवा 'received' म्हणून चिन्हांकित असो—तिला मानक अपडेटप्रमाणेच रोल व्हेरिफिकेशनमधून जावे लागेल. यामुळे 'रीड-ओन्ली' रोल खरोखरच डेटा बदलू शकत नाही, या अपेक्षेची पूर्तता होते.

डेव्हलपर्ससाठी धडे

  • पद्धतीच्या नावांना (method names) सुरक्षिततेचा निकष मानू नका. नवीन एंडपॉइंट जोडल्याने त्याला आपोआप संरक्षण मिळत नाही; प्रत्येक पब्लिक मेथडच्या 'साइड इफेक्ट्स'ची (side effects) तपासणी करा.
  • अलोविस्ट (Allowlists) हे केवळ त्या सूचीइतकेच पूर्ण असतात. "चांगल्या" क्रियापदांची (verbs) स्थिर सूची चुकांसाठी मार्ग मोकळा ठेवते.
  • हेतू (intent) आणि HTTP verb वेगळे ठेवा. GET हे केवळ वाचण्यासाठी (read-only) असते, परंतु येथे त्याने स्थिती बदलण्याचे काम केले. डेटा बदलण्याच्या (mutations) क्रिया केवळ POST, PUT, DELETE, PATCH पर्यंत मर्यादित ठेवा.
  • परवानगी कव्हरेज तपासणी स्वयंचलित करा. स्टॅटिक ॲनालिसिस टूल्स अशा कंट्रोलर मेथड्स शोधू शकतात ज्यामध्ये ऑथोरायझेशन कॉलचा अभाव आहे, ज्यामुळे सॉफ्टवेअर रिलीज होण्यापूर्वीच त्रुटी पकडता येतात.
  • कमीतकमी अधिकारांच्या (least-privilege) खात्यांसह चाचणी करा. Docker-आधारित चाचणीमध्ये 'रीड-ओन्ली' वापरकर्त्याचा वापर करण्यात आला होता; CI पाइपलाइनमध्ये अशा परिस्थितींची पुनरावृत्ती केल्यास अशा समस्या लवकर समोर येतात.

पुढे काय पाहावे

Akaunting च्या समुदायाने आधीच सुधारित व्हर्जन रिलीज केले आहे. प्रशासकांनी (Administrators) त्यांच्या इन्स्टन्सचे व्हर्जन तपासावे आणि त्वरित अपडेट लागू करावे.

कोणताही रोल-बेस्ड सिस्टम तयार करणाऱ्या डेव्हलपर्ससाठी, यातून मिळणारा धडा स्पष्ट आहे: प्रत्येक संभाव्य कृती लक्षात ठेवण्यावर अवलंबून असलेले परवानगी मॉडेल (permission model) मुळातच कमकुवत असते. कोणत्या ऑपरेशन्समुळे स्थिती बदलते हे स्पष्टपणे घोषित करा, फ्रेमवर्क स्तरावर तपासणी लागू करा आणि कोडबेसचे नियमितपणे ऑडिट करा. तरच, आर्थिक रेकॉर्ड्स सुरक्षित ठेवण्यासाठी "रीड-ओन्ली" लेबलवर विश्वास ठेवता येईल.