Seorang akauntan dengan akses baca-sahaja boleh membatalkan invois dan memadam sejarah pembayaran dalam alat pembukuan sumber terbuka Akaunting, mendedahkan perniagaan kecil kepada kehilangan data secara senyap. Kelemahan tersebut telah ditampal dalam versi 3.2.0, tetapi kesilapan tersebut—menghubungkan semakan kebenaran kepada senarai nama kaedah yang dikodkan secara keras (hard-coded)—masih mengancam mana-mana sistem yang bergantung pada kawalan akses berasaskan peranan.

Bagaimana pepijat tersebut terlepas

API Akaunting mengesahkan hak pengguna dengan merujuk kepada senarai putih (allowlist) nama kaedah. Senarai tersebut merangkumi operasi CRUD biasa—create, read, update, delete—tetapi terlepas beberapa titik akhir (endpoint) penukaran status:

  • markSent
  • markCancelled
  • markReceived

Oleh kerana pengendali (handler) tersebut tidak ada dalam senarai, rangka kerja (framework) tidak pernah memanggil rutin semakan kebenaran apabila ia dijalankan. Pengguna dengan peranan baca-sahaja boleh menghantar permintaan GET yang mudah ke titik akhir markCancelled dan sistem akan menganggapnya sebagai perubahan keadaan yang sah.

Membatalkan invois bukan sekadar menandakan dokumen sebagai terbatal; ia juga memadamkan sebarang rekod pembayaran yang dikaitkan dengan invois tersebut. Hasilnya: pengguna tanpa hak suntingan boleh menghapuskan jejak kewangan sesuatu transaksi.

Apa yang ditunjukkan oleh ujian

Kerentanan tersebut muncul dalam imej Docker rasmi Akaunting:

  • Permintaan PUT standard untuk mengemas kini invois mengembalikan 403 Forbidden, mengesahkan bahawa laluan kemas kini biasa dilindungi.
  • Permintaan GET ke titik akhir pembatalan berjaya tanpa ralat kebenaran, mendedahkan jurang tersebut.

Mengapa ia penting

Penyata kewangan boleh diubah tanpa jejak audit yang jelas, menjadikan penipuan lebih sukar dikesan dan kesilapan jujur lebih sukar untuk diperbaiki.

Pembaikan

Versi 3.2.0 memperluas peta kebenaran untuk menyertakan tindakan status yang sebelum ini tertinggal. Bermula dari versi tersebut, sebarang permintaan yang mengubah keadaan dokumen—sama ada ditandakan sebagai dihantar, dibatalkan, atau diterima—mesti melalui pengesahan peranan yang sama seperti kemas kini standard. Ini mengembalikan jangkaan bahawa peranan baca-sahaja benar-benar tidak boleh mengubah data.

Pengajaran untuk pembangun

  • Jangan sesekali menyamakan nama kaedah dengan keselamatan. Menambah titik akhir baharu tidak secara automatik mewarisi perlindungan; audit setiap kaedah awam untuk kesan sampingan.
  • Senarai putih hanya selengkap senarai itu sendiri. Senarai statik kata kerja "baik" meninggalkan pintu terbuka untuk kecuaian.
  • Asingkan niat daripada kata kerja HTTP. GET bertujuan untuk baca-sahaja, tetapi di sini ia melakukan perubahan keadaan. Hadkan mutasi kepada POST, PUT, DELETE, PATCH.
  • Automasikan semakan liputan kebenaran. Alat analisis statik boleh menandakan kaedah pengawal (controller) yang kekurangan panggilan kebenaran, mengesan jurang sebelum ia dilancarkan.
  • Uji dengan akaun keistimewaan terendah (least-privilege). Ujian berasaskan Docker menggunakan pengguna baca-sahaja; mereplikasi senario sedemikian dalam saluran paip CI akan mendedahkan isu serupa lebih awal.

Apa yang perlu diperhatikan seterusnya

Komuniti Akaunting telah pun mengeluarkan versi yang telah ditampal. Pentadbir harus mengesahkan versi instans mereka dan melaksanakan kemas kini dengan segera.

Bagi pembangun yang membina mana-mana sistem berasaskan peranan, pengajarannya adalah jelas: model kebenaran yang bergantung pada ingatan terhadap setiap tindakan yang mungkin adalah rapuh dari segi reka bentuk. Nyatakan secara eksplisit operasi mana yang mengubah keadaan, laksanakan semakan pada peringkat rangka kerja, dan audit kod sumber secara berkala. Hanya dengan itu label "baca-sahaja" boleh dipercayai untuk mengekalkan rekod kewangan dengan utuh.