Un contabile con permessi di sola lettura poteva annullare le fatture e cancellare la cronologia dei pagamenti nello strumento di contabilità open-source Akaunting, esponendo le piccole imprese a una perdita silenziosa di dati. La falla è stata corretta nella versione 3.2.0, ma l'errore — legare i controlli dei permessi a un elenco predefinito di nomi di metodi — minaccia ancora qualsiasi sistema che si affidi al controllo degli accessi basato sui ruoli.

Come è passato inosservato il bug

L'API di Akaunting convalida i diritti di un utente consultando una allowlist di nomi di metodi. L'elenco copriva le solite operazioni CRUD — create, read, update, delete — ma ometteva diversi endpoint che modificano lo stato:

  • markSent
  • markCancelled
  • markReceived

Poiché quegli handler non erano presenti nell'elenco, il framework non chiamava mai la routine di controllo dei permessi durante la loro esecuzione. Un utente con un ruolo di sola lettura poteva inviare una semplice richiesta GET all'endpoint markCancelled e il sistema l'avrebbe trattata come un legittimo cambiamento di stato.

Annullare una fattura fa molto più che contrassegnare il documento come nullo; rimuove anche tutti i record di pagamento collegati a quella fattura. Il risultato: un utente senza diritti di modifica può cancellare la traccia finanziaria di una transazione.

Cosa ha mostrato il testing

La vulnerabilità è emersa nell'immagine Docker ufficiale di Akaunting:

  • Una richiesta PUT standard per aggiornare una fattura restituiva 403 Forbidden, confermando che il percorso di aggiornamento regolare era protetto.
  • Una richiesta GET all'endpoint di cancellazione andava a buon fine senza errori di autorizzazione, esponendo la falla.

Perché è importante

I rendiconti finanziari possono essere alterati senza una chiara traccia di audit, rendendo più difficile individuare frodi e correggere errori onesti.

La correzione

La versione 3.2.0 espande la mappa dei permessi per includere le azioni di stato precedentemente omesse. Da quel rilascio in poi, qualsiasi richiesta che modifichi lo stato di un documento — sia che venga contrassegnato come inviato, annullato o ricevuto — deve passare attraverso la stessa verifica del ruolo di un aggiornamento standard. Ciò ripristina l'aspettativa che un ruolo di sola lettura non possa effettivamente modificare i dati.

Lezioni per gli sviluppatori

  • Non equiparare mai i nomi dei metodi alla sicurezza. L'aggiunta di un nuovo endpoint non eredita automaticamente la protezione; analizza ogni metodo pubblico per eventuali effetti collaterali.
  • Le allowlist sono complete solo quanto l'elenco stesso. Un elenco statico di verbi "buoni" lascia la porta aperta a sviste.
  • Separa l'intento dal verbo HTTP. GET è destinato alla sola lettura, ma in questo caso ha eseguito un cambiamento di stato. Limita le mutazioni a POST, PUT, DELETE, PATCH.
  • Automatizza i controlli di copertura dei permessi. Gli strumenti di analisi statica possono segnalare i metodi del controller privi di una chiamata di autorizzazione, individuando le falle prima del rilascio.
  • Testa con account a privilegi minimi. Il test basato su Docker ha utilizzato un utente di sola lettura; replicare tali scenari nelle pipeline CI permette di far emergere problemi simili precocemente.

Cosa monitorare ora

La community di Akaunting ha già rilasciato la versione corretta. Gli amministratori dovrebbero verificare la versione della propria istanza e applicare l'aggiornamento tempestivamente.

Per gli sviluppatori che costruiscono qualsiasi sistema basato sui ruoli, l'insegnamento è chiaro: un modello di permessi che dipende dal ricordare ogni possibile azione è fragile per progettazione. Dichiara esplicitamente quali operazioni modificano lo stato, impone i controlli a livello di framework e sottoponi regolarmente il codice ad audit. Solo allora si potrà fidarsi di un'etichetta "sola lettura" per mantenere integri i registri finanziari.