Mhasibu mwenye ruhusa ya kusoma tu (read-only) angeweza kufuta ankara (invoices) na kufuta historia ya malipo katika zana ya uhasibu ya chanzo huru (open-source) ya Akaunting, jambo linaloweka biashara ndogo katika hatari ya kupoteza data bila kujua. Hitilafu hiyo ilirekebishwa katika toleo la 3.2.0, lakini kosa hilo—kuunganisha ukaguzi wa ruhusa na orodha iliyoandikwa moja kwa moja (hard-coded) ya majina ya njia (method names)—bado linatishia mifumo yoyote inayotegemea udhibiti wa ufikiaji kulingana na majukumu (role-based access control).

Jinsi hitilafu ilivyopita bila kugundulika

API ya Akaunting huhakiki haki za mtumiaji kwa kushauriana na orodha ya majina ya njia (allowlist) iliyoidhinishwa. Orodha hiyo ilijumuisha operesheni za kawaida za CRUD—create, read, update, delete—lakini ilikosa njia (endpoints) kadhaa za kubadilisha hali (status):

  • markSent
  • markCancelled
  • markReceived

Kwa sababu wasimamizi (handlers) hao hawakuwa kwenye orodha, mfumo (framework) haukuwahi kuita utaratibu wa ukaguzi wa ruhusa wakati wanapotekelezwa. Mtumiaji mwenye jukumu la kusoma tu angeweza kutuma ombi rahisi la GET kwenye endpoint ya markCancelled na mfumo ungeichukulia kama mabadiliko halali ya hali.

Kufuta ankara kunafanya zaidi ya kuionyesha hati kama isiyo halali; pia huondoa rekodi zozote za malipo zilizounganishwa na ankara hiyo. Matokeo yake: mtumiaji asiye na haki za kuhariri anaweza kufuta kumbukumbu za kifedha za muamala.

Kile ambacho majaribio yalionesha

Udhaifu huo ulionekana katika picha rasmi ya Docker ya Akaunting:

  • Ombi la kawaida la PUT la kuhuisha ankara lilirudisha 403 Forbidden, likithibitisha kuwa njia ya kawaida ya kuhuisha ilikuwa imelindwa.
  • Ombi la GET kwenye endpoint ya ubatilishaji lilifanikiwa bila hitilafu ya idhini, likionyesha pengo hilo.

Kwa nini ni muhimu

Taarifa za kifedha zinaweza kubadilishwa bila kumbukumbu ya ukaguzi (audit trail) iliyo wazi, jambo linalofanya udanganyifu kuwa mgumu kugundulika na makosa ya kweli kuwa magumu kurekebishwa.

Suluhisho

Toleo la 3.2.0 linaongeza ramani ya ruhusa ili kujumuisha vitendo vya hali vilivyokuwa vimeachwa hapo awali. Kuanzia toleo hilo na kuendelea, ombi lolote linalobadilisha hali ya hati—iwe imewekwa kama imetumwa, imebatilishwa, au imepokelewa—lazima lipite katika uhakiki wa jukumu sawa na uhuishaji wa kawaida. Hii inarudisha matarajio kwamba jukumu la kusoma tu kwa kweli haliwezi kubadilisha data.

Mafunzo kwa watengenezaji

  • Usilinganishe majina ya njia na usalama kamili. Kuongeza endpoint mpya hakulengi kinga moja kwa moja; kagua kila njia ya umma (public method) kwa athari za pembeni (side effects).
  • Orodha za ruhusa (Allowlists) ni kamili tu kadiri orodha yenyewe ilivyo kamili. Orodha ya kudumu ya vitenzi "vizuri" huacha mlango wazi kwa upotevu wa makini.
  • Tenganisha nia na kitenzi cha HTTP. GET imekusudiwa kuwa ya kusoma tu, lakini hapa ilifanya mabadiliko ya hali. Zuia mabadiliko (mutations) kwenye POST, PUT, DELETE, PATCH.
  • Weka mifumo ya kiotomatiki ya kukagua ufikiaji wa ruhusa. Zana za uchambuzi wa kudumu (static analysis tools) zinaweza kuashiria njia za kiongozi (controller methods) zinazokosa wito wa idhini, na kugundua mapengo kabla ya kusambazwa.
  • Jaribu kwa akaunti zenye madaraka ya chini kabisa. Jaribio la Docker lilitumia mtumiaji mwenye ruhusa ya kusoma tu; kurudia matukio kama hayo katika mifumo ya CI hufichua matatizo kama hayo mapema.

Nini cha kufuatilia baadaye

Jumuiya ya Akaunting tayari imetoa toleo lililorekebishwa. Wasimamizi wanapaswa kuhakiki toleo la mfumo wao na kutumia sasisho mara moja.

Kwa watengenezaji wanaojenga mfumo wowote unaotegemea majukumu, funzo ni wazi: mfumo wa ruhusa unaotegemea kukumbuka kila tendo linalowezekana ni dhaifu kwa asili. Tangaza waziwazi ni operesheni zipi zinazobadilisha hali, simamia ukaguzi katika kiwango cha mfumo (framework level), na kagua msimbo (codebase) mara kwa mara. Ni baada ya hapo tu lebo ya "kusoma tu" inaweza kuaminiwa kuhakikisha rekodi za kifedha zinabaki salama.