Akaunting എന്ന ഓപ്പൺ സോഴ്സ് ബുക്ക് കീപ്പിംഗ് ടൂളിൽ, ഒരു 'read-only' അക്കൗണ്ടന്റിന് ഇൻവോയ്‌സുകൾ റദ്ദാക്കാനും പേയ്‌മെന്റ് ചരിത്രം മായ്ച്ചുകളയാനും സാധിക്കുമായിരുന്നു. ഇത് ചെറുകിട ബിസിനസ്സുകളെ നിശബ്ദമായ ഡാറ്റാ നഷ്ടത്തിന് ഇരയാക്കുന്നു. ഈ പിഴവ് 3.2.0 പതിപ്പിൽ പരിഹരിച്ചു, എന്നാൽ പെർമിഷൻ പരിശോധനകളെ മെത്തേഡ് പേരുകളുടെ ഒരു ഹാർഡ്-കോഡഡ് ലിസ്റ്റുമായി ബന്ധിപ്പിച്ചു എന്ന തെറ്റ്, റോൾ അധിഷ്ഠിത ആക്സസ് കൺട്രോൾ (role-based access control) ഉപയോഗിക്കുന്ന ഏത് സിസ്റ്റത്തിനും ഇപ്പോഴും ഭീഷണിയാണ്.

ബഗ് എങ്ങനെ സംഭവിച്ചു

Akaunting-ന്റെ API, മെത്തേഡ് പേരുകളുടെ ഒരു allowlist പരിശോധിച്ചാണ് ഉപയോക്താവിന്റെ അവകാശങ്ങൾ സാധ്യമാക്കുന്നത്. ഈ ലിസ്റ്റിൽ സാധാരണ CRUD ഓപ്പറേഷനുകൾ—create, read, update, delete—ഉൾപ്പെട്ടിരുന്നു, എന്നാൽ സ്റ്റാറ്റസ് മാറ്റുന്ന ചില എൻഡ്‌പോയിന്റുകൾ (endpoints) ഇതിൽ വിട്ടുപോയി:

  • markSent
  • markCancelled
  • markReceived

ഈ ഹാൻഡ്‌ലറുകൾ ലിസ്റ്റിൽ ഇല്ലാതിരുന്നതിനാൽ, അവ പ്രവർത്തിക്കുമ്പോൾ ഫ്രെയിംവർക്ക് പെർമിഷൻ പരിശോധനയ്ക്കുള്ള റൂട്ടീൻ ഒരിക്കലും വിളിച്ചിരുന്നില്ല. ഒരു 'read-only' റോൾ ഉള്ള ഉപയോക്താവിന് markCancelled എൻഡ്‌പോയിന്റിലേക്ക് ഒരു ലളിതമായ GET റിക്വസ്റ്റ് അയക്കാൻ സാധിക്കുമായിരുന്നു, സിസ്റ്റം അത് ഒരു നിയമപരമായ സ്റ്റേറ്റ് ചേഞ്ച് (state change) ആയി കണക്കാക്കുകയും ചെയ്യും.

ഒരു ഇൻവോയ്‌സ് റദ്ദാക്കുന്നത് ആ രേഖയെ അസാധുവാക്കുന്നത് മാത്രമല്ല; ആ ഇൻവോയ്‌സുമായി ബന്ധപ്പെട്ട ഏതൊരു പേയ്‌മെന്റ് റെക്കോർഡുകളും അത് നീക്കം ചെയ്യുന്നു. ഇതിന്റെ ഫലം: എഡിറ്റ് ചെയ്യാനുള്ള അവകാശമില്ലാത്ത ഒരു ഉപയോക്താവിന് ഒരു ഇടപാടിന്റെ സാമ്പത്തിക വിവരങ്ങൾ (financial trail) പൂർണ്ണമായും മായ്ച്ചുകളയാൻ സാധിക്കും.

ടെസ്റ്റിംഗ് എന്ത് കാണിച്ചു

Akaunting-ന്റെ ഔദ്യോഗിക Docker ഇമേജിലാണ് ഈ സുരക്ഷാ വീഴ്ച കണ്ടെത്തിയത്:

  • ഒരു ഇൻവോയ്‌സ് അപ്‌ഡേറ്റ് ചെയ്യാൻ സാധാരണ രീതിയിലുള്ള PUT റിക്വസ്റ്റ് അയച്ചപ്പോൾ 403 Forbidden എന്ന് ലഭിച്ചു, ഇത് സാധാരണ അപ്‌ഡേറ്റ് പാത്ത് സുരക്ഷിതമാണെന്ന് സ്ഥിരീകരിച്ചു.
  • ക്യാൻസലേഷൻ എൻഡ്‌പോയിന്റിലേക്ക് അയച്ച GET റിക്വസ്റ്റ് യാതൊരു ഓതറൈസേഷൻ പിഴവും ഇല്ലാതെ വിജയിച്ചു, ഇത് സുരക്ഷാ വിടവ് വെളിപ്പെടുത്തി.

എന്തുകൊണ്ട് ഇത് പ്രധാനമാണ്

വ്യക്തമായ ഓഡിറ്റ് ട്രയൽ ഇല്ലാതെ സാമ്പത്തിക പ്രസ്താവനകളിൽ (financial statements) മാറ്റം വരുത്താൻ സാധിക്കും, ഇത് തട്ടിപ്പുകൾ കണ്ടെത്തുന്നത് പ്രയാസകരമാക്കുകയും സത്യസന്ധമായ തെറ്റുകൾ തിരുത്തുന്നത് ബുദ്ധിമുട്ടാക്കുകയും ചെയ്യുന്നു.

പരിഹാരം

3.2.0 പതിപ്പ്, മുമ്പ് വിട്ടുപോയ സ്റ്റാറ്റസ് ആക്ഷനുകളെ ഉൾപ്പെടുത്തി പെർമിഷൻ മാപ്പ് വിപുലീകരിക്കുന്നു. ആ റിലീസ് മുതൽ, ഒരു ഡോക്യുമെന്റിന്റെ സ്റ്റേറ്റ് മാറ്റുന്ന ഏതൊരു റിക്വസ്റ്റും—അത് sent, cancelled, അല്ലെങ്കിൽ received ആയി മാർക്ക് ചെയ്തതായാലും—സാധാരണ അപ്‌ഡേറ്റ് ചെയ്യുന്നതുപോലെ തന്നെ റോൾ വെരിഫിക്കേഷനിലൂടെ കടന്നുപോകണം. ഇത് ഒരു 'read-only' റോളിന് ഡാറ്റയിൽ മാറ്റം വരുത്താൻ കഴിയില്ല എന്ന ഉറപ്പ് വീണ്ടെടുക്കുന്നു.

ഡെവലപ്പർമാർക്കുള്ള പാഠങ്ങൾ

  • മെത്തേഡ് പേരുകളെ ഒരിക്കലും സുരക്ഷയുടെ മാനദണ്ഡമായി കാണരുത്. ഒരു പുതിയ എൻഡ്‌പോയിന്റ് ചേർക്കുന്നത് കൊണ്ട് മാത്രം അതിന് സുരക്ഷ ലഭിക്കണമെന്നില്ല; ഓരോ പബ്ലിക് മെത്തേഡും അതിന്റെ പാർശ്വഫലങ്ങൾക്കായി (side effects) പരിശോധിക്കുക.
  • Allowlist എത്രത്തോളം പൂർണ്ണമാണോ അത്രത്തോളം മാത്രമേ അത് സുരക്ഷിതമാകൂ. "നല്ല" വെർബുകളുടെ (verbs) ഒരു സ്റ്റാറ്റിക് ലിസ്റ്റ് ഉപയോഗിക്കുന്നത് അശ്രദ്ധകൾക്ക് വഴിമാറാൻ സാധ്യതയുണ്ട്.
  • ലക്ഷ്യത്തെ (intent) HTTP വെർബിൽ നിന്ന് വേർതിരിക്കുക. GET എന്നത് റീഡ്-ഓൺലി ആയിരിക്കേണ്ടതാണ്, എന്നാൽ ഇവിടെ അത് ഒരു സ്റ്റേറ്റ് ചേഞ്ച് നടത്തി. മാറ്റങ്ങൾ വരുത്തുന്നതിനായി (mutations) POST, PUT, DELETE, PATCH എന്നിവ മാത്രം ഉപയോഗിക്കുക.
  • പെർമിഷൻ കവറേജ് പരിശോധനകൾ ഓട്ടോമേറ്റ് ചെയ്യുക. ഓതറൈസേഷൻ കോൾ ഇല്ലാത്ത കൺട്രോളർ മെത്തേഡുകളെ സ്റ്റാറ്റിക് അനാലിസിസ് ടൂളുകൾക്ക് കണ്ടെത്താൻ സാധിക്കും, ഇത് പ്രശ്നങ്ങൾ പുറത്തിറക്കുന്നതിന് മുമ്പ് തന്നെ പരിഹരിക്കാൻ സഹായിക്കും.
  • കുറഞ്ഞ അവകാശങ്ങളുള്ള (least-privilege) അക്കൗണ്ടുകൾ ഉപയോഗിച്ച് ടെസ്റ്റ് ചെയ്യുക. Docker അടിസ്ഥാനമാക്കിയുള്ള ടെസ്റ്റിൽ ഒരു read-only ഉപയോക്താവിനെയാണ് ഉപയോഗിച്ചത്; ഇത്തരം സാഹചര്യങ്ങൾ CI പൈപ്പ്‌ലൈനുകളിൽ പരീക്ഷിക്കുന്നത് സമാനമായ പ്രശ്നങ്ങൾ നേരത്തെ കണ്ടെത്താൻ സഹായിക്കും.

ഇനി ശ്രദ്ധിക്കേണ്ടത്

Akaunting കമ്മ്യൂണിറ്റി ഇതിനകം തന്നെ പരിഹരിച്ച പതിപ്പ് പുറത്തിറക്കി കഴിഞ്ഞു. അഡ്മിനിസ്ട്രേറ്റർമാർ തങ്ങളുടെ ഇൻസ്റ്റൻസ് പതിപ്പ് പരിശോധിക്കുകയും ഉടൻ തന്നെ അപ്‌ഡേറ്റ് ചെയ്യുകയും വേണം.

റോൾ അധിഷ്ഠിത സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാർക്ക് ഇതിൽ നിന്നുള്ള പാഠം വ്യക്തമാണ്: ഓരോ പ്രവൃത്തിയും ഓർത്തുവെക്കുന്നതിനെ ആശ്രയിക്കുന്ന ഒരു പെർമിഷൻ മോഡൽ രൂപകൽപ്പനയിൽ തന്നെ ദുർബലമാണ്. ഏതെല്ലാം ഓപ്പറേഷനുകളാണ് സ്റ്റേറ്റ് മാറ്റുന്നത് എന്ന് വ്യക്തമായി പ്രഖ്യാപിക്കുക, ഫ്രെയിംവർക്ക് തലത്തിൽ പരിശോധനകൾ നടപ്പിലാക്കുക, കോഡ്ബേസ് കൃത്യമായി ഓഡിറ്റ് ചെയ്യുക. എങ്കിൽ മാത്രമേ സാമ്പത്തിക രേഖകൾ സുരക്ഷിതമായി സൂക്ഷിക്കാൻ ഒരു "read-only" ലേബലിനെ വിശ്വസിക്കാൻ കഴിയൂ.