Akaunting என்ற திறந்த மூல (open-source) கணக்குப்பதிவு கருவியில், 'read-only' (படிக்க மட்டுமே அனுமதி கொண்ட) கணக்காளர், விலைப்பட்டியல்களை (invoices) ரத்து செய்யவும் மற்றும் கட்டண வரலாற்றை அழிக்கவும் முடிந்தது. இது சிறு வணிகங்களை கவனிக்கப்படாமல் நடக்கும் தரவு இழப்பிற்கு (silent data loss) உள்ளாக்கியது. இந்த குறைபாடு பதிப்பு 3.2.0-இல் சரிசெய்யப்பட்டது, ஆனால் அனுமதிச் சரிபார்ப்புகளை (permission checks) மெத்தட் பெயர்களின் (method names) நிலையான பட்டியலுடன் இணைத்த அந்தத் தவறு, பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாட்டை (role-based access control) நம்பியிருக்கும் எந்தவொரு அமைப்பிற்கும் இப்போதும் அச்சுறுத்தலாக உள்ளது.

இந்த பிழை எவ்வாறு தப்பியது

Akaunting-ன் API, மெத்தட் பெயர்களின் ஒரு அனுமதிக்கப்பட்ட பட்டியலை (allowlist) சரிபார்ப்பதன் மூலம் பயனரின் உரிமைகளை உறுதி செய்கிறது. அந்தப் பட்டியலில் வழக்கமான CRUD செயல்பாடுகள்—create, read, update, delete—அடங்கியிருந்தன, ஆனால் நிலை மாற்றும் (status-changing) சில எண்ட்பாயிண்ட்கள் (endpoints) விடுபட்டிருந்தன:

  • markSent
  • markCancelled
  • markReceived

அந்த ஹேண்ட்லர்கள் (handlers) பட்டியலில் இல்லாததால், அவை இயங்கும்போது பிரேம்வொர்க் (framework) அனுமதிச் சரிபார்ப்பு முறையை (permission-checking routine) அழைக்கவில்லை. 'read-only' பாத்திரத்தைக் கொண்ட ஒரு பயனர் markCancelled எண்ட்பாயிண்டிற்கு ஒரு எளிய GET கோரிக்கையை (request) அனுப்பினால், சிஸ்டம் அதை ஒரு முறையான நிலை மாற்றமாகவே கருதியது.

ஒரு விலைப்பட்டியலை ரத்து செய்வது என்பது அந்த ஆவணத்தை செல்லாதது என்று குறிப்பது மட்டுமல்ல; அது அந்த விலைப்பட்டியலுடன் தொடர்புடைய எந்தவொரு கட்டணப் பதிவுகளையும் நீக்கிவிடும். இதன் விளைவாக: திருத்த உரிமைகள் இல்லாத ஒரு பயனர் ஒரு பரிவர்த்தனையின் நிதித் தடயத்தை (financial trail) அழித்துவிட முடியும்.

சோதனை என்ன காட்டியது

இந்த பாதிப்பு Akaunting-ன் அதிகாரப்பூர்வ Docker இமேஜில் (image) காணப்பட்டது:

  • ஒரு விலைப்பட்டியலைப் புதுப்பிக்க அனுப்பப்பட்ட சாதாரண PUT கோரிக்கை 403 Forbidden என்ற முடிவைத் தந்தது, இதன் மூலம் வழக்கமான புதுப்பித்தல் வழிமுறை பாதுகாப்பானது என்பது உறுதி செய்யப்பட்டது.
  • ரத்து செய்யும் எண்ட்பாயிண்டிற்கு அனுப்பப்பட்ட GET கோரிக்கை எந்த அங்கீகாரப் பிழையும் இன்றி வெற்றிகரமாக அமைந்தது, இது அந்த இடைவெளியை வெளிப்படுத்தியது.

இது ஏன் முக்கியமானது

தெளிவான தணிக்கைப் பதிவு (audit trail) இல்லாமல் நிதி அறிக்கைகளை மாற்றியமைக்க முடியும், இதனால் மோசடிகளைக் கண்டறிவதும், நேர்மையான தவறுகளைச் சரிசெய்வதும் கடினமாகிறது.

தீர்வு

பதிப்பு 3.2.0, முன்பு விடுபட்ட நிலைச் செயல்பாடுகளை (status actions) உள்ளடக்கும் வகையில் அனுமதி வரைபடத்தை (permission map) விரிவுபடுத்துகிறது. அந்த வெளியீட்டிலிருந்து, ஒரு ஆவணத்தின் நிலையை மாற்றும் எந்தவொரு கோரிக்கையும்—அவை அனுப்பப்பட்டது (sent), ரத்து செய்யப்பட்டது (cancelled) அல்லது பெறப்பட்டது (received) என எதுவாக இருந்தாலும்—வழக்கமான புதுப்பித்தலைப் போலவே அதே பங்கு சரிபார்ப்புக்கும் (role verification) உட்படுத்தப்பட வேண்டும். இதன் மூலம், 'read-only' பாத்திரத்தைக் கொண்ட ஒருவர் தரவை மாற்ற முடியாது என்ற எதிர்பார்ப்பு மீண்டும் உறுதி செய்யப்படுகிறது.

டெவலப்பர்களுக்கான பாடங்கள்

  • மெத்தட் பெயர்களைப் பாதுகாப்போடு ஒருபோதும் சமமாக எண்ண வேண்டாம். ஒரு புதிய எண்ட்பாயிண்ட்டைச் சேர்ப்பது தானாகவே பாதுகாப்பைப் பெறாது; ஒவ்வொரு பொதுவான மெத்தடையும் அதன் பக்கவிளைவுகளுக்காக (side effects) தணிக்கை செய்யுங்கள்.
  • அனுமதிக்கப்பட்ட பட்டியல்கள் (Allowlists) அந்தப் பட்டியலின் முழுமையைப் பொறுத்தே செயல்படும். "நல்ல" வினைச்சொற்களின் (verbs) நிலையான பட்டியல், கவனக்குறைவிற்கான வாய்ப்புகளைத் திறந்துவிடுகிறது.
  • நோக்கத்தையும் (intent) HTTP வினைச்சொல்லையும் (verb) தனித்தனியாகப் பிரிக்கவும். GET என்பது படிக்க மட்டுமே (read-only) செய்யப்பட வேண்டும், ஆனால் இங்கே அது ஒரு நிலை மாற்றத்தைச் செய்தது. தரவு மாற்றங்களை (mutations) POST, PUT, DELETE, PATCH ஆகியவற்றிற்கு மட்டுமே கட்டுப்படுத்துங்கள்.
  • அனுமதித் தன்மையைச் சரிபார்க்கும் சோதனைகளைத் தானியக்கமாக்குங்கள் (Automate). அங்கீகார அழைப்பு (authorization call) இல்லாத கன்ட்ரோலர் மெத்தட்களை (controller methods) நிலையான பகுப்பாய்வு கருவிகள் (static analysis tools) கண்டறிய உதவும், இதன் மூலம் பிழைகள் வெளியாவதற்கு முன்பே அவற்றைப் பிடிக்க முடியும்.
  • குறைந்தபட்ச உரிமைகளைக் கொண்ட கணக்குகளைக் கொண்டு சோதிக்கவும் (Test with least-privilege accounts). Docker அடிப்படையிலான சோதனையில் 'read-only' பயனர் பயன்படுத்தப்பட்டார்; இத்தகைய சூழல்களை CI குழாய்களில் (pipelines) மீண்டும் உருவாக்குவது இது போன்ற சிக்கல்களை முன்கூட்டியே வெளிப்படுத்தும்.

அடுத்து கவனிக்க வேண்டியவை

Akaunting சமூகத்தினர் ஏற்கனவே சரிசெய்யப்பட்ட பதிப்பை வெளியிட்டுள்ளனர். நிர்வாகிகள் தங்கள் இன்ஸ்டன்ஸ் (instance) பதிப்பைச் சரிபார்த்து, உடனடியாகப் புதுப்பிப்பைச் செயல்படுத்த வேண்டும்.

பங்கு அடிப்படையிலான எந்தவொரு அமைப்பை உருவாக்கும் டெவலப்பர்களுக்கும், இதிலிருந்து கிடைக்கும் பாடம் தெளிவானது: ஒவ்வொரு சாத்தியமான செயலையும் நினைவில் வைத்துச் செயல்படும் அனுமதி மாதிரி (permission model), வடிவமைப்பிலேயே பலவீனமானது. எந்தச் செயல்பாடுகள் நிலையை மாற்றுகின்றன என்பதைத் தெளிவாகக் குறிப்பிடவும், பிரேம்வொர்க் மட்டத்தில் சரிபார்ப்புகளைக் கட்டாயமாக்கவும், மற்றும் குறியீட்டுத் தொகுதியை (codebase)த் தொடர்ந்து தணிக்கை செய்யவும். அப்போதுதான், நிதிப் பதிவுகளை அப்படியே வைத்திருப்பதாக ஒரு "read-only" லேபிளை நம்ப முடியும்.